Is it a problem? I think no, as long as the token is Per Page, One-time use token.
Actually in one of the application, we had recommended to implement anti-CSRF tokens. When the application came back to us for verification process, we found that the application was implementing some sort of CSRF tokens, which were:
1) Going in GET request ie. were being added to URL.
2) Were being generated per page.
3) Were one-time tokens.
The only concern was the token in GET request. I mean it can be said that it is certainly not a best practice but the potential risk is very minimal. In a scenario where it can be exploited depends on following constraints:
1. The victim should be logged into the application (obvious).
2. The CSRF token must be transmitted in a GET request.
3. The attacker must be able to capture the token or from a repository (log files, browser cache etc).
4. The attacker needs to trick the victim to click on the crafted link.Actually in one of the application, we had recommended to implement anti-CSRF tokens. When the application came back to us for verification process, we found that the application was implementing some sort of CSRF tokens, which were:
1) Going in GET request ie. were being added to URL.
2) Were being generated per page.
3) Were one-time tokens.
The only concern was the token in GET request. I mean it can be said that it is certainly not a best practice but the potential risk is very minimal. In a scenario where it can be exploited depends on following constraints:
1. The victim should be logged into the application (obvious).
2. The CSRF token must be transmitted in a GET request.
3. The attacker must be able to capture the token or from a repository (log files, browser cache etc).
5. The victim's session that holds the exposed token should be still valid ie, it is not timed-put,invalidated,logout, expire etc.
The 5th point is major hurdle in executing CSRF in this scenario. In our case, although the application was exposing tokens in URL but it was generating them per page/request and one-time only. So even if you have got the token for the current GET request there is minimal chance that you can execute it as next time the user will be browsing the same page with some other unique token.Even if the CSRF token is exposed and the attacker is somehow able to figure out the associated user, the token is only valid for the lifetime of one request.
Also I had consulted with few security experts and one of them Ryan Barnett says:
Is the csrf token per/page or one-time use for each request? The difference being if a client accesses the same page multiple times is the token changed? If not, then GET may be an issue.
I have seen the following csrf token implementation strategies:
1) Per Session token
2) Per Page token
3) Per Page, One-time use token
#3 is the most secure as it prevents token reuse.
--
Ryan
So our application was changing the request and was one-time, so it was good enough!
We might have suggested them to put it into PUT request but again they had to do again some levels of coding. And as far as the things are secure enough in GET why to go for PUT. I am not supporting tokens in GET but trying to make a balance between security and client.
The 5th point is major hurdle in executing CSRF in this scenario. In our case, although the application was exposing tokens in URL but it was generating them per page/request and one-time only. So even if you have got the token for the current GET request there is minimal chance that you can execute it as next time the user will be browsing the same page with some other unique token.Even if the CSRF token is exposed and the attacker is somehow able to figure out the associated user, the token is only valid for the lifetime of one request.
Also I had consulted with few security experts and one of them Ryan Barnett says:
Is the csrf token per/page or one-time use for each request? The difference being if a client accesses the same page multiple times is the token changed? If not, then GET may be an issue.
I have seen the following csrf token implementation strategies:
1) Per Session token
2) Per Page token
3) Per Page, One-time use token
#3 is the most secure as it prevents token reuse.
--
Ryan
So our application was changing the request and was one-time, so it was good enough!
We might have suggested them to put it into PUT request but again they had to do again some levels of coding. And as far as the things are secure enough in GET why to go for PUT. I am not supporting tokens in GET but trying to make a balance between security and client.
Comments