Cross Site Scripting (XSS)

Hiyas!

This article is intended to give you, the general user, information about a commonly used technical tool known as "Cross Site Scripting", or XSS. Although logic would tell us that CSS should be the shortened version, XSS is used instead because CSS is used for another type of Web tool called "Cascading Style Sheets". (I hope this is as technical as I need to get...)

First, scripting: Web browsers use scripting to make the Web browsing experience more "rich and full". Lots of cool things can be done with scripting: forms can be checked to make sure that information follows specific rules (personal names don't have numbers, telephone numbers have no letters, etc.); Web pages can display better by detecting your Web browser type; and scripting can also be used to add extra pizazz (bells and whistles) to a Web page.

There are two main categories of Web scripting: server-side scripting, which your Web browser doesn't need to worry about, and client-side scripting, which is used by your Web browser. This article deals with client-side scripting. The most commonly used client-side scripting language is "Javascript". I adore Javascript because it's easy to write something small that does a lot. Other client-side Web scripting technologies include VBScript and ActiveX.

Scripts can be stored in the Web page itself, or (as XSS) it can be stored in another file and then read separately by the Web browser. Sometimes this is done because a Web site wants to keep all the scripting limited to a single resource, like putting all of their brown eggs in one basket, and every other type of egg in another. It helps keep things uncluttered.

XSS itself is not dangerous, but relying on another Web site to maintain the scripts can be disastrous if the script is not written properly. A recent example of a badly-written script involves worm attacks on Twitter over the last weekend. Worms are like viruses, but they're usually based on scripts. See Symantec's take on viruses, worms and trojans for a more detailed view of the differences between these exploits.

Because Twitter did not design their scripts properly, the scripts allowed the Web servers (which store the Web pages) to become vulnerable to attack. Then the Web servers were too busy dealing with the problems, and couldn't feed information to its users. It's a toss-up between safety and functionality. The more uses a scripting language has, the more exposed your Web browser can be to attack. This is an unfortunate fact of computers.

Because the scripts were available through a central site, any pages which used these scripts were vulnerable to attack.

The typical reason that Web scripts are unsafe is that companies or people take shortcuts, and therefore save time, because money (which is time) is more important to companies than safeguards. Alternately, Web programmers are not trained properly, and through lack of knowledge introduce these errors into their code. It's like a wizard who doesn't understand the nature of the spell being cast: if a part of reality is accessed by the spell without proper safeguards in place, the spell can backfire and cause problems. (Not that wizards necessarily exist, but the idea is the same.)

It would help if experts reviewed scripts and then published their findings to expose these nasty exploits. Unfortunately, it takes too long and requires too much effort, and pays little to the reviewer. A company can also change the script whenever they want, and the user won't know until they review the code.

How can you protect yourself from these exploits?

The easiest solution is to disable scripting entirely. This, however, will keep some Web sites from operating properly (or at all). If the Web site knows that it cannot use scripts, sometimes it will tell you, but it still may not work properly.

The solution I prefer is to disable scripting for some sites, and allow it for others. I'm unsure if this is available to other Web browsers, but with Firefox I've been using the NoScript add-on. NoScript disables all scripting, and then allows you to enable them temporarily or permanently on a case-by-case basis. It's fairly easy to use, and I only have it permanently enabled for maybe 6 sites. Everyone else has to earn my trust first!

As it stands, XSS is likely to be around for a while, and so too will Web scripting vulnerabilities. So, as with many other things, it's up to the user to protect themselves and be informed about the dangers of Web browsing.