How To: Is Your Website Vulnerable to XSS Injections? Here's How to Protect Your Visitors

Injection is an attack vector that involves breaking out of a data context and switching into a programming context through the use of special characters. These characters are significant to the interpreter being used, but not needed for the general user input being asked for.

Cross-site scripting, commonly known as XSS, is a form of injection where the interpreter is the browser and attacks are buried in an HTML document. HTML is particularly difficult because it's not only hierarchical, but also contains many different parsers (XML, JavaScript, CSS, PHP, etc.).

HTML is a very dynamic and free-flowing language—something that allows the web to be as advanced and colorful as it is, while also making it a nightmare to parse and filter. To make matters even worse, browser technology and features are expanding at an incredible rate and security must run to keep up.

While this makes the web fun and dynamic, it makes the security auditors job more difficult. How can you expect a legacy web application to take into account new features, protocols, and attack vectors? You simply can't.

What does all this mean to you?

Quite a bit actually, as XSS vulnerabilities are far more common that one might imagine. No matter if you are penetration testing, web developing, or black-hatting it somewhere in the middle, this is knowledge you want. Finding XSS holes is the easy part—knowing how to creatively exploit them and assess the possible impact of them is where the real coding and creativity comes in.

Injection? Like SQL Injection, Right?

Well, yes and no. In a nutshell, code injection using SQL is similar to XSS on the idea that it is abusing user input to be ran as a command or as code. SQL targets the database server (in this case, the interpreter), whereas XSS targets unsanitized HTML and JavaScript in the web browser, so as to execute one's own JavaScript code on an unsuspecting victim's machine. There are other differences, as well, and they will be apparent as we get deeper into the vulnerability.

There are two general categories of XSS attacks, reflected and persistent.

A Tale of Two Types

A reflected XSS vulnerability is when code is injected into a website to deliver a payload or to produce a result on the end user's browser. Reflected XSS vulnerabilities are delivered to a victim via various means, such as an email causing the user to click on a malicious URL, which in itself normally contains the malicious code.

A persistent XSS vulnerability is one in which the code is actually injected into the website itself, and remains for multiple users to be attacked by. For example, placing XSS code within the database that a forum uses would mean anyone who viewed that specific forum or thread would be affected by said code. The URL used to access this forum would not appear malicious in this case and chaos might ensue. 

XSS in Action

The next logical step to understanding XSS is to talk about its injection points. Where can web applications fall victim? Since XSS works as an interaction with active server content, any form of input should be filtered if it's ever to show up in a HTML page!

The default example of a reflected vulnerability, and the easiest to exploit, is parameters passed in through query string arguments (such as a search query) that get written directly to page. These are enticingly easy because all of the information can be provided directly in a clickable link and does not require any other HTML to perform. Hack in a sack, you could say.

Let's look at a famous example.

One well known persistent attack was the on MySpace by the Samy worm. In 2005, Samy Kamkar inserted JavaScript/Ajax code into his profile which updated a user's profile with "but most of all, samy is my hero."

The code would also add Samy's profile to the victim's list of friends. The XSS script would extract information about the user from the browser by looking at a cookie. Then the victim's profile was modified by adding Samy as a friend and in the victim's list of heroes, as well as replicating its own JavaScript/Ajax payload so as to spread. This ended up effecting over one million users.

Prevention

All XSS attacks infect your website via some form of user input. XSS attack code could come from a simple <FORM> submitted by your users, or could take a more complex route such as a JSON script, XML web service, or even an exploited cookie. In all cases, the web developer should be aware that the data is coming from an external source and therefore must not be trusted. I will repeat this...

ALL user input should be treated as if it is trying to exploit you. Always.

Escaping is the primary means to thwart a XSS attack. When performing escaping, you are telling the browser that the data you are sending should be treated as data and should not be interpreted in any other way. Even if an attacker manages to drop a script on your page, the victim will not be affected because the browser will not execute the script!

See below for some preventive code examples.

In Javascript:

function htmlEscape(UnescapedString) {

  return sString.replace(/&/g,'&').replace(/>/g,'>').replace(/</g,'<').replace(/"/g,'"');

}

In PHP:

htmlentities($UnescapedString);

In Ruby on Rails:

<%=h @UnescapedString %>

In C# ASP.Net 1-3:

HttpUtility.HtmlEncode(UnescapedString);

In C# ASP.Net 4:

<%: UnescapedString %>

In C# ASP.Net MVC3+ using the Razor View Engine, your strings will automatically be escaped:

@UnescapedString 

In Java:

StringUtils.replaceEach(

UnescapedString, new String[]{"&", "\"", "<", ">"}, new String[]{"&", """, "<", ">"});

In Closing

There is more to XSS then I have explained here, but I need your help! Are you a web developer? Do you have good tips for preventing XSS attacks? Have you used XSS in the wild and care to share? We would love to hear from you!

Do you have questions? A concern or two? Leave me a comment below or start a thread in our forum.