When it comes to dynamic scanning & black box testing techniques, speed and accuracy are critical factors. Developers and security teams have no time for false positives, especially in a world where the time between releases is increasingly compressed. Yet a common vulnerability found by dynamic scanners is Cross-Site Scripting (XSS), and these vulnerabilities are often either false positive or missed due to poor coverage.
So why does this matter? Well, first, more injection points (i.e., the parameters or arguments where attacks can be inserted) means there may be more ways to attack the user via XSS attacks. For dynamic scanners, this means there is more for the dynamic scanner to test – thus creating the potential for longer scan times.
Traditional approaches may send a barrage of attack strings to a specific parameter, hoping for at least one of them to fire. This could be an XSS attack library of several dozen varieties. While this is one way to detect XSS, it’s horribly inefficient:
- It significantly increases the number of requests sent by the scanner, increasing the scanner’s time spent “doing work.”
- It assumes that one of the attacks in the XSS library is sufficient to trigger the XSS – which isn’t always the case. Thus, this approach can also lead to false negatives.
The Veracode Approach
So how has Veracode solved this problem?
Second, Veracode focused on speed. To do this, Veracode analyzed the different ways an XSS can trigger a vulnerability and narrowed this down to three contexts: HTML Element, HTML Attribute and Script contexts.
What’s context? Context refers to the location of a Cross-Site Scripting attack within the Document Object Model (DOM). The DOM is basically the structure of the web page – some examples below:
HTML Element context: The attack cleanly falls between two HTML tags
HTML Attribute context: The attack falls within an attribute of an HTML tag
<a href=""><script>alert(‘XSS here’)</script></a>
To do this efficiently, Veracode developed an automated way to perform “Context Aware” Cross-Site Scripting tests. What this means is we’re able to analyze injection points and understand how data enters the web app and where it ends up in the DOM. Here’s a simple example:
GET /home.jsp?name=<script>alert(‘XSS here’)</script>&phone=555-555-1234 <html> <head> <title>Welcome</title> </head> <body> <h1>Welcome, <script>alert(‘XSS here’)</script></h1> <p>Thank you for logging in!</p> </body> </html>
Clearly, this is an XSS attack, but the important thing here is Veracode understands this as an XSS attack within the HTML Element context.
So what does Veracode do with this information? By understanding context, Veracode can calculate the exact attack string required to trigger a vulnerability. And this is the secret to improving performance and accuracy:
- Calculating the exact attack string reduces the chance of false negatives – since there is no “guessing.”
- Calculating the exact attack string improves performance – since the number of attacks required to reproduce the XSS issue goes from several dozen to only a few – lessening the number of requests needed to be sent by the scanner
A more complicated case: Script Context
Consider this example in PHP:
In this case, Veracode’s patent-pending technology would determine that an attack string with
Dynamic scanning is an important step in preventing application vulnerabilities. While it is certainly useful in the production and pre-release phases of the SDLC, it needs to work with a degree of performance and accuracy demanded by today’s Single Page Application architectures and development and security teams. Expect to hear more about what Veracode is doing in this space as part of our ongoing blog posts about Web Application Scanning.