Used this flask example for implementing a csrf token in my cherrypy app for all my site's forms...
flask csrf token example
However when a user's session times out the csrf token in session becomes None.
token = cherrypy.session.get('csrf_token')
if token is None or token != cherrypy.request.params['csrf_token']:
raise cherrypy.HTTPError(403)
How can I work around this?
Thanks in advance!
There is not need to work around this, as the behaviour you are describing is correct. If the csrf token persists for a long time, it is not very useful - the whole idea is that it is not reusable, at least not over a long period of time.
Related
I have created an app on laravel and vue.js and for the authentication process, I have used the laravel-shopify package. right now when the Axios call duration is long that time gets a session token expired error. I have already referred this solution but this was not worked for me.
Shopify App-bridge session token is having some issues while working with the vue.js and Axios?
Please check attached documents, please check.
video:- https://drive.google.com/file/d/1US2dzgcPWm6iQcK4SMS4b6q85q9l89Mx/view?usp=sharing
When I have passed many files to Axios, I don't want to get expire token error. Does anyone have a solution for this?
When I need to do a front and back which speaks to each other with APIs, I do like this:
the user connects with their login/password
the back checks and if it is good returns a token to the front
the front stores this token in the localStorage
and for all future requests, the token is added in the form of Bearer
and for each request, the back checks the presence/validity of this token (middleware)
Perfect. Everything works.
Except that I read that storing the token in localStorage is not secure at all. And that it is better to use cookies. And this is precisely what Sanctum allows with Laravel. If I understand correctly, with Laravel Sanctum no more need for a token, everything happens with cookies between front and back. This is what I see with my different tests. I understood well?
I am disturbed by this.
What is the best practice when it comes to CSRF token expiration?
Say a user is visiting a page (Jinja template) with a form, but tries to submit says form only n hours later. The CSRF token is obviously expired by then.
Of course I could stretch the token's lifespan, but I'm looking for a better way to do this.
Should I try and fetch a new token through an ajax request, before submitting the form with ajax?
I am using codeigniter 3.1.9.
I have enabled my CSRF protection with csrg_regenerate set to true. It works fine, the token regenerates every time on Post request, validation works as well. On top of that, I have also set my cookie to same-site strict connection only.
I then submitted for penetration test assessment to the security team, they rejected my work because of csrf attacks vulnerability.
The argument was, they changed the cookie token and post params, then perform the attacks.
Here is the proof:
Their response : CSRF token is not securely implemented. An attacker can still perform a CSRF attack using any value to the csrf_cookie_name Cookie and csrf_test_name parameter.
How can I solve this ?
Thanks
Its the first time to see a security token stored in cookies on the client side that's why of course your system is vulnerable.
You must store the token in your session that makes them impossible to retrieve.
The way to implement it:
Create a hidden input in your form with the csrf token and on form submit compare it with your token that is stored in the session.
Using JWT Auth + Laravel and Ionic for a mobile app.
I want to have the users stay logged in until they log out physically with a button. JWT has '60' (an hour) as its TTL for the token.
I know I could just increase this and be done, but I imagine there is a reason to having it only an hour by default.
There is lots of terms for refreshing tokens etc but can anyone give a quick summary of how to deal with long term tokens?
Do I set a refresh every 60 minutes, every request or is having a long TTL fine?
If you look at the jwt-auth package wiki page on authentication. There is a middleware Tymon\JWTAuth\Middleware\RefreshToken the way this works is.
This middleware will again try to parse the token from the request,
and in turn will refresh the token (thus invalidating the old one) and
return it as part of the next response. This essentially yields a
single use token flow, which reduces the window of attack if a token
is compromised, since it is only valid for the single request.
in my opinion as long as your application has fairly constant communication without long periods of inactivity ( more than your 60 min window ) this is the best way to go about keeping your token fresh.
If your not using the jwt-auth package you can still apply the logic you just need to pass back a new token in the header of your response, see the RefreshToken Middleware for an example of this.