Menu
I understood the purpose of the CSRF Token protection.
However, I think this protection is useless and we should remove it in the case of a REST API requiring an authentication token in the header for each action.
This way, even if Mallory forges a malicious HTML link to Alice, the attack can not be done. The reason is that:
Alice keeps her authentication information in a header key that Mallory don't know. And unlike a cookie, Alice's browser doesn't submit this authentication token automatically.
So in this context, I would like to have you point of view about the question: can we remove a CSRF token protection from this kind of API design?
406
Considering the following facts, using CSRF token for a restful API (which of course is intrisincly session-less) seems inevitable: storing JWT in local storage (any where other than http-only cookie) makes the API vulnerable to XSS attack. storing jwt in http-only cookie makes the API vulnerable to CSRF attack
The client can go ahead and send the access token thus acquired to api.example.comwithout CSRF, as no cookies will be sent to that host. So, you can still safely avoid dealing with CSRF on your REST APIs. But your login / authentication server better be bullet-proof (and CSRF protected).
This service required an access token to get the data. Here we will use the axios npm package so it will automatically read the XSRF token from the cookie and append it in the request of the API call to avoid the CSRF attack. If the XSRF token is not present in the request header then the private route won’t be accessible from the server.
Part 3 – Implement authentication in ReactJS using REST API with CSRF protection (You are here…) 1. Create secure REST API in Node.js To create a secure login application, first we have to create a REST API so we can consume it into the react application. We have already created the REST API in Node.js for authentication.
Yes, you don't need CSRF protection when using a bearer scheme authentication as the browser does not automatically add the Authorization header to the request.
You do need CSRF protection for cookies, basic, Windows, digest and client certificates authentication schemes as these are automatically added by the browser.
See also Dominick Baier's article on implicit vs explicit authentication: http://leastprivilege.com/2015/04/01/implicit-vs-explicit-authentication-in-browser-based-applications/
184
Theoretically, you don´t need CSRF protection as you described. But one of my main concerns is where to store the access token. The local storage of the browser does not provide a good security. So it´s often stored in cookies. And so, the CSRF vulnerability comes back.
Jean-Christophe Baey described in his article a two-cookie mechanism to prevent access tokens from CSRF and from being stolen by XSS.
To sum that article up: The payload of the access token is stored in a cookie that is accessibly by JavaScript. The signature of the access token is stored in a cookie that is NOT accessible by JavaScript. The client reads the payload from the cookie and passes it in the Authentication-Header to the server. The server validates the token based on the signature which is sent in the HttpOnly cookie.
So, its CSRF-save and an attacker cannot steal the entire token via XSS because there is no JS-access to the signature.
22
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
