http://ha.ckers.org/blog/20060615/a-story-that-diggs-itself/ observes that CSRF can't totally be prevented with POST, however, as http://ha.ckers.org/blog/20060818/reducing-csrf-risk-with-tiered-authentication/ notes, "tiered authentication" can. Unfortunately, requesting someone's password isn't something that you can do all that often without annoying the user.

Another method that seems atleast somewhat viable is to append some sort of "nonce" to all URLs. eg. instead of www.domain.tld/index.ext, you have www.domain.tld/index.ext?var=whatever.

An XSS vulnerability on any website doing this would render this ineffective, as would accepting (additional) parameters via GET (if you did that, you could just embed an image that redirects back to a URL target website with the desired parameters in the URL), but aside from that, is this technique sufficient to protect against CSRF?

As far as I can see yes. You could for instance require the second half of the session key to be a parameter in the url (not the whole thing or it could end up in referers to other sites). Then check that their session is sorrect and the url contains the second half of the session variable name is in the variable in the url before you do the action.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

"You could for instance require the second half of the session key to be a parameter in the url (not the whole thing or it could end up in referers to other sites)."

Having the full session key show up in referer logs doesn't seem like it'd be a problem if you restricted the session to a specific IP address?

Of course, I guess doing that could result in some annoyance if you were on a laptop at one persons house, hibernated it, and then walked back over to your house.

"Having the full session key show up in referer logs doesn't seem like it'd be a problem if you restricted the session to a specific IP address? "
True and a valid point, unless you're being hacked from within your lan

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

We recently discussed this problem in a different thread. You shouldn't count on that kind of CSRF prevention, since it can be easily bypassed by the mhtml bug.

Yeah - out-of-date Apache installations are also affected with the whole Except header thing ( http://ha.ckers.org/blog/20060731/expect-header-injection-via-flash/ ). That said, I still think there's virtue to considering solutions to pure-CSRF as opposed to hybridized CSRF/XSS attacks. It's kinda like Physics. When trying to consider how projectiles will behave, beginning Physics students only account for gravity - not for air turbulence or friction or whatever.

That said, can you post a link to the other thread?

Microsoft says do this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebuipageclassviewstateuserkeytopic.asp
Yes, it's a POST with a nonce. If there is a way of bypassing this, please let me know because I'm seeing people use it a lot lately.

There was also a lot of talk on CSRF protection here:
http://www.gnucitizen.org/blog/cross-site-request-forgery/

Yes, it's this one right here: http://sla.ckers.org/forum/read.php?4,5496

While I spent the last hours with testing and thinking about this method (and mhtml issue) again, I found out that there's one aspect I haven't understood yet:

Example: Security token, embedded in html form, changes each per request
As I assume, you usually need to send two requests to the application in question to benefit from it. The first one is to pick up a token string and once you have it, another request needs to be sent to do the CSRF with the stolen token.

That won't work this way. The moment the second request is sent, the application would have generated a new token, which means the one you've just stolen is unvalid now. (Well this depends on the app design but usually it'll be the case).

---
I don't see a possibility to bypass that protection at the moment. Of course there are various other situations in which the mhtml issue would work fine (this approach is one of them).

Comments?

"Example: Security token, embedded in html form, changes each per request
As I assume, you usually need to send two requests to the application in question to benefit from it. The first one is to pick up a token string and once you have it, another request needs to be sent to do the CSRF with the stolen token. "

You usually need to send two requests if you're a user, too. Or maybe you're thinking that the first request doesn't count if it's already been sent?

*is a little confused*



Edited 1 time(s). Last edit at 02/09/2007 10:24PM by yawnmoth.

I was just playing around and what if you had the nonce behind the #-sign and parsed the url with JavaScript on each page?

yawnmoth Wrote:
-------------------------------------------------------
> You usually need to send two requests if you're a
> user, too. Or maybe you're thinking that the
> first request doesn't count if it's already been
> sent?
>
> *is a little confused*

Either it was in fact too late yesterday or I have simply forgotten what I meant, too.