我的公司要求我们的ASP.NET代码在发布代码之前通过Fortify 360扫描。我们到处使用AntiXSS来清理HTML输出。我们还验证输入。不幸的是，他们最近更改了Fortify正在使用的“模板”，现在它将我们所有的AntiXSS调用标记为“糟糕验证”。这些调用正在执行AntiXSS.HTMLEncode（sEmailAddress）。
任何人都知道什么会满足Fortify？它标记的很多东西都是输出，其中值来自数据库而根本不是来自用户，所以如果HTMLEncode不够安全，我们根本不知道是什么！
答案 0 :(得分：7)
我是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）
答案 1 :(得分：4)
fd_dev，我想补充一点，你不应该专注于压缩你的代码以适应静态分析箍。如果您有资格并确信该发现不适用，请使用Fortify GUI工具记录评论并解决问题。
如果您不确定，请截取一些屏幕截图并通过电子邮件发送给Fortify技术支持。他们有资格就如何解释您的Fortify安全发现提供建议。
blowdart就是现货。如果您在不了解代码的目的和发现背后的原因/机制的情况下追逐静态分析结果，那么最坏的情况可以参见http://www.schneier.com/blog/archives/2008/05/random_number_b.html。 （总之，你可以让代码变得更糟而不是更好） - ：
答案 2 :(得分：1)
我们找到了解决方案。信不信由你，这导致Fortify360接受代码。
string sSafeVal = Regex.Replace(sValue, @"[\x00-\x1F\x7F]+", "");
Response.Write AntiXSS.HTMLEncode(sSafeVal);
因此，单独AntiXSS.HTMLEncode失败时，替换不可打印的字符会起作用。没关系HTMLEncode会这样做的事实。我猜他们只是触发了Regex.Replace，我想任何模式都可以。