Cross Site Scripting is one of the most prevalent attacks today on the internet. According to SANS and MITRE, XSS has been the most dangerous programming error for the past two years in a row, and that’s not surprising when you think about it.
Cross Site Scripting is
- easily exploitable
- numerous attack vectors
- hard to defend against
- hard to detect (from an automated test point of view)
- virtually unlimited vulnerable hosts
This ‘perfect storm’ if you will makes XSS something that you should be aware of, know how to defend against, and know how to exploit if you’re involved in security in any way.
In a nutshell, XSS occurs when malicious code (scripts in this case) is injected into a website for exploitation by unsuspecting users. There are two main types of XSS attacks, stored and reflected.
Stored XSS
A stored XSS attack happens when the malicious code is actually stored (who would have thought) on the web server being exploited. This is usually done via injecting the script into a web form of some sort and then when the result page is displayed, the malicious script executes and exploits the visitors workstation.
A real world example would be of a simple online guestbook or forum. Joe Evil posts a comment and in the name field, he types in his evil script. The script is then stored in whatever database or backed that stores all the rest of the data for the guestbook/forum. When the guest book is later viewed, this script is read by the browser and executed as part of the page.
Reflected XSS
Reflected XSS on the other hand is never actually stored on the web server being targeted. This script lives in a link/email or on a different web server than the one being targeted. When the user clicks on a link and visits the targeted web server the script executes as if it was stored locally (not in a link or externally on a different web server), and thus the victim’s browser trusts it and runs it.
For a real world example, check out OWASP’s site here.
One of the reasons why XSS is so hard to defend against is that there are so many different ways to exploit it, and it’s very hard to consistently develop code that defends against such attacks.
So how do you defend against it? Well, you have to sanitize your inputs for one thing. What does this mean? Well you basically can’t trust anything that can be inputted into your site. For example, if you have a web form and you’re expecting somebody to comment on a blog post, you don’t want any code tags. So filter out the <script> tag; that will effectively strip any evil JavaScript XSS from the comment, not allowing any script tags. Great and simple, right!
Unfortunately not. There are many many ways to express brackets (and various other bits of code) without using it’s latin character representation. For example:
%253cscript%253ealert(document.cookie)%253c/script%253e
<img src=asdf onerror=alert(document.cookie)>
The image source doesn’t exist, so it’ll throw an error… however the error is our evil cookie stealer. Crafty!
About XSS
- http://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
- http://www.cgisecurity.com/xss-faq.html
- http://cwe.mitre.org/top25/#CWE-79
XSS Cheat Sheets