Section 8.4. Cross-Site Scripting (XSS)

8.4. Cross-Site Scripting (XSS)

As popular and helpful as cookies are, it's becoming increasingly popular for people to turn off any cookie support. The reason is understandable: we store anything, from usernames and passwords to credit cards and other sensitive information, in stores of text that aren't all that difficult to access. (Well, depending on how vulnerableor nota web site is.) The reason, though, is also not necessarily well founded. One of the greatest areas of vulnerability associated with a web site is known as a cross-site scripting (XSS) attack.

Here's how an attack happens: you receive an email, or there's a link in a web site comment or suchanything that allows anonymous or semianonymous content. The link is to a legitimate site that takes cookies. Attached to the link is a set of characters, perhaps in hexadecimal format. We're used to long and unreadable URLs, so we don't make much of it. However, attached to that URL is a script that can trick the browser into bringing up whatever cookies are set between the person and the site. These, then, can be attached to the end of a document.location redirect, which basically sends this information to the new site.

This site then uses this information to emulate the site you're expecting to access. You'll continue to input valuable information, all the while the server site is gathering up your password, bank account, credit card information, etc.

This is what happens, more or less, with the email-phishing (pronounced "fishing") attacks you get that command you to log in or your account will be suspended. Even if the hacker doesn't steal the cookie, she can poison it by changing its value or corrupting it in some way. But vulnerabilities don't just exist with cookies: any opening into a web site is a potential doorway for bad people to do bad things.

8.4.1. The Injectors

XSS attacks are part of a group of attacks that take advantage of too many vulnerabilities in our software. Each uses some form of injection to insert malicious material. Among these are:

Cross-site scripting, or JavaScript/script injection

Embeds user information in a URL and inserts JavaScript to access this information for theft or malicious modification. A common variation uses the information it gathers to recreate what looks like a legitimate page where you do transactions (such as your bank account) but with added functionality to steal your information.

SQL injection

Potentially one of the most serious injection attacks. Many forms that take user input add the information the person provides directly to the database query. It's a simple matter to add SQL to emulate the end of one query and the beginning of anothergetting information such as credit-card numbers in the database, or passwords in plain text. When this was discovered, many popular PHP-based applications were found vulnerable. Unfortunately, more SQL injection vulnerabilities are found weekly.

HTML embedding or bad-tag injection

Embeds dangerous or malicious tags into data that's eventually going to be used to dynamically generate pages. One susceptible form involved weblog comments where hypertext links were allowed, and links to offensive pages could be added. The only skill required for this one was the ability to type and form a hypertext link.

Of course, add in holes in browsers and email programs, as well as web and email servers, and it can make you think fondly of days of log cabins, where you could see the bad guys coming from miles away.

8.4.2. What You Can Do

Things are not as bad as they seemif you stay aware of the vulnerabilities of your site as you're creating your pages. If you have a form, especially one that is nonsecure and for general use, any field in that form is a potential vulnerability.

If you have a server-side application that processes parameters passed in a URL, then all of your web site URLs are also a point of vulnerability.

If you store cookies, they're points of vulnerability.

In particular, if you post content that is created by anonymous or semianonymous people, you're creating the potential for nefarious doings.

Other than taking the log-cabin approach, the simplest technique to ensure the safety of your site is to scrub all incoming data: remove all harmful or potentially harmful material. No web site URL or form needs to have the term javascript: embedded in it; this can open the door to malicious script injection. You'll also want to consider stripping all HTML from user inputespecially images and hypertext links, and definitely script tags.

All HTML tags that are not allowed should be escaped, i.e., angle brackets converted to < and >, which prints them to the output but does not treat them as opening and closing brackets for HTML tags. As shown in earlier chapters, there are even encoding and escaping functions built into the JavaScript objects themselves that can aid this.

Here are some helpful sites regarding this issue:

CERT's Understanding Malicious Content Mitigation for Web Developers: http://www.cert.org/tech_tips/malicious_code_mitigation.html.

Wikipedia entry on cross-site scripting at http://en.wikipedia.org/wiki/XSS

If you dare, go into the lion's den: ha.ckers XSS Cheat Sheet for filter evasion at http://ha.ckers.org/xss.html.

There are many server-side approaches to securing a site using PHP or other language, and API functions such as htmlspecialchars, which escapes all HTML. However, you can make JavaScript the first line of defense in an attack by cleaning the incoming data before it's sent rather than cleaning up the mess after.