SQL injection attacks
Two weeks ago, this page
on web applications. Another well-known attack
is cross-site scripting, often abbreviated as "XSS." Cross-site scripting
is, perhaps, a more subtle way of breaking web applications, but its
effects can be just as damaging as SQL Injection.
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:
and someone else, when looking at that comment, gets the alert,
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
browser, with all of the information and privileges of the targeted user
There are other mechanisms to inject this kind of malicious content, either
as HTML links or by causing error messages that display the content.
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
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
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
website owners must handle to protect their users.
to post comments)