Nice article. And the subject's important because, as you've pointed out, many things CORS/XSRF-related are misunderstood. If I'm being honest about it, I sometimes have to stop and check my premises to ensure that I'm not doing something wrong.
In my side projects, I've adopted a habit of issuing single-use XSRF tokens. I was thinking this would be far more secure - like having a lock that only accepts officially-issued, single-use keys. I know I've seen a few other apps that employ single-use tokens, but I notice that most apps do not do this.
What do you think of this practice? Is it overkill? Am I truly providing an increased level of protection against XSRF attacks? Or am I engaging in what I like to call "security theatre"?
I was just looking into the OWASP implementation recommendations for Use of Custom Request Headers and this is what they mention there:
This defense relies on the same-origin policy (SOP) restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers do not allow JavaScript to make cross origin requests with custom headers.
I'm not an expert but at a glance this looks to me as if all we need is the presence of that XSRF header to make it work. It just needs to be a custom header, and the value doesn't necessarily have to be a secret.
I guess making that header a random session-based secret could be an additional layer of security in case something's not right with the browser security, be it a bug or a changed setting, or a compromised browser. Maybe there's still a bunch of older browsers out there that don't enforce SOP. But these look like problems that are more on the user's side, where they unwillingly or willingly compromised their own security.
Overall it seems regenerating the token on every request is probably not necessary. I guess it would be enough to regenerate it once on sign in, or session refresh.
Someone asks for clarification if the following is really true and sufficient security:
The value of the header is irrelevant. This is how Jersey 1.9's CsrfProtectionFilter works and it is described in this blog post: blog.alutam.com/2011/09/14/jersey-.... The blog post also links to NSA and Stanford papers stating that the custom header itself is sufficient protection...
The accepted answer confirms that a "token-less" CSRF header would be enough today, but generating and verifying a secret should protect against future changes
Much obliged. Those links are good reads. And they seem (to me) to confirm that, while the mere existence of the custom header may currently be "enough", it's probably not a bad idea to issue single-use tokens. Especially if that functionality has already been put in place.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article. And the subject's important because, as you've pointed out, many things CORS/XSRF-related are misunderstood. If I'm being honest about it, I sometimes have to stop and check my premises to ensure that I'm not doing something wrong.
In my side projects, I've adopted a habit of issuing single-use XSRF tokens. I was thinking this would be far more secure - like having a lock that only accepts officially-issued, single-use keys. I know I've seen a few other apps that employ single-use tokens, but I notice that most apps do not do this.
What do you think of this practice? Is it overkill? Am I truly providing an increased level of protection against XSRF attacks? Or am I engaging in what I like to call "security theatre"?
Single use is probably overkill. Best practice seems to be on a per-session basis.
I was just looking into the OWASP implementation recommendations for Use of Custom Request Headers and this is what they mention there:
I'm not an expert but at a glance this looks to me as if all we need is the presence of that XSRF header to make it work. It just needs to be a custom header, and the value doesn't necessarily have to be a secret.
I guess making that header a random session-based secret could be an additional layer of security in case something's not right with the browser security, be it a bug or a changed setting, or a compromised browser. Maybe there's still a bunch of older browsers out there that don't enforce SOP. But these look like problems that are more on the user's side, where they unwillingly or willingly compromised their own security.
Overall it seems regenerating the token on every request is probably not necessary. I guess it would be enough to regenerate it once on sign in, or session refresh.
Another Google search reveals a similar discussion on Stackexchange.com.
Someone asks for clarification if the following is really true and sufficient security:
The accepted answer confirms that a "token-less" CSRF header would be enough today, but generating and verifying a secret should protect against future changes
I (still) agree.
Much obliged. Those links are good reads. And they seem (to me) to confirm that, while the mere existence of the custom header may currently be "enough", it's probably not a bad idea to issue single-use tokens. Especially if that functionality has already been put in place.