Stay ahead of Web 2.0 worms

XSS marks the spot

Stop sign

Think you've protected your web applications from cross-site scripting (XSS) vulnerabilities? The odds are against you. Roughly 90 per cent of web applications have this problem, and it's getting worse as web applications and web services share more and more data.

Many frameworks and libraries are encoding, decoding, and re-encoding with all kinds of schemes and sending data through new protocols. Ajax and other "rich" applications are complicating this situation.

XSS happens any time your application uses input from an HTTP request directly in HTML output. This covers everything in the HTTP request, including the query string, form fields, hidden fields, pull-down menus, check boxes, cookies, and headers. And, it doesn't matter if you immediately send the input back to the user who sent it - you get something called "Reflected XSS" - or store it for a while and send it later to someone else - that's "Stored XSS".

XSS is a fairly serious vulnerability. By sending just the right input, typically a few special characters like " and > and then some JavaScript, an attacker can get a script running in the context of your web page. That script can disclose your application's cookies, rewrite your HTML, perform a phishing attack, or steal data from your forms. Attackers can even install an "XSS proxy" inside the victim's browser, allowing them to control your users' browsers remotely.

Security problems like XSS are inevitable when you don't keep code and data apart - and HTML is the worst mashup of code and data of all time. There's no way good way to keep JavaScript code and HTML data separate from each other. To prevent SQL injection, you can use a parameterized query to keep the data and code separate. But there's nothing equivalent for HTML. Just about every HTML element allows JavaScript code in attributes and event handlers, even CSS:

CSS meets XSS

Fortunately, there are steps application developers can take to protect applications:

Validate input: One way to keep code out of user input is "whitelist input validation." All you have to do is verify that each input matches a strict definition of what you expect, like a tight regular expression. Attempting to take a shortcut and apply a global filter for attacks is known as a "blacklist" approach and never works. Unfortunately, even the tightest input validation can't completely defeat XSS, as some input fields require the same characters that are significant in HTML - a you can see here:

?name=O'Connell&comment=I "like" your website; it's great!

Sponsored: Designing and building an open ITOA architecture