Contact Us

What is Cross-site Scripting?

In this post we are going to cover what XSS is, some examples of XSS and how you can prevent it.

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.
    • JavaScript takes data from an attacker-controllable source, such as the URL, and transfers it to a sink that supports dynamic code execution, resulting in DOM-based XSS vulnerabilities. (This is harder to explain)

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…

The section of the website which is vulnerable is the ‘track-orders’ function. In the below image, we have inserted the following JavaScript code.

Which results in the following alert() box popping.

A JavaScript alert box appears as a result of the malicious code input.

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

In this example we will be using portswigger’s web security academy as our vulnerable example. This lab contains a blog post which allows the user to submit a comment. The JavaScript code we will be submitting to the blogs comment section enables us to actually steal session cookies. This becomes possible when the user views the page after we have placed our malicious code into the comment section.

Let’s take a look at the blog page comment section.

It’s pretty standard stuff. We can see that the blog allows for the user to submit a comment. Now obviously we won’t be telling the writer what a great piece it was, instead, we will be submitting some malicious JavaScript code to steal the authentication cookies.

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.

secret=KsM3VgEqXthfWYMjpW7iMJXqCMl1IqaH; session=Zw6ttoAstEtZhRMjO6LjVp7fmC0oIkLC

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:

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 penetration testing.

Contact us to find out about this service.