(01-27-2017, 08:40 AM)Narf Wrote: Well, no ... actually because of a bug that was fixed in 3.1.3, which also contains a lot of other security patches. You should've updated first.
There's a few bugs that slipped through in that release, I'm waiting for 3.1.4 to see if it's stable.
(01-27-2017, 08:40 AM)Narf Wrote: Not just the approach, the entire idea is bad.
Knowingly submitting a request that you know will fail is obviously bad, but while tracking the token by expiry time would be more clean, it is still not a bullet-proof approach. In any case, whatever you do will amount to the same effect as setting a huge expiry time.
But the real problem is that you're going out of your way to disable a security feature. Often overlooked, but CSRF also prevents against replay attacks, and against someone physically impersonating careless users who leave their browsers open. What you're trying to do nullifies those protections and you'll now always refill the form with a valid token.
I don't follow. One of these two will happen;
1. User submits the form, sees a 403, clicks back and refreshes the page. User submits and it goes through.
2. User submits the form, 403 is handled, corrected, and the request goes through.
The first is a bad user experience. If they use the back button and not a link on the 403 page they have to refresh the page again or they will see another 403. They aren't going to understand the message, why they need a token, why leaving a page open causes this to occur, etc. In either case if the user is in front of the computer (being theirs or not) they will gain access.
It's not feasible to use csrf_regenerate in our application as we make a lot of concurrent requests. With this change we could, but it would not be performant and would result in a lot of duplicate calls to pull updated tokens.
The token is not stored in the form. It's saved as a property on the main app class (js) and passed to conduits each request. Every response includes the new token which is handed back to the app class for future use.
Our setup is a bit unique in that the only way to make a request is via AJAX post and the entire app is behind a login. Other than a few specific routes that allow get requests, but will not respond to system requests, it's the only way to talk to the app. CSRF is only one layer of protection we use we do not rely on this as the sole means of access.
