我需要尽可能集中地防止 XSS 攻击,这样我就不必明确地清理每个输入。
我的问题是在 URL/请求处理级别对所有输入进行清理,在服务之前对输入进行编码/清理,还是在表示级别(输出清理)更好?哪个更好,为什么?
我需要尽可能集中地防止 XSS 攻击,这样我就不必明确地清理每个输入。
我的问题是在 URL/请求处理级别对所有输入进行清理,在服务之前对输入进行编码/清理,还是在表示级别(输出清理)更好?哪个更好,为什么?
您需要注意两个方面:
将输入用作任何语言的脚本的一部分的任何地方,最显着的是包括 SQL。在 SQL 的特定情况下,唯一推荐的处理方式是使用参数化查询(这将导致数据库中存在未转义的内容,但就像字符串一样:这是理想的)。在将字符直接替换为 SQL 字符串之前,涉及对字符进行魔术引用的任何事情都是劣质的(因为它很容易出错)。使用参数化查询无法完成的任何事情都是针对 SQL 注入保护的服务绝不应该允许用户指定的事情。
将输入作为输出的东西呈现在任何地方。输入的来源可以是直接的(包括通过 cookie)或间接的(通过数据库或文件)。在这种情况下,您的默认方法应该是使用户看到的文本成为输入的文本。这很容易正确实现,因为您实际上必须引用的唯一字符是<
and &
,并且您可以将其全部包装起来以<pre>
供显示。
但这通常是不够的。例如,您可能希望允许用户进行某种格式化。这是很容易出错的地方。在这种情况下,最简单的方法是解析输入并检测所有格式化指令;其他所有内容都需要正确引用。您应该将格式化版本另外存储在数据库中作为额外的列,以便在将其返回给用户时不需要做太多工作,但您还应该存储用户输入的原始版本,以便您可以搜索它. 不要把它们混在一起!真的!审核您的应用程序以确保您完全正确(或者,更好的是,让其他人进行审核)。
但是关于小心使用 SQL 的一切仍然适用,并且有许多 HTML 标记(例如 , <script>
)<object>
和属性(例如onclick
)从来都不是安全的。
您正在寻找有关特定软件包的建议来完成这项工作?那你真的需要选择一种语言。上述建议完全与语言无关。附加包/库可以使上述许多步骤在实践中变得非常容易,但您仍然绝对需要小心。