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)
18 May 2008
I used to think that using htmlentites() with ENT_QUOTES is a pretty good "universal" protection against cross site scripting. I used it in all of my projects, and basically relied on it completely. Whenever I got any user input, I passed it through this filter and felt completely safe to use the returned value anywhere in the HTML output. Apparently, this was nothing but a false sense of security.
I can see why I missed it, and that's because the "vulnerability" is pretty obscure, none the less it's there - and I bet many sites can be affected.
Take a look at this code:
<?php
$filtered = htmlentities($_GET["arg"], ENT_QUOTES);
echo $filtered;
?>
This is completely fine, and it will always work, providing good security. The problem arises when you try to do something a little more "advanced" with the filtered result. For example:
<?php
echo "<body onload=\"alert('$filtered')\">Hmm</body>";
?>
If you can see what's the problem with this code right away, than good for you. I didn't, and it took me a little by surprise to see that my filter has completely no effect here.
Just try this input:
?arg=lol'); alert('xss
With Magic Quotes off (and it's already off by default since PHP 6), this results in XSS.
What really happens here, is that HTML entities inside URLs, Event handlers (onload for example), or any other HTML tag properties- are being "read" by browsers as the values they represent. So ' becomes ', and that's what the script interpreter sees. This effectively cancels out the effect of my filtering script.
The source of the XSS'd HTML will look like this:
<body onload="alert('lol'); alert('xss')">Hmm</body>
On first glance you may think that this shouldn't work, but it does. Actually, HTML entities are meant to do that. There is no browser bug or something, only a matter of this feature being slightly hard to grasp.
Also, you can argue that the code I've shown above would be rarely used, and you are right. Yet, look at this code:
<a href="javascript:comments(18)">Comments</a>
This code is taken from this very page. The only thing that saves me from XSS here, is that the ID of the comment is an integer (I cast it that way) and that I don't show the "Comments" link in case the post with the specified ID doesn't exist (I don't show anything, actually).
I bet many web applications use something like this. I can also bet that not many developers are aware of the issue, and think (as I did) that their "universal" HTML filters are truly universal.
Posted by: kGen | In category: XSS | Comments (0)
Copyright (C) 2007-2008. Some rights reserved. Distribute freely, but don't forget to link to the source.
