我的公司要求我们的 ASP.NET 代码在发布代码之前通过 Fortify 360 扫描。我们在任何地方都使用 AntiXSS 来清理 HTML 输出。我们还验证输入。不幸的是，他们最近更改了 Fortify 使用的“模板”，现在它将我们所有的 AntiXSS 调用标记为“验证不良”。这些调用正在执行诸如 AntiXSS.HTMLEncode(sEmailAddress) 之类的操作。
任何人都确切地知道什么会满足 Fortify？它标记的很多内容都是输出值来自数据库，而根本不是来自用户，所以如果 HTMLEncode 不够安全，我们不知道是什么！
我是 Fortify 安全研究小组的成员，对于这个问题给您造成的困惑，我深表歉意。我们在提出这类问题方面做得不是很好。我认为问题的一部分在于类别名称——我们并不是要说验证机制有什么问题，只是我们无法判断它是否适合这种情况的验证。
换句话说，我们不知道对于您的特定上下文正确的验证是什么。出于这个原因，我们不承认任何 HTML 编码函数可以验证开箱即用的 XSS，即使是 Microsoft 的 AntiXSS 库中的那些。
至于正确的解决方案是什么，如果您使用 HtmlEncode 将用户名输出到 HTML 页面的正文，那么您的原始代码就可以了。如果在 URL 中使用了编码的用户名，则它可能容易受到 XSS 攻击。在 Fortify，当我们在自己的代码中发现类似问题时，如果验证与上下文匹配，我们将其标记为“不是问题”。
我们意识到围绕这些问题的问题不断调整我们的规则以使其更加精确和易于理解。我们每三个月发布一次新规则，并希望在即将发布的版本中进行一些更改。对于第四季度，我们计划将问题分为验证不足（用于将编码和其他弱验证方案列入黑名单）和上下文敏感验证（您看到的问题类型）。如果我们能提供更多帮助，请告诉我们。
（OWASP 解释为什么 HTML 编码不能解决所有问题的链接： http ://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F ）
fd_dev，我要补充一点，您不应该专注于压缩代码以适应静态分析箍。如果您有资格并且确信该发现不适用，请使用 Fortify GUI 工具记录评论并抑制问题。
如果您不确定，请截取一个小屏幕截图并将其通过电子邮件发送给 Fortify 技术支持。他们非常有资格就如何解释您的 Fortify 安全发现向您提供建议。
blowdart 就在眼前。请参阅http://www.schneier.com/blog/archives/2008/05/random_number_b.html了解如果您在不了解代码的目的和背后的原因/机制的情况下追逐静态分析结果可能发生的最坏情况发现。（总而言之，您可以使代码变得更糟而不是更好）-：
我们找到了解决方案。信不信由你，这会导致 Fortify360 接受代码。
string sSafeVal = Regex.Replace(sValue, @"[\x00-\x1F\x7F]+", "");
Response.Write AntiXSS.HTMLEncode(sSafeVal);
因此，在 AntiXSS.HTMLEncode 单独失败的地方，替换不可打印的字符是可行的。不要介意 HTMLEncode 无论如何都会这样做的事实。我猜他们只是触发 Regex.Replace 并且我想任何模式都可以工作。