我有一个编辑器,允许用户添加存储在数据库中并呈现在网页上的 HTML。由于这是不受信任的输入,我计划使用 Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment 净化 HTML。

  • 我应该在保存到数据库之前或将不受信任的输入呈现到网页之前进行清理吗?
  • 在我的项目中包含 AntiXSS 源代码(而不是仅包含 DLL)是否有优势?(也许我可以自定义白名单?)
  • 我应该查找哪个类文件来实际实现 GetSafeHtmlFragment
有帮助吗?

解决方案

我不同意所选答案有两个原因

  1. 如果您存储了编码数据,则必须在存储之前选择编码器。如果您已将某些内容存储为 HTML,但还想以其他格式(例如作为 JSON 响应或作为 XML 文档的一部分)推出,会发生什么情况?现在您已经有了一个 HTML 编码格式,您必须对其进行解码,然后以正确的格式进行编码。
  2. 如果我们发现编码器中的错误并推出新版本怎么办?现在,因为您没有在输出时进行编码,所以所有旧数据可能包含已错误编码的内容。您可以再次编码,但随后会遇到双重编码问题,这可能很难正确过滤。

通常,您在输出点进行编码,并将来自数据存储的任何数据默认视为不可信 - 毕竟,如果有人直接或通过 SQL 注入编辑您的数据库怎么办?

其他提示

听听 Jeff Williams 的 OWASP 播客 67 关于 XSS. 。他谈到在存储之前不进行消毒或编码。主要原因是,如果(当)库为了响应新漏洞而发展时,您的数据将被困在旧版本中。当然,这并不能阻止您在入口点针对白名单运行任何输入并拒绝任何超出可接受范围的内容。

  • 两个都
  • 仅当您打算更改它时,我个人不会这样做
  • AntiXss 类(因为它被称为 AntiXss.GetSafeHtmlFragment())

您可以在页面指令中使用参数 验证请求=“真”. 。通过这种方式,所有请求数据都会得到验证,如果存在验证问题,您始终可以捕获错误。它还可以防止 sql 注入线程和其他可能的 XSS。

对于数字数据,您可以使用 Int32.TryParse() 或任何其他 TryParse 系列 (Byte.TryParse Int16.TryParse...) 验证整数溢出或数据类型误用。

无需使用任何其他类或额外的消毒方法。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top