XSS预防：客户端还是服务器端？

Question

从存储的XSS中预防的最佳方法是什么？

• 是否应对每个文本字段（甚至纯文本）进行清理服务器端，以防止使用OWASP Java HTML Sanitizer Project之类的XSS HTML？
• 或客户端应该通过应用XSS prevention rules来保护自己免受XSS错误的影响吗？

第一种解决方案的问题是可以修改数据（字符编码，部分或全部删除......）。这可能会改变应用程序的行为，尤其是显示问题。

Answer 1

当且仅当您的数据需要符合特定格式/标准且您确定可以安全丢弃数据时，才应用 sanitisation ;例如您从电话或信用卡号码中删除所有非数字字符。您始终为适当的上下文应用转义，例如将用户提供的数据放入HTML时对其进行HTML编码。

大多数时候你不想进行消毒，因为你想明确允许自由形式的数据输入并禁止某些字符只是没有意义。我在这里看到的少数例外情况之一就是如果您接受用户的HTML输入，您将需要清理该HTML以过滤掉不需要的标签和属性并确保语法有效;但是，您可能希望将原始的未经过消毒的版本存储在数据库中，并仅在输出时应用此消毒。

Answer 2

客户必须为此辩护。有两个原因：

• 因为这是漏洞发生的地方。您可能正在调用第3方API，但它们并未转义/编码所有内容。最好不要信任任何东西。

• 第二，可以为HTML页面和Android App编写API。那么，为什么服务器html在返回到Android应用程序的途中可能会对请求中的html标签进行编码呢？

Answer 3

安全方面的黄金标准是：验证您的输入，编码，而不是清理您的输出。

首先，验证输入服务器端。一个很好的例子是用户配置文件上的电话号码字段。电话号码应该只包括数字，短划线和可能的+。那么为什么要让用户提交信件，特殊字符等呢？它只会增加攻击面。因此，尽可能严格地验证该字段，并拒绝不良输入。

其次，根据输出上下文对输出进行编码。我也建议在服务器端执行此步骤，但只要您使用经过良好测试的前端框架，客户端就相对安全。消毒的主要问题是不同的环境对安全性有不同的要求。要在将用户数据注入HTML属性，直接注入页面或脚本标记时阻止XSS，您需要执行不同的操作。因此，您可以根据输出上下文创建特定的输出编码器。实体编码用于HTML上下文，JSON.stringify用于脚本上下文等。