Cross site scripting (XSS) errors are generally considered nothing more than a nuisance — most people do not realize the inherent danger these types of bugs create. In this article Seth Fogie looks at a real life XSS attack and how it was used to bypass the authentication scheme of an online web application, leading to "shell" access to the web server.

Like this article? We recommend

Cross site scripting (XSS) attacks are often seen as a powerless hack. While
this is true in some cases, for the most part the impact of an XSS vulnerability
is left up to the imagination and talent of the attacker. In this article I am
going to look at a real-life XSS attack and how it was used to bypass the
authentication scheme of an online web application I was asked to test. In this
case, the XSS resulted led to "shell" access to the web server —
anything but harmless.

The XSS Vulnerability

The target in question had a user/password entry screen, which is fairly
standard as far as web applications go. Figure 1 provides a screen shot of this
window. However, what you do not see is the code behind the login process. The
following provides the actual code used to verify the user account data:

As illustrated, the code put an unfiltered "$email" into an $error
message (line 10) after a check_email_address function rejects the input.
Unfortunately, the same $error message was then printed out onto the page, thus
allowing an attacker to inject pretty much anything they want right into the
content of the webpage — including JavaScript code.

echo ’<font color="red" size="3">’ . $error . ’</font>’;

Keeping this "feature" in mind, I next took a look at the program
and noticed that it was using the PHP Session ID value and storing it in a
cookie on the user’s PC. Knowing that this cookie information can be
called forth by a simple JavaScript command (i.e. document.cookie), I prepared a
small piece of code that would read the cookie and then forward that information
to a waiting server that would store the data for later retrieval. The actual
code is as follows:

As if fate wanted to make it challenging, the maximum size of the HTML input
field for the email address was 25 characters, and it only accepted POST data,
which is somewhat limiting. As a result, I had to "outsource" my
cross-site scripting attack to a third server. The end result was that I had to
make a user click on a link that first took the victim to my server. From there,
the code on my server directed the victim to the web application with a POST
value that included the XSS code, which was then fed into the login script.
Finally, the above JavaScript was output into the login page. Once the
JavaScript executed, the cookie data was passed back to the third party server,
which captured that cookie value, stored it, and redirected the victim back to
the real server where they would again be presented with the real and unaltered
login page. Since all this happened in a matter of a second, only an educated
and knowledgeable user would notice anything out of the ordinary.

At this point in the attack, I now owned a valid PHP Session ID value that
was used in the next stage of the attack.