CODEWITHSUNDEEP
angularjsrestsecurityjwtcsrf
boomslang
boomslang

Reputation: 1

CSRF protection in a angular SPA using Double Submit cookie

We are struggling with trying to implement CSRF protection in a SPA using AngularJS and Restful services.

Scenario: 1. user logs in a JWT is created that contains a CSRF Token as part of the payload.

  1. JWT is put in a HTTP Only Secure cookie and sent back on the response header

  2. Additionally the same CSRF Token is sent back in the response.

  3. The javascript (angular) code puts the CSRF token in $rootScope

  4. User/program whatever... makes a request of a protected api. Send the CSRF token from $rootScope in the request.

  5. Cookie travels back along with the request.

  6. Server looks at the cookie unpacks the csrf token in the JWT compares CSRF token with the token that was in the request body.

  7. Generates a new CSRF token... puts it in the jwt, puts jwt back in a cookie returns cookie along with the CSRF token in the response.
  8. Client receives response, stashes the CSRF token in the $rootScope.
  9. Repeat

Question: If I have many requests in a short period of time (sub second) from a client (, using an interceptor, maybe) which gets the CSRF token from the $rootScope. Could the csrf token in my request EVER be out of sync with the CSRF token that is in the Header/Cookie/JWT?

P.S. I understand the concept of promises etc.

The bottom line is I want every request to the API to have a CSRF token in the body that will match the CSRF token in the Header/Cookie/JWT.

Upvotes: 0

Views: 1377

Answers (1)

Gabor Lengyel
Gabor Lengyel

Reputation: 15570

Yes it could, and based on my past experience, it will happen sometimes, resulting in hard to catch bugs.

You can work around this by using multiple tokens and accepting each etc. to overcome timing issues, but it will be very complex and complexity is the enemy of security.

However, you can just use the same CSRF token for the user session. If there is enough entropy in the token (ie. it's long enough), it will still be infeasible for an attacker to successfully guess it, so you don't have to generate a new one for each request. That solves all related problems while it is very simple and reasonably secure. OWASP also states (somewhere in the middle) that this is good enough.

Upvotes: 1

Related Questions