We all know that static analysis tools produce their fair share of false positives. One example where static analysis tends to suffer is when an application uses custom cleansing logic to prevent cross-site scripting (XSS). In this scenario, SCA leaves it up to the auditor to determine whether a particular method performs adequate validation to negate a particular vulnerability.

In this situation, it can be tempting to discount all XSS issues where data passes through validation logic without looking at individual issues on a case-by-case basis. However, outputting data sanitized for cross-site scripting can still lead to potential security problems. For example, the code below output a cleansed string into an anchor tag's href attribute, which leads to open redirect vulnerabilities.

<meta http-equiv="refresh" content="1;url=<%=request.getAttribute("CLEANSED_STRING")%> "/>

or

<a href="<%=request.getAttribute("CLEANSED_STRING")%>">Click Me</a>
Here’s an example where outputting a sanitized string into the src attribute of a script tag is just as bad as cross-site scripting since it can allow attackers to source in arbitrary Javascript.

<script src="<%=request.getAttribute("CLEANSED_STRING")%>"></script>
So, a good tip when auditing Fortify SCA results is to avoid taking all of the results literally. If SCA reports cross-site scripting, also try looking for open redirects and dangerous file includes. Similarly, you can look for access control problems when auditing SQL injection or LDAP injection issues. By looking at issues more broadly, you might find vulnerabilities in places you've previous overlooked.

Another rulepack release is behind us. On August 31st the latest version of the Fortify Secure Coding Rulepacks (English language, version 2009.3.0.0006) became available from update.fortify.com and the Fortify Customer Portal. The new release contains quite a few improvements, including: support for ColdFusion 7 and 8, enhanced PL/SQL support, as well as improvements to our handling of a number of Java web frameworks – Axis 1 and 2, GWT, JSF, and Struts 2. It’s this final subject, web frameworks, that I want to talk about in this post.

The thing that bothers me the most about web frameworks is that their numbers grow faster than anyone’s full understanding of their advantages, disadvantages, security holes, or simply capabilities. How many Java web frameworks can you think of? What about templating engines, which are becoming more and more popular and provide integration with various existing web frameworks? What about Ajax component libraries? Did you get JSF, Spring, Struts 1 and 2, WebWork, Apache Beehive, WebObjects, JBoss Seam, Facelets, FreeMarker, Velocity, RichFaces, and IceFaces?

The list goes on and on. And even though the end-goal is always the same – a web application that consists of model, view, and controller layers – each of the frameworks has its own way of achieving this goal and each claims to be an improvement over existing ones. While older frameworks, such as Struts 1, require action classes to extend an abstract base class, newer frameworks, such as Struts 2, allow any POJO to be used as an action. While JSF, Struts 2 and WebWork use configuration files to define beans and actions, JBoss Seam and Apache Beehive use annotations. While Facelets uses XHTML files to define templates, FreeMarker uses proprietary FTL files and Apache Velocity uses its own proprietary VM files. The list of differences goes on even longer than the list of frameworks.

What a headache it is for the developers to keep all these differences straight, especially when upgrading from an older framework to a newer one or migrating from one to another! Switching between different structures of various configuration files, learning to apply annotations where none used to be necessary, and implementing views with the new proprietary templating language seem like very error-prone processes. No wonder frameworks misuse is so common! And a security auditor at a company where programmers can choose any and all frameworks will have to know the ins and outs of a huge technology landscape. So, what can reduce frameworks misuse, and, for that matter, software bugs and flaws? I believe the answer is straightforward – standardization of web frameworks. The fewer differences there are among the frameworks, the easier it will be for the developers to adopt a new framework. The more frameworks are built according to an accepted standard, the easier it will be to establish a set of common guidelines and best practices around their usage. And once such guidelines are in place, they can be enforced. But until then we need ways to capture and apply knowledge about a large number of frameworks, and this is an area where static analysis becomes particularly useful.