There's no need, and no good reason, to change the CSRF token on every request.
So the only thing to do here is to work on your XSS protection.īefore I answer this, I should ask: is there a reason you think changing the anti-CSRF token on every request is necessary, or even beneficial? I don't want to say that there categorically cannot be a good reason, but I can't think of one. In fact, there is no CSRF protection that will help in that case, but if you are vulnerable to XSS you have bigger problems than stolen CSRF-tokens to worry about anyway. So how can a CSRF-token help? If the always checks that a random token unique to that session is present in the request, can not forge the request since the evil hacker running that site does not know what the token is.Īs you say in your question, this will not help if there is an XSS vulnerability. Note that this relies on the browser sending the cookie with the session ID to. If the victim is already logged in to her bank, the cookie with the session ID will be sent like usual by the browser and there is no way for the bank server to know that the victim did not actually intend to transfer the money. The attacker fools the victim to visit that contains a form that automatically does a POST to. (A minor point: I am not sure you need to change the token at every request.) But you should not feel safe just because some stranger on the internet tells you it looks good - make sure you understand what you are doing and why, otherwise your are bound to make mistakes. Using a CSRF-token is the standard solution to this kind of problem. You still need to submit it eg via the form. Storing the token in a cookie would be used in place of storing it server-side. With this approach, storing the token in a cookie instead of a form will not work (it will always be submitted and will validate against the server-side token).
That seems to be what you are referring to in your question. Unrelated: CSRF tokens always need to be in two places the most common approach is storing them server-side in the session and additionally in another place (eg submitting them in a form). In the same manner, if you allow a subset of HTML for some users, and your filter has a vulnerability that allows creation of forms, you will be vulnerable to CSRF. HTML injection will lead to CSRF via injection of a form, which increases the impact of HTML injection a bit. If your application requires users without the highest level of privilege to create forms, then they can perform CSRF attacks as tokens will automatically be added.
Scriptcase csrf token expired code#
If you have cross domain forms you need to be careful that your JavaScript code doesn't add CSRF tokens to them, as it would leak the token. But you need to be aware of a couple of issues: You can dynamically add the CSRF token to forms via JavaScript.
0 kommentar(er)
