Cross-site scripting (XSS) vulnerabilities can compromise sensitive information and enable unauthorized actions in browsers. This article covers XSS vulnerabilities, how to prevent them, and resources to mitigate them.

On this page:

• What is cross-site scripting (XSS)?
• What can malicious JavaScript do?
• What causes an XSS vulnerability?
• What can I do to fix it?
• Resources

 

What is cross-site scripting (XSS)?

XSS is an exploit that provides an attacker a way to execute malicious JavaScript in a victim’s browser. In other words, if your site has an XSS vulnerability, an attacker can use your site to deliver malicious JavaScript to unsuspecting visitors.

Consider this (fairly common) scenario:

1. An attacker builds a special link that embeds a malicious script into your vulnerable page.
2. The attacker then crafts a phishing email containing that link, and sends it to UW addresses, targeting people in your department and making the message appear to be coming from you.
3. UW persons who don’t recognize it as a phishing message click on the link, and are exposed to the malicious script.

 

What can malicious JavaScript do?

• Steal sensitive user info, such as site cookies with session tokens
• Send unwanted requests to other sites
• Reproduce other forms of malware

It can feel like a waste of time to drop what you’re working on now and spend time fixing old code. But, the benefit is in minimizing the likelihood your site/application will be used to defraud people or otherwise cause harm.

 

What causes an XSS vulnerability?

Almost all XSS vulnerabilities arise from inadequate sanitization of user input.

Sites often obtain user input and then place it back onto a page, either immediately or at a later time. For example, consider a web form for collecting user comments on a blog. The user inputs a comment, which is then rendered onto the page. It’s assumed (hoped?) the user comments will be simple text. But, what if the user instead submits a script element? Without proper sanitization, the server would treat the script element as a normal comment, but when the browser attempts to render it onto a page, it would (correctly) interpret it as a script element and execute it.

 

What can I do to fix it?

Never trust user input. In other words, all user input should be sanitized at both the client and server so that potentially dangerous characters, text, or code is removed (or rendered benign) through the use of escaping, filtering, and validating. There are libraries to help with this on every platform. The following resources are a great place to gain a deeper understanding of XSS as well as the input sanitization techniques used to mitigate it.

 

Resources

• Excess XSS (an excellent XSS tutorial)
• Validating Sanitizing and Escaping User Data, from WordPress.org
• Form Data Validation, from MDN
• Input Validation, an OWASP CheatSheet

 

Information Security teaches hands-on secure coding workshops for web developers, which include understanding and mitigating XSS attacks. If you or your team is interested, please contact Pete Graff at pgraff@uw.edu.