Three Ways to Test for Cross-Site Scripting

Last week, we explained what Cross-Site Scripting (XSS) is and demonstrated a couple of examples.  But knowing what it is isn't enough- we need to able to verify that our application is not vulnerable to XSS attacks!  Today we'll discuss three different strategies to test for XSS.

Strategy One:  Manual Black-Box Testing

This is the strategy to use when you don't have access to an application's code, and when you want to manually try XSS.  To implement this strategy, you'll need to think about the places where you could inject a script into an application:

• an input field
• a URL
• the body of an HTTP request
• a file upload area

You'll also need to think about what attacks you will try.  You may want to use an existing list, such as this one:  https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

This cheat sheet includes lots of different ways to get scripts past any validation filters, including:

• on error and on mouseover alerts
• URL encoding
• using upper and lower case letters (to evade a filter that's just looking for "javascript" in lower case letters)
• putting a tab or space into a script so it won't be detected
• using a character to end an existing script, and then appending your own

If you are testing manually, a systematic approach is best.  Locate all of the places where you could inject a script, choose a list of attacks you'd like to try, and try each attack in each place.  While you are testing, you may also gain some insight of how you could change the attack by what kind of response you get from the attack.  For example, if your script tag is stripped out by validation, you could try to encode it.

Strategy Two:  Look at the Code

This is the strategy to use if you want to test manually, and you have access to your application's code.  By looking at the code, you can determine the best way to craft an attack script.  This also works well for testing file uploads; for example, if your application's code lists file types that are not allowed, you may find some types that have not explicitly been blacklisted, and you can see if you can upload a script using one of those types.

Let's take a look at how you can use an application's code to craft an attack.  We'll be using the XSS Game again; we'll be doing Challenge 3, and in order to access it you need to have solved Challenges 1 and 2; so take a look at last week's post to see how to do that.  

As you look at the website in Challenge 3, you see that there are three different tabs, each of which displays a different image when clicked on.  Take a look at what happens in the URL each time you click on one of the tabs.  When you click on the Image 2 tab, "#2" is appended to the URL.  When you click on the Image 3 tab, "#3" is appended to the URL.  What happens when instead of clicking on a tab, you type "#2" into the URL?  Unsurprisingly, you are taken to the Image 2 tab.  What happens when you type "#5" into the URL?  There is no Image 5, but you can see that the page displays the words "Image 5".  What happens when you type "#FOO"?  The page displays "Image NaN" (short for "Not a Number").  You have probably figured out now that the end of the URL is the place that you are going to inject your malicious script.  

Now, let's take a look at the code!  Click on the "toggle" link next to the words "Target Code".  This will display the code used for the webpage.  Look at line 17; it shows how the URL for the image tag is created:

"<img src='/static/level3/cloud" + num + ".jpg' />";

The "num" part of this image tag is a variable.  The value of the variable is taken from what we are sending in the URL.  If you send in a URL with "#3", then the image tag will be
cloud3.jpg
If you send in a URL with "#FOO", then the image tag will be
cloudFOO.jpg

Our task now is to see how we can inject a script using this "num" variable.  Recall that in last week's post, we did some Cross-Site Scripting where we made it look like we were uploading an image, and we included an alert that would display when there was an error uploading the image. And we set things up so that there would always be an error, because we weren't really uploading an image at all.  We are going to do the same thing here.  

Let's craft our URL.  We will begin with

https://xss-game.appspot.com/level3/frame

because this is how the URL always starts.

Next, we'll add

https://xss-game.appspot.com/level3/frame#3

because we want to make it look like we are following the pattern of choosing an image number.

Now we'll add

https://xss-game.appspot.com/level3/frame#3 '

because we want to trick the code into thinking that the image URL is completed. This means that the code will try to load an image called "cloud3" instead of "cloud3.jpg", which will generate an error.

Now we can add our on-error script:

https://xss-game.appspot.com/level3/frame#3 ' onerror='alert("Hacked!")'

When the alert is triggered, a popup window will appear with the "Hacked!" message.

Let's try it!  Take the entire URL:

https://xss-game.appspot.com/level3/frame#3 ' onerror='alert("Hacked!")'

Paste it into the URL window, and click the "Go" button.  

You should see the popup window appear, and you have solved the challenge!

Strategy Three: Use a Security Testing Tool

As you can see from the example above, crafting an XSS attack takes a little time.  You may have many places in your application that you need to test for XSS, and not much time to test them.  This is where automated tools come in!  With an automated tool, you can send hundreds of XSS attacks in less than a minute.  In next week's blog post, we'll take a look at how to use an oddly-named tool called Burp Suite to automate XSS attacks!