强化和 AntiXSS
我的公司要求我们的 ASP.NET 代码在发布代码之前通过 Fortify 360 扫描。我们随处使用 AntiXSS 来净化 HTML 输出。我们还验证输入。不幸的是，他们最近更改了 Fortify 使用的“模板”，现在它将我们所有的 AntiXSS 调用标记为“验证不佳”。这些调用正在执行诸如 AntiXSS.HTMLEncode(sEmailAddress) 之类的操作。
有人确切知道什么能让 Fortify 满意吗？它标记的很多内容都是输出，其中值来自数据库而不是来自用户，因此如果 HTMLEncode 不够安全，我们就不知道什么是安全！
My company requires our ASP.NET code to pass a Fortify 360 scan before releasing the code. We use AntiXSS everywhere to sanitize HTML output. We also validate input. Unfortunately, they recently changed the "template" Fortify was using and now it's flagging all our AntiXSS calls as "Poor Validation". These calls are doing things like AntiXSS.HTMLEncode(sEmailAddress).
Anyone know exactly what would satisfy Fortify? A lot of what it's flagging is output where the value comes from a database and never from a user at all, so if HTMLEncode isn't safe enough, we have no idea what is!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我是 Fortify 安全研究小组的成员，对于这个问题给您带来的困惑，我深表歉意。我们在提出此类问题方面还没有做得很好。我认为部分问题在于类别名称——我们并不是想说验证机制有什么问题，只是我们无法判断它是否适合这种情况。
换句话说，我们不知道对于您的特定上下文来说正确的验证是什么。因此，我们不认为任何 HTML 编码函数可以立即进行 XSS 验证，即使是 Microsoft AntiXSS 库中的函数也是如此。
至于正确的解决方案是什么，如果您使用 HtmlEncode 将用户名输出到 HTML 页面的正文，那么您的原始代码就可以。如果在 URL 中使用编码的用户名，则可能容易受到 XSS 攻击。在 Fortify，当我们在自己的代码中发现类似问题时，如果验证与上下文匹配，我们会将其标记为“不是问题”。
我们意识到围绕这些问题的问题，不断调整我们的规则，使它们更加精确和易于理解。我们每三个月发布一次新规则，并预计在即将发布的版本中进行一些更改。对于第四季度，我们计划将问题分为验证不足（针对黑名单编码和其他弱验证方案）和上下文敏感验证（您所看到的问题类型）。如果我们可以提供更多帮助，请告诉我们。
（关于为什么 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)
I'm a member of Fortify's Security Research Group and I'm sorry for the confusion this issue has been causing you. We haven't done a very good job of presenting this type of issue. I think part of the problem is the category name -- we're not trying to say that there is anything wrong with the validation mechanism, just that we cannot tell if it is the appropriate validation for this situation.
In other words, we don't know what the right validation is for your particular context. For this reason, we do not recognize any HTML encoding functions as validating against XSS out of the box, even the ones in Microsoft's AntiXSS library.
As for what the right solution is, if you are using HtmlEncode to output a username to the body of an HTML page, your original code is fine. If the the encoded username is being used in a URL, it could be vulnerable to XSS. At Fortify, when we find similar issues in our own code, if the validation matches the context, we mark it "Not an Issue".
We are aware of the problems around these issues keep tweaking our rules to make them more precise and understandable. We release new rules every three months and expect to make a couple changes in upcoming releases. For Q4, we plan to split the issues into Inadequate Validation (for blacklisting encoding and other weak validation schemes) and Context Sensitive Validation (the type of issue you're seeing). Please let us know if we can help more.
(A link to an OWASP explanation of why HTML encoding doesn't solve all problems:
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 安全调查结果向您提供建议。
吹镖是正确的。请参阅http://www.schneier.com/blog/archives/2008 /05/random_number_b.html 如果您在不了解代码的目的以及发现背后的原因/机制的情况下追逐静态分析结果，可能会发生什么最坏的情况。 （总而言之，你可能会让代码变得更糟而不是更好）-：
fd_dev, I would add that you shouldn't focus on squeezing your code to fit through static analysis hoops. If you are qualified and confident that the finding doesn't apply, use the Fortify GUI tools to record a comment and suppress the issue.
If you are not sure, take a little screenshot and email it to Fortify Technical Support. They are well qualified to advise you on how to interpret your Fortify security findings.
blowdart is spot on. See http://www.schneier.com/blog/archives/2008/05/random_number_b.html for the worst case of what can happen if you chase static analysis results without understanding the purpose of the code and the reason/mechanics behind the finding. (In a word, you could make the code worse instead of better)-:
我们找到了解决方案。不管你相信与否，这会导致 Fortify360 接受该代码。
因此，当 AntiXSS.HTMLEncode 单独失败时，替换不可打印字符就可以了。没关系 HTMLEncode 无论如何都会这样做。我猜他们只是触发 Regex.Replace 并且我想任何模式都可以工作。
We've found a solution. Believe it or not, this causes Fortify360 to accept the code.
So where AntiXSS.HTMLEncode alone fails, replacing non-printable characters works. Nevermind the fact that the HTMLEncode would do that anyways. I'm guessing they simply trigger off the Regex.Replace and I imagine any pattern would work.