CSRF Token in GET request

  • According to the OWASP testing guide a CSRF token should not be contained within a GET request as the token itself might be logged in various places such as logs or because of the risk of shoulder surfing.

    I was wondering if you only allow the CSRF token to be used once, (so after one request it's invalidated) would this still be insecure? Considering that by the time someone logs the token, it will already be invalidated and unusable should the attacker want to perform CSRF.

    If you're generating the tokens in a secure random fashion, then an attacker cannot infer the next token from the previous ones. So there shouldn't be any realistic risk. It feels weird telling _you_ that.

    I just wanted some kind of confirmation

    @LucasKauffman I can't find a reference of "CSRF token should not be contained withing a GET request" can you please share if you have any OWASP reference for this ?

  • Adi

    Adi Correct answer

    8 years ago

    If you're generating the tokens in a secure random fashion, then an attacker cannot infer the next token from the previous ones. So there shouldn't be any realistic risk.

    Another important point here is to use SSL. Any proxies/reverse proxies between the user and the server cannot even see the GET parameters to log them. The only places where the token is logged is on the two ends of the SSL connection.

    Logging on the user's end (History, for example) happens after the link is clicked. Logging on the server's end carries no risk (if you don't trust the place where the SSL traffic is decrypted, then there are bigger problems).

    Of course, TLS/SSL is important, however if a MITM/proxy can grab a CSRF token then they can grab anything anyway. Avoiding logging shouldn't be a reason alone, as CSRF tokens should be session based and should have expired by the time logs are archived.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM

Tags used