Automatically fuzzing for XSRF
Planet Websecurity has a great blog post up about the state of XSRF testing. In particular, there's a section that calls out one of the big difficulties in writing an XSRF fuzzer that would be as useful as most XSS fuzzers. This is mostly due to the fact that fuzzers, as they are mostly written now, use input/output matching to automatically flag vulnerabilities.
(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.
Why? If there's an XSS hole on foo.example.com and all the account changing actions have to be done on abc.example.com, you can't use the foo subdomain XSS to do a XSRF request on the abc subdomain because of the javascript engine's sandboxing. In addition, foo.example.com cookies will not be sent along by your browser with a request to abc.example.com. Note that example.com cookies, though, go to both.
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.
Why? If there's an XSS hole on foo.example.com and all the account changing actions have to be done on abc.example.com, you can't use the foo subdomain XSS to do a XSRF request on the abc subdomain because of the javascript engine's sandboxing. In addition, foo.example.com cookies will not be sent along by your browser with a request to abc.example.com. Note that example.com cookies, though, go to both.
0 Comments:
Post a Comment
<< Home