Matt Briggs

"Not all code needs to be a factory, some of it can just be origami." - _why, the lucky stiff

Understanding XSS

security
by Matt Briggs on

When you are talking about security with regards to web applications, the vast majority of it falls into IT land (i.e. configuring your firewall, webserver, etc). However, that doesn't mean web application developers can just ignore security. The most pervasive, and difficult to understand attack vectors out there is Cross Site Scripting, or XSS for short.The idea is that you find a public facing web page that exposes user generated content automatically, but does not take measures to prevent people from injecting arbitrary html or javascript. On the face of it, you may think "Ok, so that would mean a page gets defaced. Sucks, but its not the end of the world". It turns out it could get much, much worse then that. Here is a quick rundown of several scenarios where an XSS vulnerability could cause serious harm

Straight Forward XSS

  1. I find google has an xss vulnerability
  2. I write a script that rewrites a public google page to look exactly like the actual google login
  3. My fake page submits to a third party server, and then redirects back to the real page
  4. I get google account passwords, users don't realize what happened, google doesn't know what happened

XSS as a platform for CSRF

  1. Amazon has a csrf vulnerability where a "always keep me logged in" cookie allows you to flag an entry as offensive
  2. I find an xss vulnerability on a high traffic site
  3. I write a javascript that hits up the urls to mark all books written by gay/lesbian authors on amazon as offensive
  4. To amazon, they are getting valid requests from real browsers with real auth cookies. All the books disappear off the site overnight
  5. The internet freaks the hell out. (this supposedly actually happened)

XSS as a platform for Session Fixation attacks

  1. I find an e-commerce site that does not reset their session after a login (like any asp.net site), have the ability to pass session id in via query string or via cookie, and stores auth info in the session (pretty common)
  2. I find an XSS vulnerability on a page on that site
  3. I write a script that sets the session ID to the one I control
  4. Someone hits that page, and is bumped into my session.
  5. They log in
  6. I now have the ability to do anything I want as them, including buying products with saved cards

Those three are the big ones. The problem with XSS, CSRF, and Session Fixation attacks are that they are very, very hard to track down and fix, and are really simple to allow, especially if a developer doesn't know much about them.