Fortify and AntiXSS

Question

My company requires our ASP.NET code to pass Fortify 360 validation before releasing the code. We use AntiXSS everywhere to sanitize HTML output. We also check input. Unfortunately, they recently changed the “template” that Fortify used, and now it puts all of our AntiXSS calls as “Poor Validations”. These calls do things like AntiXSS.HTMLEncode (sEmailAddress).

Does anyone know exactly what Fortify will satisfy? Much of what is marked is displayed where the value comes from the database and never from the user at all, so if HTMLEncode is not secure enough, we don’t know what it is!

Answer 1

I am a member of the Fortify Security Research Group and I regret the confusion caused by this issue. We did not deal very well with this issue. I think that part of the problem is the name of the category - we are not trying to say that there is something wrong with the check mechanism, we just can’t say whether this is a suitable check for this situation.

In other words, we don’t know what the correct check is for your specific context. For this reason, we don’t recognize any HTML encoding features, as we test XSS out of the box, even those contained in the Microsoft AntiXSS library.

As for the correct solution, if you use HtmlEncode to output the username to the body of the HTML page, your source code is fine. If the encoded username is used in the URL, it may be vulnerable to XSS. In Fortify, when we find similar problems in our own code, if the check matches the context, we mark it “Not a problem”.

We are aware that the problems associated with these problems are constantly improving our rules to make them more accurate and understandable. We release new rules every three months and expect to make a couple of changes to upcoming releases. For Q4, we plan to divide the problems into inadequate verification (for coding a blacklist and other weak verification schemes) and Context Sensitive Validation (the type of problem you see). Please let us know if we can help more.

(link to an explanation of OWASP why HTML encoding does not 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 )

Answer 2

fd_dev, I would add that you should not focus on compressing your code so that it matches the elements of static analysis. If you are qualified and confident that the search is not applicable, use the Fortify GUI tools to record a comment and suppress the problem.

If you are unsure, take a small screenshot and email it to Fortify Technical Support. They are well qualified to advise you on how to interpret your Fortify security evidence.

blowdart is the place. See http://www.schneier.com/blog/archives/2008/05/random_number_b.html in the worst case of what can happen if you pursue the results of a static analysis without understanding the purpose of the code and the reason / mechanics behind the find. (In a word, you can make the code worse, not better) -:

Answer 3

We have found a solution. Believe it or not, that's why Fortify360 accepts the code.

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

So, when AntiXSS.HTMLEncode itself fails, the replacement of non-printable characters works. Ignore the fact that HTMLEncode will do this anyway. I assume that they just run Regex.Replace, and I think that any template will work.