Attackers can use Cross site scripting (XSS) as a proxy to perform website security auditing. Jeremiah Grossman and I have been toying with this idea for a while now, but it occured to me much later, that we never got into the basics of how this could work. The basic premise is that by using Cross Site Request Forgeries (CSRF), I can get users to perform systematic security penetration tests against web application targets of my design.
Typically XSS works in this way: You have a site that you want to attack, and by injecting HTML into it the users who go to that URL are then fooled into entering their credentials, or the information that is sent via the browser (like cookies) are logged off host. It’s a very direct path, that doesn’t leave much room for obfuscation. The other problem is that testing the application to find the vulnerable cross site scripting holes can take a lot of poking, and all the while you are leaving signatures all over the host.
You may get around that by using a proxy, but here’s an idea. Why not use existing users as your proxy? All it takes is one compromised host, or another site that is frequented that you can inject HTML into. So I have random site “A” that is not the ultimate target, and the victim site “B” that you are interested in. I inject HTML into site “A” and the visitors of that site stumble accross the injected XSS. That XSS tells their machine to connect to site “B” and test for a simple exploit (say another XSS hole - just to make this easy).
Now the bad guy simply needs to go to site “C” and look for any string that might have worked. Voila! Now what did the victim host “B” see? They saw an IP address connect to their machine and perform a series of XSS attacks. They may see one succeed, but either way they can no doubt see where the information was intended to be logged on site “C”. You can remove site “A” from the logs by using a series of META refreshes so it doesn’t show up in the referring URL (as META refreshes remove the referring URL). The important part here is that the real attacker’s IP address never shows up in the log files of the victim, site “B” and it is highly unlikely that the user who’s machine is being used as an attack relay probably won’t have any idea about what is going on.
Here’s a diagram that should help explain it:
Cross site scripting is probably the most important initial vulnerability to find, because that will then open the doors to remove the browser cross domain policy issues so you can perform more interesting attacks, like SQL injection and code injection. Once those attacks are performed they will need an XML RPC call (requiring cross site scripting) to send the data that is outputted to a logging remote host (site “C” or otherwise).
In this way you can use XSS to completely proxy all of your web attacks so that the victim in question (site “B”) will never see the originating IP address. This does rely on having two other cross site scripting vulnerable machines at your disposal, but those are a dime a dozen. This concept really falls into the category of XSS malware (a term coined by Jeremiah) where XSS goes beyond a simple way to inject HTML, but actually can be used as a launch pad by which to initiate much more destructive attacks.