Cross-site scripting attacks
The basic vector for XSS is user input into a website that is not filtered to remove dangerous content. One of the more obvious ways this can occur is with sites that allow users to add comments to stories, without removing or altering HTML tags that they enter. For example, if one adds a comment that contains:
<script>alert("howdy")</script>
and someone else, when looking at that comment, gets the alert,
the site is vulnerable to XSS. Obviously, a javascript popup is not
particularly dangerous and would be a clear sign that something odd is
going on. This kind of 'attack' is only used as a proof of concept.
The key thing to note
is that one user can run javascript in the context of another user's
browser, with all of the information and privileges of the targeted user
(or, at least, the subset granted to javascript).
There are other mechanisms to inject this kind of malicious content, either as HTML links or by causing error messages that display the content. Essentially any place that a web application displays user input can be exploited if the input or output is not filtered correctly. When XSS attacks appear in links, they are often encoded in hex using the '%xx' or '&#xx;' so that it is not immediately apparent that the link contains malicious content.
A wide variety of actions can be triggered by an XSS exploit, including cookie theft, account hijacking, and denial of service. A clever attacker could make a page that looks exactly like the login page of a popular website (Google for example) and an unwary user could be fooled into entering their username and password into this page after following a link. By exploiting an XSS hole recently reported and discussed on the Bugtraq mailing list, the link would not obviously be malicious and could start with http://www.google.com.
Another common attack is to hijack a session by using an XSS exploit to capture a cookie value that stores a session ID. An attacker can then use that session ID to take over a currently logged-in session at the web site and for all intents and purposes, become that user. This attack is especially nasty if that user happens to be an administrative user - or is logged into, say, a financial site.
Avoiding XSS in a web application requires diligence in filtering user input (a common theme in nearly all web application vulnerabilities). Any user input that is sent back to browser for any reason needs to have certain characters converted to strings that will display properly, but not be interpreted as HTML by the browser. An XSS FAQ recommends replacing the following characters: < > ( ) & and # with <, >, (, etc.
XSS vulnerabilities are one of the most commonly reported security issues with web applications today. New XSS techniques are discovered regularly that find new ways to evade various security measures implemented by the browser scripting languages and new ways to fool users into falling into an XSS trap. Any technique that allows attackers to run code in your browser with your permissions is obviously cause for worry. Website users can only take some fairly drastic measures to avoid XSS (turning off javascript, not following links, etc.). This is clearly something that website owners must handle to protect their users.
| Index entries for this article | |
|---|---|
| GuestArticles | Edge, Jake |