Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
2  
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. –  Adnan May 30 '13 at 11:43
    
I just wanted some kind of confirmation –  Lucas Kauffman May 30 '13 at 12:19

3 Answers 3

up vote 5 down vote accepted

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).

share|improve this answer

It's probably secure enough, but it doesn't entirely eliminate the shoulder surfing and logging problem. An attacker could temporarily DoS the network so that he can use a shoulder-surfed token before the user gets a chance to, and a request may show up in logs but not get invalidated when the website (or database, or network) is down during an attempted pageload. Beyond that, I can't think of any vulnerabilities that don't also occur when you put the token in POST-data.

I'm not sure it's practical to invalidate all tokens after usage though. I often open multiple pages in a new background tab, for example on older SMF forums I middle-click the delete button of private messages so that it doesn't need to reload the page before I can delete another. You can generate a unique token for all links appearing in a page, but then you get to a level of complexity where you might as well start using HMACs instead of a simple token.

share|improve this answer

Considering that by the time someone logs the token, it will already be invalidated and unusable should the attacker want to perform CSRF.

There is a corner case if the user gets the address but fails to actually use the token (due to transient network failures etc). It's unlikely this is significant enough to worry about for a CSRF token, but can be a problem for other more sensitive tokens.

Single-use CSRF tokens tend to pose usability problems, though, such as breaking navigation and multi-tab browsing... not to mention they're super-ugly. :-) Given that GET requests should be idempotent and thus not in need of CSRF protection, token-in-URL is usually a design smell. But I doubt there's much you can exploit here.

share|improve this answer
    
GET requests don't need a CSRF token because they should not change the server's state. Idempotence is not a sufficient condition. Consider PUT requests which are idempotent but still potentially vulnerable to CSRF. –  CodesInChaos Aug 6 at 15:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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