Cross Site Scripting (XSS) – a peek on OWASP’s top ten list member

 Author - Sivakumar RR

Over the time web applications were so popular over desktop applications due to its ease of accessibility and not having a list of hardware / software requirements to use them. Minimum requirement for running the web application is limited to just the browser dependency, which made a lot of difference in building and releasing applications world wide, in short it made the process simpler and easier. As the saying “with great power, comes great responsibilities”, all the application providers are forced to look at the security and privacy implications of their user’s data. Web applications become popular in all domains which even trigger the “moving to cloud” trend for the old desktop applications as well. Social media applications played a key role for promoting this trend which also increased the number of users online. The more it became popular, the more it became the target. There are a lot of vulnerabilities which were present in the earlier days and over time it gets addressed and added to the boilerplate for the new application building process. The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. In this article we are going to take a peek on XSS vulnerability.

What is XSS?

Same Origin policy is something that is designed to segregate the web sites from each other. This allows the user or the browser which runs the application to trust all the information coming as part of the request response. XSS or Cross Site Scripting is something that can misuse this policy and compromise the user interaction in a vulnerable application. Since the attack will be happening on the client side or the user side it is possible to gather the user's data by manipulating the user action using some malicious script. If the user has privileged access to the application, it is possible to obtain control of the application or gather sensitive information.

How does XSS work?

Image Credit : PortSwigger

An attacker can use XSS to send a malicious script to user or a target and the browser will not have any suspicion and it will trust the script as Same Origin policy applies to it. This malicious script can manipulate the user action on the user side or capture information like cookie data, session information or other sensitive information.

Types of XSS

• Reflected XSS
• Stored XSS / Persistant XSS
• DOM XSS

Reflected XSS

Reflected attacks are something the injected script will be reflected off the web server. That is, in this case the full or the partial input which has been forwarded to the server will be coming as part of the output.

URL : https://bad-webapp.com/page?name=Tim

Response HTML : <p>Hello Tim</p>

Response Loaded : Hello Tim

Above mentioned code block is a normal request and response, you can see the URL parameter is “name” and the value passed is “Tim” so the response contains the name of the so it replaces the value with “Tim” in it, resulting “Hello Tim” as the output.

URL : https://bad-webapp.com/page?name=<u>Tim</u>

Response HTML : <p>Hello <u>Tim</u></p>

Response Loaded : Hello <u>Tim</u>

In the second block we have added a HTML underline tag as the value of the “name” and it responded with the tag itself in the output, this states that this site doesn’t have any XSS vulnerability since the code passed is printed as it is. If the response is something like this,

Hello Tim

So the above output is underlined with the user name which means the HTML code which has been sent along with request is considered as HTML given by the response and it rendered the HTML in the browser. Here where the red alert comes, now we can assume that this site is having XSS vulnerability and attackers can leverage this by just sending some script.
 

URL : https://bad-webapp.com/page?name=<script>alert(document.cookie</script>

Response HTML : <p>Hello <script>alert(document.cookie</script></p>

Response Loaded : Hello (with an alert of the cookie value)

The above code snippet can be used to test the XSS, if we sent this in the second example we have mentioned above the site will reload with an alert message that contains the cookie value.

Stored XSS

This is something where the payload which we shared as part of the request will be stored in the database / server itself and runs every time when it loads in the UI as part of the response. One of the famous Stored XSS findings is the Tweetdeck incident in Twitter where the script got stored in twitter servers as part of a tweet and each time when a user sees that tweet it will get retweeted in their accounts as well. Twitter had to stop the service for a while to fix this issue.

DOM XSS

This vulnerability occurs when a client side script processes the input in an unsafe way and updates it back to a DOM as part of the process. For example,

var input = document.getElementById('input_box').value;
var output_dom = document.getElementById('output_dom');
output_dom.innerHTML = 'You searched for: ' + input;

In this scenario, an attacker can modify the input and replace it with some malicious script so that the script can run as part of the process.

Impact of XSS

Impact of this attack can vary based on the application’s nature and how it handles the data. If the application handles the user data with anonymity then the impact will be very minimal. In the second scenario where the application having authentication and cookies are used to store any sensitive information then the impact will be more. In certain scenarios where the session of a privileged user is compromised then the impact can be critical.

How to prevent XSS?

XSS vulnerability is very tricky to find, the best way to identify these is performing a manual code scan and identify the user input locations in the application where the input data can potentially be the output of the request and format the response. There are tools like Nikto, Nessus and all which can run automated scans on the application and report back the issues, but this alone will not be sufficient to secure your application.

It is also advised to follow the best development practices like XXS Prevention Cheat Sheet by OWASP.