Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc....

He's just explaining how CSRF can be detected by robots. You input some data, see if anything changed once you did. Then it's a function of some sort. Then you try to exploit it by getting someone else to do it for you with their credentials. Poof, CSRF in a can.

Thing is, how it is implemented again. because if I reference two iframes to a website, and the user is on that site also, I could make legitemate requests despite wether they are detecting a change in sessions or data for that matter. In the end they only lock out the good guys with it.

So detection is really, really tough. Think => CAPTCHA and you know what I mean when I say tough these days.

Instead of detecting it, make sure it cannot happen. A lot of ways to do that:

- design a cross/same domain policy for your domain (Apache, flash)
- jump out of frames/iframes with javascript.
- create unique identifiers based upon IP info
- create secure tokens, (very secure they must be able to withstand bruteforcing)
- create a user profile and store it into a session
- be sure to ask a password on EVERY important change in data, like modifying the password, email etc.

Yeah, it's not easy to reliably detect CSRF, but that doesn't mean you couldn't do some fuzzing and automatic flagging of potential CSRF. I think that this would be most useful against sites using RPC that returns JSON, especially if the fuzzer could analyze the response to see if it's usable JSON.

THere's a good blog post on what responses are vulnerable here: http://jpsykes.com/47/practical-csrf-and-json-security