Search code examples
javascriptangularjssecuritycsrf

Risk of using a persitent XSRF-TOKEN cookie in Angular


This is related to this question CSRF Protection for Refresh Token Cookie in SPA

I want to use the recommended XSRF-TOKEN cookie mechanism to protect another HttpOnly cookie. For this scenario I need to make the XSRF-TOKEN cookie persitent, because it has to be available at app start up after a reload. The default implementation in Angular $http looks up in session cookies only.

What are risks if I make the cookie persitent and manually set the X-XSRF-TOKEN HTTP header?


Solution

  • What are risks if I make the cookie persistent and manually set the X-XSRF-TOKEN HTTP header?

    The risk is that an attacker could eventually brute force the token value.

    The recommendation is to have a new CSRF token per session. If you make this persistent then a malicious site could keep trying to submit a cross site request including a different token value each time. Eventually it will try every combination of token character and succeed in making the request.

    Practically however, the user would have to visit the malicious website at the same time and every time. This can happen with browsers that remember the user's open tabs and automatically load each time.

    You could also build in some brute force protection. For example, after 10 requests made with an invalid CSRF token you could abort the session and then inform the user that they have been logged out. This will mitigate the brute force attack, however this converts the attack into a Denial of Service attack as the malicious website will be successful at logging out the user. Therefore you should follow this up by contacting the user and informing them that a site that they are visiting is attempting to compromise them (you can check your server logs to determine the referer and origin headers).