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.
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).
GET requests should be idempotent, which means you can't invalidate the token once used because any repeat requests won't give the same response.
GET requests should also never make state changes to the system, therefore should not be required to have CSRF protection. Even logout should not be a GET request for the method that actually executes the logout (although you could have a GET link that navigates to another page before a POST request carries out the action).
To fix the idempotent problem, with a repeated GET request and with the same CSRF token supplied, you could display the cached response from the first request, without making any state change. However, you're still violating the standard if you make state changes at all, see rfc7231:
Request methods are considered "safe" if their defined semantics are
essentially read-onlyOf the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe.
As a side note, I would also argue that resource intensive processes should also be POSTs (with CSRF protection) rather than GETs, otherwise an attacker could DoS a system using a CSRF vector.
Therefore, if you need CSRF for a method, then don't implement this as a GET.
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.
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.
