asp.net - AntiXss.HtmlEncode 和 HttpUtility.HtmlEncode 有什么区别？

Question

我刚刚遇到一个问题，其答案建议使用 AntiXss 库以避免跨站点脚本。听起来很有趣，阅读 msdn blog ，它似乎只提供了一个 HtmlEncode() 方法。但我已经使用了 HttpUtility.HtmlEncode()。

为什么我要使用 AntiXss.HtmlEncode 而不是 HttpUtility.HtmlEncode？

的确，我不是第一个提出这个问题的人。而且，确实，谷歌出现了some answers , 主要是

白名单代替黑名单方法

0.1ms 的性能提升

嗯，这很好，但这对我意味着什么？我不太关心 0.1ms 的性能，我真的不想为我已经拥有的功能下载和添加另一个库依赖项。

是否存在 AntiXss 实现可以防止 HttpUtility 实现无法阻止的攻击的示例？

如果我继续使用 HttpUtility 实现，我是否有风险？怎么样 this 'bug' ?

Answer 1

我没有专门针对您的问题的答案，但我想指出白名单与黑名单的方法不仅仅是“好”。这一点很重要。很重要。在安全方面，每一件小事都很重要。请记住，使用跨站点脚本和 cross-site request forgery ，即使您的网站没有显示敏感数据，黑客也可以通过注入(inject) javascript 来感染您的网站，并使用它从另一个网站获取敏感数据。因此，正确地做是至关重要的。

OWASP guidelines specify using a white list approach . PCI 合规性指南也在编码标准中指定了这一点(因为它们引用了 OWASP 指南)。

此外，较新版本的 AntiXss 库有一个不错的新功能:.GetSafeHtmlFragment()，这对于您希望将 HTML 存储在数据库中并将其作为 HTML 显示给用户的情况非常有用。

此外，对于“错误”，如果您正确编码并遵循所有安全准则，则您使用的是参数化存储过程，因此单引号将被正确处理，如果您没有正确编码，则不书架图书馆将全面保护您。 AntiXss 库旨在成为一种使用工具，而不是知识的替代品。依靠图书馆为您做正确的事情，您会期望一个非常好的画笔在没有好的艺术家的情况下制作出好的画作。

编辑 - 添加

正如问题中所问的，反 xss 将保护您而 HttpUtility 不会保护您的示例:

HttpUtility.HtmlEncode and Server. HtmlEncode do not prevent Cross Site Scripting

不过，这是作者的说法。我没有亲自测试过。

听起来您已经遵守了安全准则，所以这可能不是我需要告诉您的事情，但以防万一经验不足的开发人员正在阅读本文，我说白名单方法至关重要的原因这是。

现在，今天，HttpUtility.HtmlEncode 可以成功阻止所有攻击，只需删除/编码 <和 > ，加上一些其他“已知的潜在不安全”字符，但总有人试图想出新的闯入方式。只允许已知安全(白名单)的内容比尝试考虑所有可能的不安全内容要容易得多输入攻击者可能会扔给你(黑名单方法)。