Cool CSRF using nothing but CSS and iframes
26 May 2008
Yes, you heard me. This even beats the random token protection. The only things that it can't beat are password requests and CAPTCHAS.
Before you get too excited, though, this method requires some user interaction (a click on the malicious page). Also, it's *very* limited to specific browser settings (it can be adapted to any browser, though). Read on to lean why.
Yes, this method is most certainly something you would call "lame", but in my opinion it does it's job well.
The process is really quite simple. You create an iframe to the page you want to attack, and size it in a way so the "sumbit" button on the victim page is in the lower right corner of the frame. You add CSS to make the frame transparent, then you place it over something a user would want to click (like the "play" button on a video). You set the z-index of the frame to something high, and make sure the user would click on the right spot. Once the user clicks on what he thinks is the "play" button, he actually clicks on the hidden "submit" button. That's it.
Funny, isn't it? This doesn't sound like much, but the possibilities are endless. In fact, I created a PoC that exploits Digg.com in this way. If a logged in Digg user clicks on a "link" on my page, he automatically and unknowingly diggs an article. (Another "An article that diggs itself" submission"?)
I won't be posting this PoC for now, but I promise to do that in a future post. Maybe even my next post, so wait for it.
Anyway, this attack has some obvious drawbacks:
1) It's very sensitive to how the victim page is rendered.
2) Any change like the default font size could kill the attack.
3) Browsers render things differently. Even the slightest differences can be trouble.
Oh, and also, to change the CSRF'd form's content, we will need some JS. One line to be exact (document.forms[0].submit()), but still, JS is JS.
The thing is that many web applications have a feature to restore a form's content after it was sent and there's been an error. So, you create an HTML page that automatically POSTs an arbitrary form to the destination, and work with the page that says "you had a problem with your token". It will probably have your arbitrary values included, along with the correct token.
Pretty bad, huh? The worst thing is that if you don't need to use JS, not even "NoScript" will protect you.
Finally, I promise that once I get my Digg.com PoC to work on more than one browser, I'll post it here, so you could see it in action.
Posted by: kGen | In category: CSRF (XSRF) | Comments (0)
