I spend a lot of time searching for the solution for this problem, but with no luck so I am hoping somebody can help me.
I enabled CSRF protection and set csrf_regenerate to true (I want to regenerate the CSRF token on each request).
I am testing with my login form. The problem occurs when first submit the form with invalid data and the refresh the page (F5). I get thew error: The action you have requested is not allowed, so the CSRF token validation failed.
I noticed that when submitting the form with invalid data, CSRF request and response tokens do not match and I thing that is the cause of the problem.
I am guessing I'm not the first one with this problem, so I really hope somebody can help me out.
I you need any additional data please let me know.
Thanks and regards, Gregor
Related
When I upload a file through my app that uses Spring framework and spring security, it sends a CSRF token in the request through Spring to prevent CSRF. This token does not seem to be generated as it's left out of the request URL in Firefox. Again, this is happening in Firefox only. Does anyone have any experience with this and/or have any insight as to why this is happening? I've tried accepting cookies from this website in the browser and doing a few hacks in my code to allow it, but none of it seems to work. Thank you.
In case anyone is wondering, it turns out that my async call to retrieve a new CSRF token wasn't firing on time and the form would post without it, hence causing this error message from Spring. Check if you're posting the form prematurely if you're getting this error.
Why does recaptcha v3 throw an error ?
... when I check the humanity of a visitor a second time on the same page?
Token is clearly NOT a duplicate.
... so what is a duplicate?
First token:
03AEMEkEl76Kn0nMhKlgY8dMOAD2g3zGIHoGOqz95jEFKl8A24gADw-2gBipDYcU7G_TWSqpuWyNa62CIk-tYdreevde0p1lJg_3wwZlmD9giDSdPb_He-mTsIqv0tMuEroJLLArCI4vfbZjcCZ6BYokYEhYbCU-Qqdx9YbqgRG1JJDxE8LRagR0cPY8mfQZ5bZ7KGK8Dfqe8avqOy18RvIcYk-H6s9Bhq28s5YRIkHid163c-yqpeY8U5j9U70aveSuEcLz-UMlgsQ8MaYhHIIv7cJpag2RJFAgGxOZnWONEk2Z9-IK_Ea_4
recaptcha v3 Response:
{
"score":0.1,
"hostname":"localhost",
"success":true,
"challenge_ts":"2018-07-17T21:24:03Z",
"action":"AW___________LGOZCKiH_oQBEJnwwYcD"
}
Second token on same page with same label:
03AEMEkEk-CVItfMmzYErG97inmxzf7mIeWuAgEXmwncu8AvMGP0ofXnwCMFNdBpa7CY8MCkVZ_skiF1HwmGhKBgayFm-fM3VM_QfM5LRNDbxLLyCF8lGclmBBlihmkeT1PsvW9LrVfp2VdikuHxeqvviGnI2NKQHbclvaDnuu5rwy3HS_EiPrn7eJb3z892f8oIOMkVg6tTsCNPCTnH5QuvAIw2DlI3EiRFDSqIjXp4vJdzJIGn10K6Noi1JIPOCzJ8OUshn_yFROWvNNpYNFn3E7tSHk3j0LU9-KDy1RiSoEf2I1VcVEKTE
recaptcha v3 Response:
{"error-codes":["timeout-or-duplicate"],"success":false}
Yes, This is the error code we get in two case.
1) When we send same token for two requests
2) The token gets expired in every 3 minutes. So if the user do not submit the form in 3 minutes then the token gets expired and we get this error message.
The token might have timed out. It happened to me also. On page rendering, a token was generated but I performed an action after a long time. Then it gave me this error. But if the token is generated on action performing then it works fine.
I had a similar problem, but I realized it was not a good understanding.
This error message happens when:
1. The token was already verified, so it becomes "duplicate".
The token was executed 3 minutes or more before it was verified, so it becomes "timeout".
Regarding the second scenario, the idea is to verify the action when the action is executed. Meaning, if you want to verify a submit operation, then you may need to generate the token to verify when submitting, not right after the grecaptcha Object is ready.
Online documentation has an example where the execute methods is invoked right after the grecaptcha is ready, but that's the case when you want to verify that execution right away. In the case of formularies, the execute method should be placed in the same routine of the form submission, makes sense? Probably I am mistaken, but I have been able to verify click actions, form submit actions, close popups actions, you name them. 😉
The monstor captcha token generation at the time of page load is definitely is not a good idea as it expires after 2 mins. If still you bound to do so, you have to renew the token after some time intervals using 'setinterval' in JavaScript.
So to generate the token on button submit 'execute' will do your work better. You can call ajax or java script to call the execute method. Please refer google reCAPTCHA v3 documentation for more information.
I'm trying to better understand the mechanism for how Spring CSRF protection works. Suppose I have a site https://example.com/ where people can vote on candidates. Users can also exchange messages. I also have a user logged in, and another user that sends her a message saying to click on the link https://example.com/vote/candiate/30.
If a user clicks on this link, won't the browser send both the CSRF token and the session ID for the logged in user, thereby bypassing the CSRF protection check?
The reason a link is usually not a problem regarding CSRF is that CSRF is only an issue when the request changes something. A link (a GET request) should not change anything. If it does, like in your example it adds a vote to the candidate I suppose, any link from an external origin (a different website) would also be able to exploit "normal" CSRF by just linking to that url.
The problem in the example is not that CSRF protection is inadequate in Spring, the problem is that voting in this case is a GET request, and GETs are not usually protected against CSRF by design. The solution is to change the vote request to a POST, which would then be protected against CSRF (and which would also be more RESTful btw).
Main idea :
When request is submitted, the server received special cookie and waits for defined value in this cookie. If this value will be differet , the request should fail.
So, if service returns form for moving money between accounts, this form includes parameter, that expected to receive when form is submitted, and if data would be sent without this parameter, request wouldn't be proccessed
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.
I am having a very weird CSRF protection problem in CodeIgniter. I have made sure that I use form_open to start my form, csrf_protection is set to true in the config file, and I have also made sure that the hidden csrf name and value fields match the csrf cookie as seen here: http://d.pr/3cfB.
What happens is that when I submit the form, I get "An Error Was Encountered. The action you have requested is not allowed." error and am not sure why. The form works fine when I turn the csrf_protection off.
What's even weirder is that I use tank_auth library for my authentication and it also uses form_open for the login form. I did check to make sure that there is a hidden csrf field in the login form when csrf_protection is on and I was able to submit the form and log in with no problem.
Thoughts on what I can do to debug this problem?
To begin with, the session class is expecting a token named 'csrf_token_name', not one named 'csrf_salemarked_token$...'.
This blog post covers AJAX with CSRF Protection in Codeigniter 2.0.
Tank_auth is getting the token from the hidden input form field, rather than the cookie. Your AJAX requests need to get the token from the hidden field if available, or the cookie if there is no form.
I found the problem. In one of my custom libraries I have parent::_sanitize_globals() which apparently was what's causing the error. I read somewhere that if I have xss filtering turned on, I don't need to do sanitize global.