Basics

Cross Site Scripting (XSS) is currently one of the most common web application vulnerabilites. It is bascially the ability to inject executable script (usually Javascript) into a web page. The goal of the attacker is to craft a custom script (usually one that steals session cookies) and get a user to make the request that executes the script. This can be accomplished by getting the user to click on a crafted link , having them visit a malicious website created by the attacker, or even by sending them to a particular page on the valid side that contains a persistent/stored XSS vulnerability.

How do you test for XSS?

To find a XSS vulnerability, basically you attempt to see if Javascript can be injected into any place on the website that accpets user input. These places include url parameters, form inputs, hidden form fields, and even other places you would not expect such as a cookie value.

Here are some simple steps to get started:

1. Find a place on the site that accepts user input. Example: www.site.com/search=blah

2. Change the parameter to something that can be located in the page source. Example: www.site.com/search=xss

3. View the page source to see where ‘xss’ is reflected.

4. Now the goal is to figure out how you can get javascript to execute. If the user input is simply reflected as text on the page something simple such as <script>alert(‘xss’)</script> could work. If the user input lands somewhere inside of an HTML tag  you will need to figure  out how to get it to “break out”. By this I mean you will need to figure out how to end the HTML tag so that you can inject the script. Usually a “> should be enough.  For Example: www.site.com/search=”><script>alert(xss’)</script>

If the user input lands in an href link on the page it is not necessary to break out of the tag completely. You can simply create an attribute such as “onmouseover=”prompt()”. Also if you find your input lands in Javascript it is as simple as formatting correctly to get an alert window to pop.

How do you fix XSS?

Blacklisting alone usually doesn’t work.  Implementing output encoding such as HTML entinty encoding or URL encoding seems to be the best fix for now. This will prevent user input from reflecting dangerous characters such as “,<,>, etc. which means that script will not be able to execute in a user’s browser.

Some things to keep in mind:

- If you are simply testing for XSS, being able to get an alert or prompt window to execute is all you need to show that an XSS vulnerability is indeed present.

- Getting a script to execute might take some work. Often it is not as simple as inputting <script>alert(document.cookie)</script>. I suggest reading over the XSS cheat sheet at ha.ckers.org

- This is only a brief intro to XSS. There is much more to this topic and I hope to cover more at a later time. For further reading you can checkout OWASP.

This entry was posted on Sunday, July 19th, 2009 at 6:38 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.