我刚刚遇到一个问题，其答案建议使用 AntiXss 库以避免跨站点脚本。听起来很有趣，阅读msdn 博客，它似乎只是提供了一个 HtmlEncode() 方法。但我已经使用了 HttpUtility.HtmlEncode()。
为什么我要使用 AntiXss.HtmlEncode 而不是 HttpUtility.HtmlEncode？
的确，我不是第一个提出这个问题的人。而且，确实，谷歌提供了一些 答案，主要是
嗯，这很好，但这对我意味着什么？我不太关心 0.1ms 的性能，我真的不想为我已经拥有的功能下载和添加另一个库依赖项。
是否存在 AntiXss 实现可以防止 HttpUtility 实现无法阻止的攻击的示例？
如果我继续使用 HttpUtility 实现，我是否有风险？这个“虫子”呢？
我没有专门针对您的问题的答案，但我想指出白名单与黑名单的方法不仅仅是“好”。这一点很重要。很重要。在安全方面，每一件小事都很重要。请记住，使用跨站点脚本和跨站点请求伪造，即使您的站点没有显示敏感数据，黑客也可以通过注入 javascript 来感染您的站点，并使用它从另一个站点获取敏感数据。因此，正确地做是至关重要的。
OWASP 指南指定使用白名单方法。PCI 合规性指南也在编码标准中指定了这一点（因为它们参考了 OWASP 指南）。
此外，较新版本的 AntiXss 库有一个不错的新功能：.GetSafeHtmlFragment()，这对于您希望将 HTML 存储在数据库中并将其作为 HTML 显示给用户的情况非常有用。
此外，对于“错误”，如果您正确编码并遵循所有安全准则，则您使用的是参数化存储过程，因此单引号将被正确处理，如果您没有正确编码，则不书架图书馆将全面保护您。AntiXss 库旨在成为一种使用工具，而不是知识的替代品。依靠图书馆为您做正确的事情，您会期望一个非常好的画笔在没有好的艺术家的情况下制作出好的画作。
编辑 - 添加
正如问题中所问的，反 xss 将保护您而 HttpUtility 不会保护您的示例：
HttpUtility.HtmlEncode 和服务器。HtmlEncode 不会阻止跨站点脚本
不过，这是作者的说法。我没有亲自测试过。
听起来您已经遵守了安全准则，所以这可能不需要我告诉您，但以防万一没有经验的开发人员在那里阅读本文，我说白名单方法至关重要的原因这是。
现在，今天，HttpUtility.HtmlEncode 可以成功阻止所有攻击，只需删除/编码<和>，加上一些其他“已知的潜在不安全”字符，但总有人试图想出新的闯入方式。只允许已知安全（白名单）内容比尝试考虑攻击者可能向您抛出的每一个可能的不安全输入（黑名单方法）要容易得多。
至于为什么要使用其中一个，请考虑 AntiXSS 库比 ASP.NET 框架更频繁地发布 - 因为，正如 David Stratton 所说，“有人总是试图想出新的闯入方式”，当有人提出一个 AntiXSS 库时，更有可能获得更新版本来防御它。
Microsoft.Security.Application.AntiXss.HtmlEncode以下是和方法的区别 System.Web.HttpUtility.HtmlEncode：
Anti-XSS 使用白名单技术（有时称为包含原则）来提供针对跨站点脚本 (XSS) 攻击的保护。这种方法的工作原理是首先定义一组有效或允许的字符，然后对该组之外的任何内容（无效字符或潜在攻击）进行编码。System.Web.HttpUtility.HtmlEncode该命名空间中的其他编码方法使用排除原则，并且仅对指定为潜在危险的某些字符进行编码，例如 <、>、& 和 ' 字符。
Anti-XSS 库的白色（或安全）字符列表支持十几种语言（希腊语和科普特语、西里尔语、西里尔语补充语、亚美尼亚语、希伯来语、阿拉伯语、叙利亚语、阿拉伯语补充、Thaana、NKo 等）
Anti-XSS 库专门设计用于缓解 XSS 攻击，同时HttpUtility创建编码方法以确保 ASP.NET 输出不会破坏 HTML。
AntiXss.HtmlEncode()性能 - 每个事务之间的平均增量HttpUtility.HtmlEncode()为 +0.1 毫秒。
Anti-XSS 3.0 版提供了一个测试工具，允许开发人员运行 XSS 验证和性能测试。
大多数 XSS 漏洞（实际上是任何类型的漏洞）纯粹基于现有安全性并未“预期”某些事情会发生的事实。默认情况下，仅白名单方法更倾向于处理这些场景。
我们对 Microsoft 的 Windows Live 站点使用白名单方法。我确信有很多我们还没有想到的安全攻击，所以我更喜欢偏执的方法。我怀疑有些情况是黑名单暴露了白名单没有的漏洞，但我不能告诉你细节。