Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It seems that the entire problem could be solved very elegantly by simply adding a new flag to the HTTP cookie specification.

Similarly to how cookies flagged Secure will only be submitted by the user agent over secure connections and those which are flagged HttpOnly will be forever inaccessible via DOM access, why not specify a new flag, say, NoCSR, or SameOriginOnly, which, when set, would prevent the cookie from being submitted with requests triggered by cross-origin referrers?

Of course, it would default to off so as not to break the previously expected behavior for already existing web sites, as per HTML5 Design Principle #2.1. I suppose there does exist one security hole, but not one that can't be easily solved: it can't be indiscriminately depended on, because old browsers would presumably just ignore the unrecognized flag.

So why not just create a whitelisted enumeration of NoCSR-implementing user agents versions' corresponding UA strings, and then only accept/process authorization-requiring and sensitive requests that carry one of those User-Agent: values? For requests submitted with no or non-whitelisted UA headers, an error could be returned that reasonably demands that the user upgrade to a supported browser version.

The whitelisting could be DRYed out with canonical implementation libraries (it would probably be more like a single simple function) for various server side languages.

Doesn't this seem much simpler than the current system of generating, keeping track of, and reading secure CSRF tokens?

Thoughts, anyone?

share|improve this question

migrated from Sep 9 '12 at 23:07

This question came from our site for professional and enthusiast programmers.

For requests submitted with no or non-whitelisted UA headers, an error could be returned that reasonably demands that the user upgrade to a supported browser version. which would definetly break the previously expected behavior for already existing web sites. – Jonas Wielicki Sep 9 '12 at 14:31
Cookies are not the only means of authentication. You could also use HTTP authentication, client certificate based authentication, or even IP address based authentication. – Gumbo Sep 9 '12 at 14:32
I think you'd be borderline retarded to use anything as unpredictably volatile as IP addresses for authentication. I don't know what client certificate based authentication refers to, but is HTTP authentication vulnerable to CSRF attacks, as well? I suppose it would be, wouldn't it.. That said, I feel like my solution would still work for the overwhelming majority of sites using cookie-based auth schemes, wouldn't it? @Gumbo – adlwalrus Sep 9 '12 at 14:38
@adlwalrus, yes, HTTP authentication and client certificate based authentication are also vulnerable to CSRF. – D.W. Sep 10 '12 at 0:41
up vote 4 down vote accepted

Basically you are right, your solution would prevent CSRF tokens from being necessary against such attacks. But then we could also check the Referer header to make sure it comes from an allowed domain or subdomain, right? And using the referrer would already be more flexible than an NoCSR-flag: you can whitelist domains or subdomains.

The problem is replay attacks, or when a user accidentally submits twice. For this reason you would already need a token that changes unpredictably every request (a.k.a. nonce). This might be as simple as a salted hash of the current time, but still need to do it.

Also cookies are necessary to keep someone logged in. Having to have seperate cookies to identify CSRF attacks and when someone is logged in is kind of annoying. (The one to identify CSRF attacks would carry the NoCSR flag.) And you do want to know whether someone is logged in, the menu will probably need to be different, even when he is referred there from another website.

share|improve this answer
+1 replay attack – rox0r Sep 10 '12 at 2:02
I don't believe that the HTTP spec requires referrer transmission. But if one assumes that their users have internal referrer transmission enabled, I assume just verifying that would do the trick too, wouldn't it? – wwaawaw Sep 10 '12 at 8:06
But what I don't understand is how a replay attack is an attack at all. Seems more like an innocent accident or a bug or a mishap. Also, isn't the risk of that mitigated by disabling / "greying out" the button on it's click event? I read a post about that one time, I think it was on codinghorror. I'd also redirect after the POST receiver script got hit. Finally, how would you verify the nonce when you received it back? – wwaawaw Sep 10 '12 at 8:09
@adlwalrus "I don't believe that the HTTP spec requires referrer transmission." No, it doesn't, that's my single issue with this. All browsers support it though, and those who disabled it because of privacy reasons will discover soon enough. Same with Javascript, if it's disabled stuff might break. Just make sure to give appropriate errors. – Luc Sep 10 '12 at 9:41
Well that makes sense then. There really isn't any additional privacy leak to sending same-site referrers, though, and that's really all that's called for here. I believe the browsers that offer a way to disable referer transmission only allow disabling it for external link clicks. Of course there're extensions to both big browsers that disable it completely. But yeah, obviously there'd be a reasonably explanatory error message. – wwaawaw Sep 10 '12 at 10:29

I'd say mostly complication. A link sent through another application would carry no site referrer, so that is a hole that needs to be considered. One could focus on only passing requests from within the site, but there could be an XSS vulnerability that would create CSRF-like behavior that would be stopped by using a nonce.

In very short summary: the nonce method already works and isn't very complicated to implement. This proposed method may end up being much more complicated to implement, would break backwards compatibility, and would require the already existing nonce method as a stop-gap.

Finally, there are other non-repetition behaviors for which you might still desire a nonce.

share|improve this answer
I don't think it actually would break BC, if you read the post carefully. Is "nonce" synonymous with "CSRF token"? – wwaawaw Sep 10 '12 at 8:10
@adlwalrus Essentially yes. – Jeff Ferland Sep 10 '12 at 15:42
@adlwalrus A CSRF token does not necessarily need to be used only once. The only requirement it must fulfill is that it is only known to the properly authenticated user. Theoretically, it is perfectly fine to generate a token only on user registration. Although regenerating the CSRF token reduces the risk of the possibility of a valid CSRF token getting leaked or guessed. But nonce rather implies that the value is only valid for a single request. – Gumbo Sep 10 '12 at 17:12
@Gumbo that's a great point. – wwaawaw Sep 10 '12 at 17:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.