Cross-site scripting (XSS) is a common vulnerability that is carried out when an attacker injects malicious JavaScript into a website, which then targets the website’s visitors. By doing so, the attacker may gain access to users’ cookies, sensitive user information, as well as view and/or manipulate the content that is shown to the user. This is not another article explaining what XSS is, why it is a security issue and how to fix it because we have already covered that. This article goes into the details of the different types of XSS attacks and what happens in each scenario.

Reflected XSS means that the payload is reflected, i.e. the server reads it from the request and includes it as part of the response as well.

/search.php?q=

hello

would be an example that then shows up on the page.

An attack like this requires getting the user to click on a link that includes the payload. There are several ways to achieve this; sending the link as an email or buying advertisements on a website that you know the victim is going to visit are two potential ways.

Persistent or Stored XSS means that the payload is saved on the actual page, not in the request that is then reflected. If we assume this would also occur in a search function, it could, for example, be in a list of recent popular search terms.

";
	foreach ($terms as $term) {
		echo "$term 
";
	}
?>

As the malicious JavaScript is saved on the page, this attack does not necessarily require you to send the victim any specific link. It depends on where on the page it is saved. If the XSS is in the latest searches you can just wait until the victim uses the search function by themselves. However, if it is stored in a specific forum thread you might need to send the victim a link to that post.

When you visit a website, the server generates some HTML and JavaScript which it sends back to your browser. Your browser will then interpret all this and you will see the result on your screen. JavaScript can modify what you see and this is also called modifying the DOM (Document Object Model).

DOM XSS is the catch-all term for when the attacker’s JavaScript is not interpreted directly as a result of the source you get from the server, but rather ends up being interpreted after existing JavaScript on the page has modified the DOM to include it.

Let’s continue with the search example. This could be a function that uses JavaScript to read the value from the current URL and then writes it onto the page. This would then lead to a similar vulnerability as with the reflected XSS, but this time it will be called a DOM XSS.

DOM XSS could be much more complex than this. The JavaScript does not have to read the value from the URL, there are lots of other potential sources. Two examples would be postMessage or that the javascript sends a xhr-request to another API.

If a DOM XSS reads the value from the URL this similarly to reflected XSS requires you to share a specific link with the victim to exploit it. However, if it is caused by the server sending an API request to get the latest search terms, the impact would be similar to the persistent XSS.

Is your website vulnerability to a XSS attack? Scan for 1000+ known vulnerabilities including XSS by using Detectify today. Sign up for your 14-day  free trial and check your status.