1

In a website that have CSRF protection done using a token added as an hidden element in forms, if a session and a token is generated before login to protect against login CSRF, should you reset the token if the user successfully login?

I don't see how an attacker could get the token from the login screen (as the victim) and use this token once the victim actually logged in, but I might be missing something.

  • 1
    what you are doing now sounds fine, unless they can stay logged-in forever. – dandavis Apr 29 at 21:19
2

if a session and a token is generated before login to protect against login CSRF, should you reset the token if the user successfully login?

OWASP recommends that session tokens be renewed on a successful login to prevent session fixation attacks,with CSRF attack the thumb rule is a token which cannot be guessed by an attacker beforehand and forge a request with it.Your application logic seems to follow that rule.Unless you messed up somewhere else this should work.

  • Thank you, do you have a reference to that recommendation from OWASP? I looked and didn't find it – Galdo Apr 29 at 19:32
  • which one session tokens or csrf? – Vipul Nair Apr 29 at 19:38
  • 1
    I found a reference to renewing the session id after a privilege level change in this document : owasp.org/images/archive/9/9a/… Renewing the session ID after login automatically implies changing the token in the framework I'm using so that would answer my question. – Galdo Apr 29 at 19:38
  • well glad to be of help. – Vipul Nair Apr 29 at 19:41
  • A complete answer explaining why you MUST reset the CSRF token after login is available here : security.stackexchange.com/questions/22903/…. The reason is the same for session ID and CSRF token – Galdo May 13 at 20:12
-1

CSRF tokens should be generated new every time you load a page. The idea behind CSRF tokens is to validate the request's authenticity. If two requests are made with the same CSRF token, it can be assumed that the second one is a replay and shouldn't be executed and is invalid or fraudulent.

CSRF tokens are used to protect any critical functionality, not just log in. Which means that every page load a new CSRF token should be generated.

So to answer your original question, typically XSS vulnerabilities are combined with CSRF. The XSS will dynamically call javascript that pulls the CSRF token from the webpage that is being attacked and introduce it into the CSRF form. So if the XSS is on the login for example, if you reproduce the CSRF tokens each page load, the attacker will only have secured a login CSRF token which in practice is useless. By regenerating the token each page load, you are limiting the scope that the CSRF token can be used abused in.

  • 1
    While this enhance security, this is not what OWASP recommends for general use cases. This approach is only recommended for highly secured websites as it has a lot of drawbacks (like breaking the back button in browsers). For general use cases, OWASP recommend to generate the token once per session. My question is : should I reset it after a privilege level change. (Reference : 2 last paragraphs of this section : github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/… ) – Galdo Apr 29 at 20:09
  • 1
    I work for an unnamed fortune 500 company's red team, and I can tell you that you're wrong and you don't understand OWASP's recommendation. Let me provide you an example. Say you have a password reset function, if you don't reset the CSRF token each page load and an attacker intercepts your CSRF token when you log on using XSS payloads or network layer MitM attacks, they can now force you into submitting a payload that will change your password to one that is completely in their control using Ajax to asynchronously make the POST. I'd appreciate if you changed your vote. – leaustinwile May 3 at 19:08
  • So yes you do need to reload each page load and if you implement the synchronizer token pattern as OWASP specifies in their recommendation, it will automatically change on page-load, because that's how the algorithm works.See this related post for more information: security.stackexchange.com/questions/55971/… – leaustinwile May 3 at 19:09
  • Sorry but I'm not the person that downvoted you and I understand your point, but I would like you to explain me what I missed in that part of the recommendation from OWASP : "To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and/or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. This is more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal. However, this may result in usability concerns." – Galdo May 7 at 13:44
  • 1
    So to answer your original question, typically XSS vulnerabilities are combined with CSRF. The XSS will dynamically call javascript that pulls the CSRF token from the webpage that is being attacked and introduce it into the CSRF form. So if the XSS is on the login for example, if you reproduce the CSRF tokens each page load, the attacker will only have secured a login CSRF token which in practice is useless. By regenerating the token each page load, you are limiting the scope that the CSRF token can be used abused in. – leaustinwile May 7 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.