Fortify360 - Sinks & Sources - Vulnerability count

Question

In an application security environment, I use Fortify Software's Fortify360 on a daily basis.

One of my biggest hurdles is explaining the numbers (sources vs sinks)

Fortify flags each location in the source code where unvalidated data is displayed to a user as a Cross-Site Scripting vulnerability.

Let's assume there are 300 locations (sinks) where unvalidated data is displayed to the user. Of those 300 sinks, the data is ALL pulled from a database utilizing one function. (source)

Fortify will subsequently report that there are 300 Cross-Site Scripting vulnerabilities. What it doesn't explicitly tell you is that 300 of which may potentially be fixed from the same location.

My question to you, from an Application Security Engineer point of view, do you then report to your client that there are 300 Cross-Site Scripting vulnerabilities, or 1 Cross-Site Scripting vulnerability? Are either of those statements accurate?

Do you report the source, or the sink?

What I am currently doing is reporting that there are 300 POTENTIAL Cross-Site Scripting vulnerabilities which may all be fixed within one function/method.

Is it more accurate to say that there is 1 Cross-Site Scripting vulnerability which is exposed in 300 locations?

I realize some of this is subjective, but I'm looking for input from others in the field who can shed some light on their methods.

Answer 1

I would almost always state this as one vulnerability which shows in 300 places - especially if this was part of a wider report where there may be 50, 100 or more vulnerabilities, otherwise you end up with a report as thick as a book which no-one can ever take action on.

Think of it from the audience side - they'll want to know their exposure to risk and what they can do about it. Their action will be to assign an individual or team to make the fix, so they'd rather be told there is one issue they need to fix - the 300 instances where it crops up may make it a higher priority for them than a vulnerability with one visible instance, but the remediation may be the same.

Answer 2

I'd reiterate AviD's reply - Cross Site Scripting is generally better solved as a context sensitive output encoding problem, rather than an input validation problem. If you're trying to solve it as an input validation problem, you're going to be encouraging a black list input validation approach in many cases, or if you're using a white list approach you may not be able to get these as tightly constricted as you'd like.

Also - what you'll need to handle for each output encoding context (HTML, attributes, CSS, JavaScript) will be different, so I'd advise you steer the development team to something that does the encoding for them like Microsoft's WPL (Web Protection Library) or OWASP ESAPI or OWASP Reform for other languages.

Answer 3

My personal preference (and please keep in mind that I work for a vendor, IBM, but it's my own opinion) is that the optimum reporting method for remediation is to provide the source and the sink.

I would say that this is particularly the case in the .NET framework where different output controls (sinks) encode the data passed to them differently and different input controls (sources) do not always unencode the data from its url encoded form.

With Java you don't usually see quite so much variability, however, I think you still must take into account both the source and the sink before deciding on an optimum fix.

Answer 4

In my opinion it both matters and doesn't matter where the XSS is, and how it can be utilized.

It doesn't matter because any XSS is dangerous to some degree.

It does matter because an XSS in an innocuous looking URI and param structure is bound to lead to more phishes. In many ways (from an attacker perspective), it's better to have an XSS available on a page that is available to both authenticated and non-authenticated visitors/users of an application or infrastructure.

When you phrase this differently as SQLi instead of XSS -- the situation becomes much more relevant and easy to understand. Each instance of SQLi could be turned into an exercise of exploitability. Blind SQLi is often more difficult to exploit, but it doesn't matter -- the real key is what data or unauthorized access has been exposed by each individual SQLi flaw. CVSS and DREAD come to mind, but really this should be even more optimized like CWSS and STRIDE.

So -- to answer your question -- the determination should be an exercise in appsec risk management. There will likely be somewhere more than 1 and perhaps even less than 300 individual findings per vulnerability category. I prefer to speak about them as software weaknesses, but this may vary depending on your target audience. Customization to your target audience is always important when presenting information, especially in report writing efforts.

Again, whether or not to list the source or sink (or both) depends on the target audience. If I was receiving the report, I'd want to see both -- but that's because I'm a deep technical assessor of applications. The sink is most useful to most developers -- and it may allow them to focus on the root cause problem -- i.e. Encoding (in the case of XSS and SQLi) -- however, there may be other remediation and defense-in-depth strategies to put forward for developers as well as DBAs, sysadmins, managers, and whoever else is involved in the application and system lifecycles.

So my answer is that this answer is highly dependent on perhaps thousands or millions of other factors.

Answer 5

The answer is: it depends.

One design discipline is to consider all data in the database as untrusted and sanitized, so that it is the responsibility of the code that's outputting HTML to encode or escape it properly before including it in HTML output. If that's the approach your project has taken, then this is 300 bugs. This is a fairly common way of structuring a web application.

Another design discipline is to sanitize all data before storing it in the database, so that we know that data stored in the database is safe for outputting in all plausible HTML contexts (HTML, attributes, CSS, Javascript). If this is the discipline that your programmers are following, then what you want to know is if there is any place in the code that stores data in the database without first encoding/escaping/sanitizing it properly. In this case, you might have one bug, or you might have many bugs.

A more general design discipline is to have a different invariant for each field in the database: some of them have been pre-sanitized before storing in the database (and maybe for different contexts: e.g., one field might hold pre-escaped or trusted HTML, another might hold a pre-escaped string suitable for inclusion in Javascript), and some haven't and will need to be escaped/sanitized on the output side. In this case, you'll need to look at what invariant the program is maintaining about the particular field in the database that's associated with the XSS vulnerabilities you found.

A fourth approach, and probably the most common one, is to have no discipline at all. This is bad news for security.

So, I think I'd start by trying to understand whether the developers of the software have adopted any systematic strategy for defending against XSS. If they haven't adopted any systematic strategy, there's the root problem (you can report a few bugs, but they are a symptom of a more fundamental and serious problem: the lack of any disciplined defense against XSS). If they have adopted a systematic strategy, then once you have figured out what that strategy was and what the intended invariants were, you'll be in a better position to write useful bug reports.

Answer 6

I think the question is not whether it is 300 sinks or 1 source, but it is that you are vulnerable and you should fix this. So instead of going to your customer to justify we have 300 XSS exposure or 1 vulnerability, you should fix it and have no vulnerability. That should be the stance of a security engineer.