Cross-Site Scripting (XSS) attacks are injection attacks in which malicious scripts execute in otherwise trustworthy and innocuous websites. Cross-Site Scripting 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 that can occur on a web application.
- Reflected XSS
- Reflected Cross-Site Scripting 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 Cross-Site Scripting 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 Cross-Site Scripting. 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 received a request to our burp collaborator tool. Now it is absolutely critical to understand this is an 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.
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 Cross-Site Scripting 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
If you are concerned about security vulnerabilities in your web application. We can help with that. Our Web Application Penetration Test is conducted to the OWASP standard for web application penetration testing.
Contact us to find out about this service.
Frequently Asked Questions
Web applications can be tested for cross-site scripting vulnerabilities through a web-application penetration test. Web application vulnerability scanners can also be used, such as OWASP ZAP and Burpsuite. However, relying on scanners is not usually enough to verify if the application is vulnerable to cross-site scripting. Vulnerability scanners are prone to false positives, and will only check to see if the vulnerability exists. A penetration tester will aim to exploit the cross-site scripting vulnerability to its full potential.