It is hard to write a zero knowledge signature for XSRF that is *accurate*. - Planet Websecurity
(it appears that the original of this post is over on O'Reilly: The Complexities of Assessing XSRF Automatically Yet Accurately by Nitesh Dhanjani)
It's true, it's not simple. It's not impossible, though, to write a generalized XSRF fuzzer. First, the fuzzer should be able to record a web app login and use it for fuzzing. Then there are three things to think about:
* the fuzzer should try every GET/POST both with the login cookies and without them
* it should try every POST request that it came across as a GET as well
* it should try GET/POST requests by swapping different subdomains or swapping out the subdomain
The reason to do the first is to identify actions that react differently when the user is logged in/not logged in (and flag ones where it's different as potential XSRF surfaces). The second one is similiar- web developers who are aware of XSRF sometimes try to protect their apps by making requests only work through POST (hint to those developers- that's not a good fix). The last one is because those developers also try to protect their web apps by only taking POST/GETs that modify acct information on certain subdomains of their website. Sometimes they do this for the same reason as the POST-only limitation, and sometimes they do it because they're trying to protect against XSS.