Cross-Site Scripting (XSS) attacks are injection attacks in which malicious scripts execute in otherwise trustworthy and innocuous websites. XSS attacks occur when an attacker uses a web application to send malicious code to a particular end user, usually in the form of a browser side script.
The weaknesses that allow these attacks to succeed are common and can be found anywhere a web application uses user input in its output without validating or encoding it.
There are three main types of XSS attacks which can occur on a web application.
- Reflected XSS
- Reflected XSS gets it’s name because it is reflected off a web server. This can occur via an error message, search results or some other method in which input is sent to the server then returned back to the user in some way.
- Stored XSS
- Stored attacks are those in which the injected script is held on the target servers indefinitely, such as in a database, a message board, a comment area, and so on.
- DOM XSS
Now we have definitions for each type, let’s take a look at some examples of XSS.
Example – Reflected Cross-Site Scripting
In this example we are using the OWASP Juice Shop. This is a purposefully vulnerable web application that contains a plethora of security vulnerabilities. It is perfect for the budding penetration tester to practice their skills, anyway, swiftly moving on…
Which results in the following alert() box popping.
This is a good example of reflected XSS. When we insert some malicious code into the ‘track-orders’ function it reflects back off the server.
Example – Stored Cross-Site Scripting
Let’s take a look at the blog page comment section.
The malicious code:
Wait what is going on here? The code itself is simply instructing the browser to grab the authentication cookies and post them to the following URL:
This is a URL that we control, therefore when the user views the blog page. The malicious code will grab the authentication cookies and post them to us (It is worth noting that the burpcollaborator tool is only available to Burpsuite Professional users).
Let’s now we have the concept down, we can submit our comment.
Great, now we have the malicious code on the site. We simply wait for anybody to view the blog……okay that’s enough time.
Around a minute or so later. We recieve a request to our burp collaborator tool. Now it is absolutely critical to understand this is a intentionally vulnerable lab, which is programmed to act as though a person has viewed the page. However, the concept and method is exactly how an attacker would orchestrate this type of attack. Let’s take a look at the HTTP request sent to it.
As suspected. A victim viewed the page and as a result, a request was made to the collaborator tool containing the session cookies of the person viewing the page. Just to clarify, this request will be made by every person viewing the page.
Who knew hacking was so fun.
Mitigating Cross-Site Scripting vulnerabilities
The following advice aims to be as general as possible. Preventing XSS issues can be both trivial, and complex. We highly recommend you take a look at the advice from OWASP on the matter. Details are provided at the bottom of this post
Preventing XSS general guidance:
- Filter input are the point in which it is recieved.
- Encode data on output.
- HTTP Response Headers can be used as a medium of preventing XSS. Use the Content-Type and X-Content-Type-Options. These will ensure that browsers only interpret the results as you intended.
- Finally, use the CSP Header (Content-Security-Policy). You should use Content Security Policy as a last line of protection to mitigate the seriousness of any remaining XSS vulnerabilities.
OWASP Cross-Site Scripting prevention guides:
- XSS (Cross Site Scripting) Prevention Cheat Sheet
- DOM based XSS Prevention Cheat Sheet
- Data Validation
Contact us to find out about this service.