One of the most common flaws in web applications is  Cross Site Scripting (XSS).  All too often the risk with XSS is undermined, and ends up going to the bottom of the priority list because system owners do not fully understand the potential impact.

This three (3) part blog post will hopefully change that thought process by educating readers on some attack scenarios that are possible by exploiting XSS flaws.  We aren’t planning on going into all things XSS, so if you want to learn more we suggest heading over to OWASP

  • Part 1 will cover an overview and introduction to XSS
  • Part 2 will cover how to enumerate XSS vulnerabilities
  • Part 3 will cover how to exploit XSS vulnerabilities

Before we go too far, let’s first define XSS. XSS is a type of web application flaw that allows an attacker to inject client-side code (usually HTML/JavaScript) into a web application. The most trivial example of this is the use of HTML script tags (), and JavaScript alert() method:

[code lang=”py”] <script>alert(1)</script> [/code]

This trivial example has led to the false perception of risk with XSS. If you are new to XSS you might be asking yourself “So what, an alert box….”. Hold on, and keep reading because we plan to open your eyes to the real risk. XSS allows an attacker to leverage the trust relationship a user has with a web application to run malicious code on their web browser. With respect to exploitation and risk, there are a few things to consider:

    1. Is the XSS vulnerability stored or reflective?
    2. Where is the XSS flaw?
    3. What type of XSS payloads are possible?
    4. Does the application utilize input validation or output encoding?
    5. Is the XSS payload only effective on certain browsers?

Stored vs. Reflective XSS:

Stored XSS means that the attacker supplied code remains on the web application, and could impact any user that loads that content.  An example of this could be a comment feature on a web application that doesn’t properly handle user input, and allows for a comment to add client-side code to the page.  Stored XSS has elevated risk because the code remains on the web application, and anyone who loads the affected page would potentially be impacted. Reflective XSS is when code is dynamically added to the page based on user supplied input.  This code does not remain on application, but still presents risk because an attacker can craft a malicious link using the trusted web application.  An example of a reflective XSS flaw could be a search feature that accepts user input via a GET parameter and adds the user input to the page:

[code lang=”py”]http://example_url/index.php?query=’>">[XSS_Payload][/code]

Where is the XSS Flaw:

To exploit reflective XSS reliably, you’d need to craft a link and have the user click on it.  This is why we brought up item 2.  If the XSS flaw is in an HTTP GET parameter it is far easier to exploit, but if the flaw is in an HTTP header value, or POST parameter these are much harder exploit. HTTP GET: A request to retrieve data from a resource or page Header and HTML file (body). Below demonstrates a basic example of passing a reflective XSS payload via the URI of a GET request via the “id” parameter.

HTTP POST: A request that the server accepts the entity enclosed within its contents often used to make entries in forums, upload files, mailing list, comment threads or additions to a database. Below demonstrates a basic example of passing a stored XSS payload via the body of a POST request via the “comment” parameter.

Other things to consider that might impact the risk of the flaw:

  • To exploit the flaw does the user have to be authenticated?
  • Is the flaw on a high impact web application for the target organization?
  • Is the XSS payload limited in it’s attack vectors due to input validation?
  • Can you inject your XSS payload in the URI of a link?

What type of XSS payloads are possible: For the purposes of this blog we won’t dive too deep into bypassing XSS controls and filters.  It is just important to know that web applications incorporate user input in many ways, and depending on the way it’s using the input, and XSS controls/filters certain payloads may not work. An example of this would be ColdFusion has built-in XSS protections against HTML script tags ().  The framework will replace the first script tag with “”, which will break the XSS payloads that rely on HTML script tags.  To get around this you have no shortage of options – Reference OWASP XSS Filter Cheat Sheet, one example would be:

[code lang=”python”]<IMG SRC="javascript:alert(1)">[/code]

XSS payloads may only be effective on certain browsers:

When utilizing a XSS vulnerability first the web application must process the payload followed by the user’s web browser. A user’s web browser will often render web content differently and have various security settings built-in based on their browser type and version. Many times XSS payloads can be prevented by a web browser via enhanced security settings or plugins.