Yes I understand the function that’s why I said kind of, it’s a mild annoyance to the user oucassionally so okay kind of bug but not really it’s possible there is a solution to the time outs but it’s not high on my list of things to deal with.
I suspect this would've already been considered - but why not a simple keepalive service to refresh the token every so often?
Wouldn't that kind of defeat the purpose of the token?
The purpose of the token is to verify that the user is the same user and not a third-party interloper sending fraudulent bits. Shouldn't make much difference if it lasts five minutes or five days - as long as the token itself isn't compromised then it serves its purpose.
By the Same-Origin Policy, hacker.com can submit data to poal.co (either via GET or POST hackery), but cannot actually read the responses from poal.co (which goes to the user, and not to hacker.com). Since hacker.com can't read the responses, it can't get the same token issued to itself as what is given to the user, and thus the csrf token (which should really be called an anti-csrf token) serves its purpose.
I'd think (and if anyone knows better, I'd ask them please to correct me here) that a simple keepalive for the token that persists while that user session is open, shouldn't cause any real security issues, at least in any sort of normal use case (I can see an edge case developing with really long lived tokens, which may expose cryptographic weaknesses in the token generation itself, but other than that nothing immediate comes to mind).
(post is archived)