Cross-Site Scripting
Cross-site scripting ('XSS' or 'CSS') is an attack that takes advantage
of a Web site vulnerability in which the site displays content that
includes un-sanitized user-provided data. For example, an attacker might
place a hyperlink with an embedded malicious script into an online
discussion forum. That purpose of the malicious script is to attack
other forum users who happen to select the hyperlink. For example it
could copy user cookies and then send those cookies to the attacker.
Details
Web sites today are more complex than ever and often contain dynamic
content to enhance the user experience. Dynamic content is achieved
through the use of Web applications that can deliver content to a user
according to their settings and needs.
While performing different user customizations and tasks, many sites
take input parameters from a user and display them back to the user,
usually as a response to the same page request. Examples of such
behavior include the following.
- Search engines which present the search term in the title ("Search Results for: search_term")
- Error messages which contain the erroneous parameter
- Personalized responses ("Hello, username")
Cross-site scripting attacks occur when an attacker takes advantage of
such applications and creates a request with malicious data (such as a
script) that is later presented to the user requesting it. The malicious
content is usually embedded into a hyperlink, positioned so that the
user will come across it in a web site, a Web message board, an email,
or an instant message. If the user then follows the link, the malicious
data is sent to the Web application, which in turn creates an output
page for the user, containing the malicious content. The user, however,
is normally unaware of the attack, and assumes the data originates from
the Web server itself, leading the user to believe this is valid content
from the Web site.
For example, consider a Web application that requires users to log in
to visit an authorized area. When users wish to view the authorized
area, they provide their username and password, which is then checked
against a user database table. Now, assume that this login system
contains two pages: Login.asp, which created a form for the users to
enter their username and password; and the page CheckCredentials.asp,
which checks if the supplied username/password are valid. If the
username/password are invalid, CheckCredentials.asp uses (for example), a
Response.Redirect to send the user back to Login.asp, including an
error message string in the query string . The Response.Redirect call
will be something like the following.
Response.Redirect("Login.asp?ErrorMessage=Invalid+username+or+password")
Then, in Login.asp, the error message query string value would be displayed as follows:
Using this technique, when users attempt to login with an invalid
username or password, they are returned to Login.asp and a short message
is displayed indicating that their username/password were invalid. By
changing the ErrorMessage value, an attacker can embed malicious
JavaScript code into the generated page, causing execution of the script
on the computer of the user viewing the site. For example, assume that
Login.asp is being called using the following URL.
As in the code for Login.asp, the ErrorMessage query string value will be emitted, producing the following HTML page:
The attacker embedded HTML code into this page in such a way that when
users browse this page, their supplied username and password are
submitted to the following page.
http://www.hax0r.com/stealPassword.asp
An attacker can send a link to the contrived page via an email message
or a link from some message board site, hoping that a user will click on
the link and attempt to login. Of course, by attempting to login, the
user will be submitting his username and password to the attacker's
site.
Prevention
Cross-site scripting is one of the easiest attacks to detect, yet many
Intrusion Prevention Systems fail to do so. The reason why cross-site
scripting can be easily detected is that unlike most application level
attacks, cross-site scripting can be detected using a signature. The
simple text pattern
To accurately detect cross-site scripting attacks the product must know
where and when to look for that signature. Most cross-site scripting
attacks occur either with error pages or with parameter values.
Therefore the product needs to look for cross-site scripting signatures
either within parameter values or within requests that return error
messages. To look for signatures in parameters values the product must
parse the URL correctly and retrieve the value part and then search for
the signature on the value while overcoming encoding issues. To look for
signatures in pages that return error messages the product needs to
know that the specific URL returned an error code. Intrusion Detection
and Prevention Systems which are not Web application oriented simply do
not implement these very advanced capabilities.
