Is Your Dynamic Scanning Context Aware?
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.
In addition, with the rise of Single Page Applications, Veracode has begun scanning more and more applications designed to deliver rich, native-like experiences using JavaScript frameworks like jQuery and AngularJS. Many enterprise apps are moving in this direction, exposing a great deal of UI functionality that ultimately leads to – you guessed it – more injection points!
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?
First, Veracode has taken a production-safe approach. This means the attacks sent by our scanner are not meant to trigger harmful or annoying scripts. For example, instead of sending an alert(), Veracode sends a special JavaScript function that is only recognizable by our scanner. This means, in the event of a persistent/stored XSS vulnerability, you won’t be triggering an ‘alert()’ to your users.
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.
Understanding Context
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
Example:
<p><script>alert(‘XSS here’)</script></p>HTML Attribute context: The attack falls within an attribute of an HTML tag
Example:
<a href=""><script>alert(‘XSS here’)</script></a>
Script context: The attack falls within JavaScript code
Example:
<script language=”javascript”>
function init() {
alert("");alert(“XSS”);
}
window.onload=init;
</script>
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
The solution goes one step further by also analyzing attacks within JavaScript blocks. If you have, let’s say, data printed within <script> elements, Veracode will automatically determine the right sequence of characters required to detect an XSS attack.
Consider this example in PHP:
<?php
//Gets the value from the 'name' parameter in a query string
$name = $_GET['name'];
echo <<<END
<script language=”javascript”>
function init() {
alert(“Welcome, {$name}!”);
}
window.onload=init;
</script>
END;
?>
In this case, Veracode’s patent-pending technology would determine that an attack string with “);alert(‘XSS’); would be successful in triggering a vulnerability. With JavaScript, there are myriad ways XSS could manifest, especially if the server is printing unsanitized/unescaped data directly into <script> elements. In this scenario, the traditional approach described above becomes very problematic, both from a performance and accuracy perspective.
Conclusion
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.
Related Posts
