----- Original Message ----- From: Peter W <peterwat_private> Subject: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images) | I hope you don't mind if I expand on this a bit. You've come across the | tip, in my opinion, of a rather large iceberg. It's another | Web/trust-relationship problem. Many Web applications are fairly good at | identifying users and understanding requests, but terrible at verifying | origins and intent. Yes, and oddly enough, its an iceberg thats been floating all around us for ages. | The problem isn't the IMG tag on the message board, it's the backend app | you seek to attack via the IMG tag. And I suspect lots of Web apps are | vulnerable. Lots. I've been to training on highly-regarded, widely-used, | expensive Web app development frameworks, and none of the classes taught | how to avoid the problems I will attempt to describe. In fact, they all | seem to teach the "easy way" of handling what look like user requests, | which is, of course, the vulnerable way. Yes, you're correct that its the target of the exploit which needs to be protected. However, the reason we originally related it to message boards was because the source and the target were tightly related. I could use an image on a message board to, as you suggested, make an online transaction at an online store. However, only users who had registered and logged in at that store would be effected. With message boards, or any other script with cookie based authentication AND inline image support, the exploit will suceed every time. In PHP especially, the ability to access variables via $theirname regardless of whether they are POST, GET, COOKIE, or SERVER creates a problem. Its easily fixed, though, by simply referencing the respective predefined array for the element ($HTTP_POST_VARS[], $HTTP_GET_VARS[], etc...) but the problem will remain simply because its what makes PHP easy for the beginner. | Right. There's something much larger going on here. Darnit, I wanted to | make a nice formal paper out of this, but you're forcing my hand. :-) The | problem is what I call CSRF (Cross-Site Request Forgeries. You going to the O'Reilly Conference in San Diego? We should meet up to discuss this further...maybe setup a BOF to brainstorm the far reaching effects of "CSRF" and all the possible solutions for it. | <img src="https://trading.example.com/xfer?from=MSFT&to=RHAT&confirm=Y"> | <img src="https://books.example.com/clickbuy?book=ISBNhere&quantity=100"> Eek! While its a problem, the user exposed WOULD have to be registered on the target site, and unless the target site is the source site, its not as much of an issue as inter-system attack would be. Inter-system being, for example, an image referenced on an EBay product page which bids on the item featured on the page. | Since HTML documents are popping up everywhere (even in corporate email | systems!!!), and it's impossible to discern what IMG or HREF values might be | direct CSRF attacks, or redirect users to unwittingly do dangerous things | via CSRF redirects, the fix has to be in the applications that do the | interesting things. Exactly. | That's it. When your client requests /logo.gif -- exposing no cookies -- the | example.net server redirects you to a URL like the one you show, above. So | the end result us the same as if the attacker had embedded the more obvious | URL inside the IMG tag. Opera lets you disable automatic 302 redirection. Probably a good idea if the redirect takes you off site. | If an attacker wants, he can also use a simple, innocent looking hyperlink | and hope the victim clicks on it (http://example.net/kyotoanalysis.htm). You | don't allow hyperlinks? Well, someone might copy/paste the link, and be | stung that way. They'd notice? Maybe not -- the URL could be a mostly useful | page, with a tiny frameset sliver that loads your attack URL. This has always been a problem, and as you mentioned above, the target site has to implement the fix. However, with the many scripting tricks available today, we're not being left with many options. | The fix MUST be implemented on the backend that's being attacked. In your | example, newreply.cgi needs to be intelligent enough to detect and stop CSRF | attacks. | We've talked about how an attacker can post a message to the messageboard | with innocent looking URLs. But an attacker can also simply send the | victim a piece of HTML email including the full attack IMG URL. No amount | of IMG tag filtering in your messageboard posting system can stop that. We haven't implemented any <img> tag filtering, IIRC. John just wanted to throw out a bunch of ideas as to what was possible. | ** The 90% solution: Referer tests This would work, but not all clients pass referers. For referer checking, I'd suggest validating the form if the referer matches correctly, or if no referer exists. Although not the perfect solution, I think that it'd be a safe bet. Let's say 1% of all clients don't pass referers. The 1% would be validated, therefore preventing them from getting an error when simply interacting as usual. Its just the 1% who are compromised (which could be .0001%) that would slip through. | <snipped> Passing tokens or tokenized field names </snipped> Good idea, looks to be the best solution yet. | ** Attacking sites behind corporate firewalls | <img src="http://intranet/admin/purgedatabase?rowslike=%2A&confirm=yes"> | security to many apps relatively easily. But Referer headers can also leak | information about "private" sites if those sites use non-anonymized | hyperlinks and external document references. Thats why more and more sites are using "proxy-out" links which parse out all links to external sites and append them to a URL. http://our.intranet.application/bye.php/http://www.2600.com/ | I'm afraid CSRF is going to be a mess to deal with in many cases. | Like trying to tame the seas. I'm in the process of launching a company that will "secure" web enabled applications from these, and other, types of attacks. CSRF seems to be one of the more generic types of holes which can be exploited, but there are certainly plenty more when dealing with user input, file handling, and database access. | Most of us probably depend on applications that won't be fixed | anytime soon. So what can you do to prevent a CSRF attack from making | your browser request something without your approval? | <list snipped> Basically, inconveince the hell out of yourself until the sites you use are fixed. ;) | My apologies for the somewhat rambling nature of this post; I may yet | clean this up and put it in a proper paper, and do some real editing... | but I hope even in this rough form it makes some sense, and helps folks | design better, safer applications. Thanks Peter, you've brought out several problems I didn't even imagine when I stumbled across the concept. Let me know if you do work on a paper, I'd appreciate not only obtaining, but possibly contributing a few ideas as well. -- WhiteCrown Networks - Web Application Security www.whitecrown.net - servicesat_private ______________________________ / Chris Lambert - cjlambertat_private |-> ICQ #: 16435685 - AIM: ClipperChris `-> Cell: (401) 743-2786 - http://sms.clambert.org/
This archive was generated by hypermail 2b30 : Fri Jun 15 2001 - 12:20:53 PDT