Fortify和AntiXSS

fd_*_*dev 4 c# asp.net html-encode antixsslibrary fortify

我的公司要求我们的ASP.NET代码在发布代码之前通过Fortify 360扫描.我们到处使用AntiXSS来清理HTML输出.我们还验证输入.不幸的是,他们最近更改了Fortify正在使用的"模板",现在它将我们所有的AntiXSS调用标记为"糟糕验证".这些调用正在执行AntiXSS.HTMLEncode(sEmailAddress).

任何人都知道什么会满足Fortify?它标记的很多东西都是输出,其中值来自数据库而根本不是来自用户,所以如果HTMLEncode不够安全,我们根本不知道是什么!

小智 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 )

  • 对不起,这只是使用扫描引擎类型的自动化工具问题的一个很好的例子.AntiXss是所有上下文的正确解决方案,尽管有OWASP文章 - 它明确指出虽然*HTML*编码不够,但根据正确的上下文编码**是** - 这些是由AntiXss提供的.问题是Fortify无法检测到正确的上下文,并且由于无法确定使用哪种方法(如您所述). (3认同)

fd_*_*dev 1

我们找到了解决方案。不管你相信与否,这会导致 Fortify360 接受该代码。

string sSafeVal = Regex.Replace(sValue, @"[\x00-\x1F\x7F]+", "");
Response.Write AntiXSS.HTMLEncode(sSafeVal);
Run Code Online (Sandbox Code Playgroud)

因此,当 AntiXSS.HTMLEncode 单独失败时,替换不可打印字符就可以了。没关系 HTMLEncode 无论如何都会这样做。我猜他们只是触发 Regex.Replace 并且我想任何模式都可以工作。