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.
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 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.
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:
<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!
XSS Cheat Sheets