I was reading document, and one question occurred. Why would we need to call this endpoint /sanctum/csrf-cookie to get CSRF protection when login?
I understand what CSRF is, and per my understanding, the practice that Laravel uses to prevent CSRF is to set a cookie xsrf-token on browser and then Angular or some framework would automatically attach the cookie to header as x-xsrf-token, and it's also called server side double submit as one of the practices to prevent CSRF
However, I just don't get why on Laravel Sanctum we have to manually call /sanctum/csrf-cookie before login. With Web guard, this protection is automatic after login without any manual work before login.
My question is what is the benefit or logic for calling /sanctum/csrf-cookie before login rather than automatically sending x-csrf-cookie to browser via response after login?
Anyone could help to further explain will be so much appreciated.
Related
Frameworks such as laravel and others require you place the csrf token in your HTML forms.
However at the same time laravel comes by default with the VerifyCsrfToken middleware that automatically creates a X-XSRF-TOKEN cookie with the csrf token on every response. This cookie is used for ajax requests and is automatically added to the header for axios for example.
I am wondering why is it required to add the csrf token to every HTML form. Why could you not just use the already existing X-XSRF-TOKEN cookie to validate the csrf token. I understand there is the issue of same site cookies, and if your csrf cookie is set to lax or none the cookie would be sent from an external site if they would POST to my site. However this issue can be solved by setting the same site to strict then there would be no need to set the csrf token on every form which is kind of annoying to do and remember.
Is there some security concern I am missing on why we just cant use a strict cookie for validating the csrf token?
An X-CSRF-Token protects users against unwanted execution of modifying requests, which are of interest for their side effects (the changes which they make to the server, or the database), not for their response, which the attacker cannot read anyway, by virtue of the CORS protocol.
A same site cookie would protect even against execution of navigation requests, which do not change anything on the server, but only read data (including X-CSRF-Tokens for subsequent modifying requests), which is then displayed in an HTML page. For example, if stackoverflow.com had same site session cookies, you would not be able to navigate from your webmail site via a mailed link to this StackOverflow question and immediately click to upvote it, because the session cookie would not be included in the navigation request, therefore you would not be logged on at first.
SameSite cookies do indeed provide significant protection against CSRF attacks.
But it's always better to put an explicit counter-measure in place - that is provided by anti-CSRF tokens.
For one thing, SameSite uses a notion of "registerable domain" so it does not protect you against subdomain hijacking
Finally, for these topics I very much recommend an excellent book Api Security in Action - they discuss CSRF and related topics in Chapter 4.
there would be no point in validating csrf token through cookies. That's the problem we are trying to solve. If csrf token was sent and validated as a cookie, it also could be sent, and is sent in cross site request. But when doing cross site request, as far as I know, attacker can't read that cookie with js and put it inside the form, only we can access that cookie with js. That's because when we set a cookie we specify domain attribute, and that cookie can be read with js, only on that particular domain. That's the reason why that cookie is not http only, and why we include it inside forms.
This is quite a simple question when I'm using JWT based authentication and there's seems to be no url that I can make a request to, if I want to logout. Is it practical to just simply clear the localStorage and refresh the page unlike token based authentication where you need to make a request to /token/logout/ ?
Using CSRF token in rest API is helpful or not ? as far as I know we don't have a session so we should send the token to client for next request or for submitting the form.
Is it helpful to use it again in ajax(xhr) calls. are there any alternatives ?
I've been reading the spring documents for this, and it also has some examples. but I was curious that is it really helpful or not ?
By the way My server is spring 2.2 and my client is Angular 9.
Thanks
CSRF tokens are essential for preventing XSS attacks, for instance you are logged into your bank, in one tab, and visiting my malicious site that will send a hidden form to your bank stealing your credicard number.
If you want to build a more secure site, every request that manipulates the state in the backend (POST, PUT, DELETE etc) should have a CSRF token included, to ensure that the request came from forms on your site and only your site.
You can read more about CSRF tokens on Owasps webpage.
How can I authenticate a user with sanctum when the whole login process happens server side? The question I am asking is kind of hard to phrase so I will explain my situation.
I have a Vue SPA for my front end and a Laravel app as a backend api (they run on the same domain). Normally, to authenticate with the laravel api using sanctum, you would send the credentials in a post request, and if the login was successful, you would get the session information returned. However, I want to use steam login for authentication. I already have to whole process on the backend figured out in terms of actually logging in, however I am unsure how to pass the session data back to the SPA. Currently I have a link on my site that takes the user to the login endpoint on the api, and that endpoint will have them authenticate with steam, so the entire login process is handled on the backend. Now I just need to figure out how to send the session data back to the SPA. I guess it world be similar to using sanctum with socialite.
So far I've tried usisng Sanctums Mobile Aplication Authentication. I did this by having the user log in into the laravel app using steam, then once authenticated, a access token for their account would be created, and they would get redirected back to the Vue apps call back file, with the token as a part of the query string. Then the token would be stored and . This worked, however it presented some security issues.
The token was passed back in the url, so anyone could screenshot it and use it
Anyone who obtained the token by some other method could use it.
Here is the code for what I tried: https://gist.github.com/DriedSponge/4e8549486c2bfa33e4c0b21a539bdf85
So in summary, I want the entire login process to take place on the server, but somehow at the same time authenticate the SPA. If you have any ideas on how I can make this work, please let me know. If you have any questions just leave a comment. Thanks in advance.
I am working on csrf and using spring 5. Spring 5 automatically provide supports for csrf and on enabling csrf protection on the server side I am getting
403: Invalid X-CSRF token
So this means a token needs to come from frontend?
My understanding is that backend generates csrf token and sends as a response to frontend browser and then it uses this token and send it as cookies to the backend server and then backend will validate it. is my understanding is correct?
when manually generating the hidden token for csrf, How backend will know it is a valid csrf token?
Second Scenario: Suppose two users are logged in to my website and frontend is sending this token to backend then how the application will differentiate which token is for which user?
Also please explain how it works internally means we enabled csrf protection in the backend and manually generated a token on the front end then what it does behind the scenes?
consider my frontend is JS pages
Is there is any specialty of Spring 5 which take care's of sessions for each user and validate tokens automagically for each user?. I tried finding it on the official website but didn't get it anywhere
Hi Zaib the csrf token is generated from back-end as you stated, once it is generated is automatically sent to the front-end which must take care to retrieve from the model and re-post for each "POST" requests.
You can share the csrf token via different way mostly i used header or html parameter.
A token is related to a specific session so is not really important if you have a logged user or not , even not authenticated users must send the csrf token for "POST".
The csrf token is validated via a filter placed in the front of the filter chain defined by Spring security itself, if you search in the documentation there is a table showing you the position of each "default" filter enabled by Spring security. Moreover if you enable debug on Spring ( </debug> is enough in your xml configuration) you will have printed all the filters used while processing an http request.
So each time a request with "POST" method pass through that filter , it will check if in the parameters there is the csrf token or header.
I never used as cookie so it may a different case for you if specifically need that but it does not differ on how it works.
Here is the details of csrf implementation on Spring:
https://docs.spring.io/spring-security/site/docs/5.0.7.RELEASE/reference/htmlsingle/#csrf-configure
I said "POST" method but actually the token is checked for any method that is related to a change of state , you can refer to doc here:
https://docs.spring.io/spring-security/site/docs/4.2.5.RELEASE/apidocs/org/springframework/security/web/csrf/CsrfFilter.html
Hope this help clarifying a bit the usage of the csrf token.