Disclosure of Anti-CSRF Token in URL

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.

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.

Mould it as per your need

We had a discussion with our colleagues over XSS issue found in one application. Initially there was not input validation at all-you can insert simple script tag and execute XSS. Following our recommendations they filtered out certain special characters like (>,<," etc) also they encoded them at time of output. Fair enough? No. Actually they implemented half of the recommendations- ie. they worked on blacklisting and left out whitelisting. There are a number of models to think about when designing a data validation strategy, which are listed from the strongest to the weakest as follows. 1.Exact Match (Constrain) 2.Known Good (Accept) 3.Reject Known bad (Reject) 4.Encode Known bad (Sanitize) They were implementing last two of strategies only. So the application was now filtering out normal XSS vectors like "><script>alert(...);</script> based attacks. But what happens when we provide eventhalders like onmouseover,onload etc-XSS executed. When we brought this to customers' notice they said that alphabets and " (double quotes) are valid inputs in the comment fileds, how can we filter them out, not even whitelisting approach will work here as these are valid characters. So after a brainstorming session with them we advised them to mould as per their need. It's not like that you blindly follow strategies mentioned above for whole application. We suggested them for that specific case where " (double quotes) and alphabets were valid inputs (in comments fields) don't filter " (double quotes) but atleast filter even handlers-onload,onfocus etc by using this sample script: .replaceAll("(?i)<.*?\\s+on.*?>.*?", "");

It removes on* attributes like onLoad or onClick

My point is that in some cases you need to shape your strategies as per your need to strike a fine balance between security and user-friendliness.