20070123

Breaking out of Same-Domain Constraints

Link

There have been a few articles in the past on working around same-domain policies. I kinda' disregarded them in the past because they still require an XSS injection point, and there are other things that are still effective with XSS.

But a coworker today dinged me about trying to make an OTP proxy using a single XSS point. So I did a little futzing around with the DOM, and when the page loaded, replaced the submit button with a new button that evades same-domain by genning a <script> tag sourced from the attacker site, with parameters being passed from what is in the form.

While I was shocked at how easy it was, it still doesn't paralyze me with fear. Here's why:

  1. It still requires an XSS injection point. No XSS, no problem.
  2. Said XSS injection point would, in a perfect world, have to exist on the page that renders the form you want to steal (more on those of you who are telling me "now just a minute, buster!")
  3. Because of 1 and 2, there are other, really effective, and really simple things to do. Most notably, if I've got a victim user who will click on anything, they'll at some point ignore the site, and give up OTP's to the attacker site, rather than to the real site anyway, right?
Now, for the problem with #2 - I say the injection point has to be on the same page. I understand that if the injection is on another page, I can just render the login form I want. Which gets me around this whole cross-domain problem, anyway, right? I can just render a brand new form with a target action of the attacker's proxy. I was looking for something where I could swipe form information as it was entered, and the user still go to the right site - which ends up being non-effective with OTP - if I let the user post to the real site, what good does their OTP do me?

So, it was a fun exercise, but not really as scary as the posts I've seen make it out to be.

For those of you who are developers, there's nothing new here - just get rid of all your XSS flaws. Er....ahem....Do output filtering on everything, then you won't need to worry about all this chaos.

4 comments:

  1. Ok, I'm confused. What's an OTP proxy?

    ReplyDelete
  2. OTP - One Time Password. The idea was to make a MITM to get the user to give an attacker OTP's (thinking they were giving them to the legitimate site), while the attacker uses the OTP for whatever they want.

    ReplyDelete
  3. i would slightly disagree with your point about the XSS injection point on the same page. In my posting about ajax worm, i demonstrated that all you need is one injection point anywhere on your website. XSS attack can exploit that one hole and inject a ajax worm which controls your browser session as long as you are on that site. You can read about it on my blog http://myappsecurity.blogspot.com

    ReplyDelete
  4. Point taken.

    Sheesh. I hate XSS.

    Developers take note - just filter all your output, use XHTML rather than HTML to render your pages, and specify charsets.

    ReplyDelete