At AT&T Security Solutions, we perform hundreds of web application security penetration tests to find vulnerabilities — and one of the most commonly observed is Cross-Site Scripting (XSS).

Recently, however, newer applications using these technologies tend to be relatively better off in terms of proliferation of these vulnerabilities. This is due, partly, to the use of libraries, such as the OWASP ESAPI library and Microsoft Anti-XSS library (ASP.Net request validator library). Note that vulnerabilities still exist despite using these libraries. Now, why is that?

When do libraries fall short?

A very common web application function is when user input becomes a part of the script components of the web application source code.  When XSS validators like the ones in ASP.Net are used, characters input by users — including double quotes and “less than” or “greater than” characters — get escaped such that they do not alter the source of the HTTP response page.

There are two specific cases where these libraries, especially like ASP.Net request validators, might fall short. This depends upon how your application utilizes them.  If the user input makes it straight into the JavaScript section, as an attacker, you don’t need to have characters such as “less than,” “greater than,” and double quotes included to exploit this vulnerability.

The second case is when the application has more than one input stream. In this case, the database might include characters that distort the HTML page structure.  In such situations, the ASP.Net request validators may not help you much.

The bottom line? Be careful of how your applications process user input and always include different sources of data in your threat model.  During design phases, if input does not go through the “validation routines,” then that might be a source of input validation vulnerabilities in the application.

Lesson:

Do not assume that using a library will fix all your cross-site scripting woes.  The secret sauce lies in understanding when the libraries will work.

Have you noticed such vulnerabilities in your web applications?  Do you know other ways to solve these issues easily?