Using SCA/AWB as a guiding tool

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.