Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)

[Peter W <peterw () usa net>]

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