0

When implementing CSRF protection, one generally uses a CSRF cookie that must be included in the body of the request. This prevents CSRF attacks because the malicious website cannot read the other website's cookies.

Does this mean that it is equally secure to instead host the CSRF token at a specific URL (without any Access-Control-Allow-Origin header set)? So for example, example.com/unique_csrf_token hosts a randomly generated secure CSRF token that must be included in all requests.

Is that equally secure since other websites can't access that URL? Or is there some other vulnerability I'm missing?

Azeezah M
  • 53
  • 4
Gabe
  • 11
  • 1
  • 1
    Why would you want to do this? Why can't other websites access that URL? And how to you link a specific user/session to that specific token? – tim Jun 24 '16 at 22:42
  • @tim I found a website that is doing this, and am trying to figure out if it would qualify as a vulnerability. It is set up so iframe access is not allowed and other domains can't make requests to it so as far as I know there is no way for other websites to access it. As for the second question, I believe it is done by the cookies sent to example.com/unique_csrf_token. – Gabe Jun 24 '16 at 22:48
  • 2
    Then you should edit the question stating you found a site doing it and you're curious if this practice is safe(AFAIK, it isn't because the cross site script will go to the domain that the form wants to post too, but I could be wrong?) – Robert Mennell Jun 24 '16 at 23:12

1 Answers1

1

When implementing CSRF protection, one generally uses a CSRF cookie that must be included in the body of the request. This prevents CSRF attacks because the malicious website cannot read the other website's cookies.

This is fundamentally incorrect. I think you misunderstand the attack vector.

A CSRF attack (also called "session riding") will typically look like this

  1. Hacker sends a carefully crafted email to millions of users, and/or tricks them into opening a carefully crafted page of the attacker's design.
  2. Of those millions, a few users will access the email while their browser is already logged into a secure web site, and hence has the session cookie
  3. A clear GIF, link, or script in the email or malicious page targets a location within the secure web site
  4. Because the user is already logged into the site, all cookies associated with that site are automatically sent along with the request. Hence the attack can "ride" on top of the user's legitimate session.
  5. At no point does the attacker learn what is IN the cookie. He is just borrowing it, blindly.

A CSRF mitigation relies on the fact that the attack is crafted ahead of time and has no ability to access the content of any of the secure pages (it can only issue a request blindly). A CSRF token is included as a hidden variable in the site's secure pages; when the attacker's request hits the site, yes it has the cookie, but it will not have the hidden variable. The site can validate the cookie against the variable, and if the variable is missing or wrong, the request is denied.

It is certainly possible to implement a CSRF mitigation using some token in the URL (in addition to, not in place of, a cookie), but this approach has certain problems. In order to offer any security, the token must change occasionally (sometimes per session, often per page request) and when it changes, it will invalidate any of the user's bookmarks. Also, it is darned ugly because an end user can see what appears to be goobledigook in the address bar.

You should NOT implement a cookieless mechanism that relies on the URL token alone, as this causes other security problems.

Community
  • 1
John Wu
  • 9,101
  • 1
  • 28
  • 39