On Fri, Jun 15, 2001 at 02:09:57AM -0400, Chris Lambert wrote: > 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. Yes, of course. It's a ripe target. Low-lying fruit. Worth special concern. > | <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. Yes, the tightly coupled attack is definitely more effective. I can imagine a fair number of shenanigans on Slashdot et. al. if they're vulnerable, e.g., Anonymous Cowards posting links to what purports to be useful information... but I'm more concerned about things like commerce sites and webmail sites. As one pf the long messages reference in my long bugtraq post points out, I expect on many webmail systems an attacker could use CSRF to make a victim send abusive email without their knowledge. With more governments like that of the United Kindom bringing transactional capabilities to the Web, I hope developers will pay serious attaention to the problems of verifying origin and intent. > Opera lets you disable automatic 302 redirection. Probably a good idea if > the redirect takes you off site. Yes, that does sound like generally a good idea, but it would frustrate some applications that expect the usual behavior (I've written some such apps myself). I wonder how it would work in HTML mail clients, though? You could restrict to the sender's domain, but email is the easiest thing in the world to spoof. (And an effective attack vector, especially against things like messageboards that expose email addresses.) HTML email is just evil evil evil. I can't see much need for HTML email to reference *any* external documents, or to allow, as Jay Beale suggested, the use of things like META refresh tags to effect client-pull CSRF attacks. > | ** 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. I haven't thought this through very much. But check the securityfocus URL in my post; in my testing, 100% of clients will not send Referer information in client-pull (META refresh) scenarios. So be careful when working with your 1% rule: with client-pull, an attacker can make anyone suppress Referer information. > | <snipped> Passing tokens or tokenized field names </snipped> > > Good idea, looks to be the best solution yet. The problem with tokenized argument names is the /logo.gif 302 attack. If an attacker embeds an IMG reference to /logo.gif on their server, then their server is passed a Referer (in most cases, probably 99%+) that exposes the argument names used to read the CSRF message. I suspect you would not be (socially) able to rename the arguments with each page delivered. Doing things like that really frustrates users. I've tried it, and had to back out such protection on applications used by "regular" folks. The one-time-use authorization tokens seem to be solid, though. And easy to use, once you've got the basic Create/Verify/Invalidate methods written. > | 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. A pattern I've seen in Web deveopment over the years -- and I suspect it's not just the relatively young Web area that exhibits this -- is that developers tend to be more paranoid when building applications for pulic / unathenticated access. They tend to let their guards down when writing applications for users who are "logged in". The thinking often goes something like this: "Well, if the site's editor is logged in and asks to do something stupid, that's *her fault* and I'm not going to make this management application idiot-proof." Hopefully this discussion of CSRF helps explain the importance of making sure the HTTP request your application handles really is the site's editor asking to do somethign stupid, and not simply reading an HTML email with a CSRF IMG tag. > | 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... > Thanks Peter, you've brought out several problems I didn't even imagine when > I stumbled across the concept. And I keep running into more things myself. :-( Be well, -Peter
This archive was generated by hypermail 2b30 : Fri Jun 15 2001 - 12:36:56 PDT