What would be the recommended way (simple, and secure) to initialize CSRF token when working with Single Page Applications?
I have figured out some possible solutions but all of them have some downsides:
a) Before login or any request, create CSRF request to obtain a token.
Downside: The Client/frontend should implement logic to request CSRF if it is missing
b) Exempt login request from CSRF protection and initialize token on every login
Downside: Is it safe to exempt login from CSRF protection?
If using multiple endpoints and Single Sing On, we still need to init CSRF token in every endpoint
c) Init CSRF token when the client request a frontend code (on SPA load / refresh)
Downside: Complex logic and extra request to backend needed in frontend providing endpoint
If we use multiple endpoints and can not validate the same CSRF tokens in every endpoint we do not know where to init the token
The current solution/answer to this problem is the following:
Client sends a CSRF token request
Server adds CSRF token into client cookies
Client sends a login request with his credentials and copies the CSRF token from cookies into headers
Server checks the cookie & header match and processes a login request. The server sets a session cookie and rotates a CSRF token.
Other (login required) endpoints check header & cookie match AND validate session cookie.
When working with multiple endpoints
Implement BFF or proxy server which handles the CSRF protection. Allow connections to the server endpoints only from the proxy/BFF server. The endpoints does not need CSRF protection anymore.
All requests from Client / browser is routed through the CSRF protected BFF/proxy server.
Pros
Login requests are now protected with CSRF
If multiple endpoints are needed, only one CSRF token init request must be done.
CSRF token is rotated and unique in every new session.
Cons
Client/frontend should implement CSRF request logic and missing CSRF token error handling thus increasing the complexity. CSRF token init can not be done silently for example during the login request.
When working with multiple endpoints, separate BFF/proxy server is needed.
Related
I have Single Page Application(SPA) with multiple endpoints using Singe Sing On(SSO) with JWT token. I try to figure out how to initialize a CSRF token while still keeping my frontend and backend logic as simple as possible.
My question is: Is there a way to avoid generating a CSRF token for every endpoint? So can I, for example, generate CSRF token during my login process (first fetch CSRF token and rotate the token in every login request) and then verify that one CSRF token in every backend? How could this be implemented if it is somehow possible?
I use X-CSRF tokens, so on the server side the token is set to cookies, then the client duplicates it to request headers and finally server verifies that cookie and header value match. I use django csrf middleware which also does some extra validation to avoid client self generated tokens. This extra validation is something I do not really understand
In my opinion, what you have in mind is not possible. But you could communicate with a proxy that knows the other endpoints. That would make the most sense from my point of view. So you only need the CSRF token for this one endpoint. And on the server side from the proxy to your other servers you don't need CSRF anymore. But this solution means you need an additional endpoint.
Consider I'm creating a RESTful API (like Twitter API) and I need only a single key token to access the endpoint GET /messages.
The token needs to be sent via header access_token for example.
If I don't pass the token I'll get an 4xx error.
In the RESTful API scenario, is this all needed to protect against CSRF attacks? I mean, in RESTful APIs I'm not using Cookies to manager a user session, since the idea here is to not be a session (Stateless is one of the principles of REST).
Am I forgetting something or is this correct? I don't see why I would need a anti CSRF token besides my access token.
Thanks in advance!
Short answer: if your access_token is not a cookie, yes, it's enough to protect you against CSRF.
Long answer:
A CSRF attack can only happen when HTTP client automatically sends some authentication data(usually cookies) to server. The key point is attacker do not need to know the Cookie, it's is automatically sent if web user accesses 2 sites(your site and the attacker's site) using the same browser.
To anti CSRF, server sends to client a private token that browser does not automatically send it to server(so it's must not be a cookie). The developer has to write code to attach the token to each subsequent request.
CSRF is an issue for using Cookie by Web browser, if you are developing restful API that is not used by web browser, usually, you do not need to care about CSRF
#Bart Firstly CSRF attacks are usually from a trusted user. Which means that the client has successfully authenticated himself by maybe passing a valid token in case of a rest API. The attack could be by passing let's say a javascript which can change the state of a resource. So just having a single key token won't really help to avoid CSRF attacks.
Please refer to below URL for more reference on CSRF :-
https://en.wikipedia.org/wiki/Cross-site_request_forgery
Most of the frameworks like Spring have inbuilt support for CSRF.
I have 3 services (in the real much more):
Authorization service (uses OAuth 2.0)
Frontend service
Resource service
and client (web-browser).
I store session_id, access_token and refersh_token in cookies of the user's web-browser. The user goes to Auth service, signs in and gets these tokens. After his web-browser is redirected to Frontend.
Frontend and Resource services can't validate tokens because they know a nothing about it, so they must make a request to Auth service.
The current scenarios:
The user (web-browser) sends a request to Frontend service, the Frontend sends a request to Auth service to validate access_token. If it's invalid the Frontend sends a request to refresh token using refresh_token.
If the Frontend needs an access to Resource service to process a request then the Frontend sends its client_id and access_token to Resource service. The Resource service sends a request to the Auth service to validate an access_token too.
Are my thoughts right? Or it has simpler schema?
P.S. All services use RESTful architecture.
OAuth talks about how the tokens be exchanged. What you have mentioned it seem liek you are talking about using implicit grant, which is little less secure and you may think of opting for authorisation flow.
Other than that, in microservices when you have many services and one user request pass through many downstream services, verifying the token with auth provider at each and every step might become a bottleneck.
There are ways out there by which you can skip this call to auth server and still validate the sanctity of the token without making an explicit call.
One way is to make use of JWT. These tokens are signed by the Auth provider and your services have keys which can help you validate if the token is modified on it way, and token itself has all the information you need to ensure validity of it, like expiry time, intended audience, clients, roles etc.
On login you get AT and RT. AT could be passed along to downstream for authentication and authorization and RT could be used when AT is expired.
You only need to talk to auth provider at the time of login and when you need to refresh the token.
You can read more about the JWT OAuth2.0 with JWT and OIDC to get more information around it
I've been reading about JWT, and from what I understand, it's a token that the server sends after a user logs in. The user will have to send that token with all future HTTP requests. This creates a stateless way for the server to verify a user's request.
Now what I don't understand is that if the JWT is sent in the header and marked as HTTP only, why is a CSRF token also needed for prevention of CSRF attacks? My understanding is that both JWT and CSRF tokens are tied to a user, and that a JWT would serve both purposes.
I understand that CSRF tokens are used so HTTP requests from other sites won't be accepted. How does a JWT not accomplish that? What separates a CSRF token from a JWT token, and allows it to accomplish that difference?
I've been reading articles on JWT's and CSRF tokens as well as the double submit method, but there is just something I can't seem to understand or I'm missing.
An authentication system based on tokens (JWT or random) stored in cookies is vulnerable to CSRF attacks, because cookies are sent automatically to server in each request and an attacker could build a harmful url link to your site.
https://yoursite.com/delete?something=1
To protect your site it is needed to use a CSRF token that your application must send in the following request (not in a cookie).
Alternatively you could store the JWT in localStorage and send it in a Authorization header, then your site is protected against CSRF, but it could be vulnerable to XSS attacks. Take in account always the security considerations of the technical solution you choose
Update ¿why storing JWT in localstorage could be vulnerable to XSS attacks?
See this comparison between storing tokens in localstorage and http-only cookies https://academind.com/tutorials/localstorage-vs-cookies-xss
An attacker could inject javascript code to read the token from the localstorage and send it to his own server. However, this type of attack is not possible with an http-only cookie because it is not accessible from javascript
All your questions are relative to the fact that a CSRF token in NEVER included in a cookie and that a JWT token MAY be sent in a cookie.
A JWT token can be sent:
1- in a cookie
2- in another type of header
3- outside the headers, in some POST attribute
4- outside the headers, in some GET parameter (not very common)
But for stateless authentication, you MUST use cookie (case 1).
So, for stateless authentication, you are prone to CSRF, with your JWT token. This is why you need to add some CSRF mitigation mechanism, based on some more information not included in a cookie, or not only included in a cookie.
All of this would not apply if you were accepting to implement a stateful authentication.
I'm struggling with setting up reliable and performant solution to communicate frontend with different microservices. I do not really now how to maintain (maybe not need) CSRF between my frontend and end services
Solutions stack: PHP, Laravel Passport, JWT, oAuth 2.0, Axios
Current approach:
Actually I've started up with approach from Laravel's passport
https://laravel.com/docs/5.4/passport#consuming-your-api-with-javascript
Using oAuth 2.0 to authorize user from website A to service B.
JWT token is returned for further communication.
Token is saved in cookie within website A
Once user is authorized website A uses JWT token to manage requests without additional to oAuth server, by sending JWT token as cookie using HTTP headers (withCredentials) to authorize user.
For each website A's request there was CSRF token created from service B since user is authorized and cookie could be applied by another unauthorized website to access service B. That was killing my performance since it has to retrieve CSRF for each request made. (that what I actually assume from laravel passport approach and need to create CSRF with JWT token - maybe that was mistake)
My concerns:
Regarding to of James Ward post:
http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
The easiest way to do authentication without risking CSRF
vulnerabilities is to simply avoid using cookies to identify the user.
Cookies themselves are not the cause of CSRF vulnerabilities. It’s
using the cookies on the server to validate a user that is the cause
of CSRF. Just putting an authentication token into a cookie doesn’t
mean it must be used as the mechanism to identify the user.
From my understanding setting JWT with website A's cookie with its domain set could not be accessed via any other site from outside. Since that there is no possible way to make request to service B without accessing JWT.
So do we really need CSRF then to secure potential attack to service B while using JWT?
If so, how could I achieve the best (in term of performant) way to generate CSRF through different services to be sure that communication would not be vulnerable for attack from different sites?
Any advice will be appreciated!