我的公司要求我们的 ASP.NET 代码在发布代码之前通过 Fortify 360 扫描。我们到处都使用 AntiXSS 来清理 HTML 输出。我们还验证输入。不幸的是，他们最近更改了 Fortify 使用的"template"，现在它将我们所有的 AntiXSS 调用标记为“Poor Validation”。这些调用正在执行 AntiXSS.HTMLEncode(sEmailAddress) 之类的操作。
有谁知道究竟什么会满足 Fortify？它标记的很多内容都是输出，其中值来自数据库，而根本不是来自用户，所以如果 HTMLEncode 不够安全，我们不知道是什么!
最佳答案
我是 Fortify 安全研究小组的成员，对于这个问题给您造成的困惑，我深表歉意。我们在提出此类问题方面做得并不好。我认为问题的一部分是类别名称——我们并不是想说验证机制有什么问题，只是我们无法判断它是否适合这种情况。
换句话说，我们不知道针对您的特定上下文的正确验证是什么。出于这个原因，我们不认为任何 HTML 编码功能可以验证开箱即用的 XSS，即使是 Microsoft 的 AntiXSS 库中的功能。
至于正确的解决方案是什么，如果您使用 HtmlEncode 将用户名输出到 HTML 页面的正文，那么您的原始代码就可以了。如果在 URL 中使用了编码的用户名，则它可能容易受到 XSS 的攻击。在 Fortify，当我们在自己的代码中发现类似问题时，如果验证与上下文匹配，我们会将其标记为“不是问题”。
我们意识到围绕这些问题的问题不断调整我们的规则，使其更加精确和易于理解。我们每三个月发布一次新规则，并希望在即将发布的版本中进行一些更改。对于第 4 季度，我们计划将问题分为验证不足(用于将编码和其他弱验证方案列入黑名单)和上下文敏感验证(您看到的问题类型)。如果我们能提供更多帮助，请告诉我们。
(关于为什么 HTML 编码不能解决所有问题的 OWASP 解释的链接:
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F )