1

I'm reading about the OWASP double submit cookies method of protection and there it states that the cookie value between the header and form should match.

That seems to be somewhat of a risk, as the article states, as the value embedded in the form can be accessed by the DOM & Javascript.

Would it not be more secure to have a differently seeded value for the cookie and the HTTP POST embedded value, so that a malicious script can't infer the cookie value

ASP.NET's AntiForgeryToken is an example of a double submit cookie. Its unclear to me if that token uses the same value for the cookie as the form.

Anders
  • 64,406
  • 24
  • 178
  • 215
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • When you know which cookie & which hidden form field is used for matching, you can successfully defeat the `double submit cookie` pattern... https://i.imgur.com/WFZG579t.png – Bossliaw Oct 30 '15 at 10:43

2 Answers2

2

A few points of note:

  • Don't use double-submit cookies, as you said and as the article states, this not very secure, and opens you up to other attacks.
  • "a differently seeded value for the cookie and the HTTP POST embedded value" - Yes, this approach is much preferred, but this is not a double-submit cookie - you are referring to what is known as a Form Token.
  • Using form tokens used to be more problematic, since it was difficult to get it right and avoid the subtle errors which invalidate the solution. Nowadays, there are very good packages out there that do this for you, such as OWASP's CSRFGuard. Similar mechanisms are also built into many frameworks, including ASP.NET.
  • As I mentioned, ASP.NET's AntiForgeryToken (actually, that's ASP.NET MVC...) is based on form tokens, and not double-submit cookies. Which, as mentioned, is not secure.
  • ASP.NET itself also includes protection based on ViewState, when using UserKey attribute.
  • Many other modern frameworks also have some builtin protection, including Spring, RoR, etc.
  • Another alternative, which might or might not be relevant, is re-authentication of the user, for specific actions. E.g. before transferring a large some of money to a 3rd party from your bank account, or authorizing connections in LinkedIn.
  • Don't use double-submit cookies.
AviD
  • 72,138
  • 22
  • 136
  • 218
  • It seems that [ASP.NET MVC uses identical values for the cookie and the form embedded value](http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/2a625d3470b90a7984cf26f6804c0b3acbbecb0c#src/System.Web.WebPages/Helpers/AntiXsrf/TokenValidator.cs). Could you please explain why this approach is different from double-submitted cookie? – Yeonho Apr 29 '13 at 04:15
  • OWASP: "[Double-submit cookie] approach is effective in mitigating the risk of cross-site request forgery". Why are you saying not to use it? Is it still vulnerable if I escape all HTML output and always use SSL? – Neil McGuigan Aug 20 '13 at 22:15
  • "`While this approach is effective in mitigating the risk of cross-site request forgery, including authenticated session identifiers in HTTP parameters **may increase the overall risk of session hijacking**`". It might fix one problem, but if it creates others then it is just not worth it. – AviD Aug 21 '13 at 07:22
  • 2
    I believe the double-submit cookies technique is safe, so long as you adhere to these caveats: http://security.stackexchange.com/a/61039/5002 – Gili Jun 14 '14 at 19:07
1

I think you're right that it would provide stronger protection if the cookie and form had different values. The downside is that instead of just checking if the cookie value matches the form value, you now have to keep track of which cookie value matches up with each form value. Also, as the OWASP documentation states, this all relies on the browser properly enforcing the same-origin policy (which can be trickier than it sounds) as well as proper (unpredictable) pseudo-random value generation.

Eugene Kogan
  • 281
  • 2
  • 4