CSRF and double posting

LOL, I am the guilty one of saying too much Blah Blah Blah.

And WTF? When did Narf use the word 'sychronous'? Your entire tirade is based on a misreading.

Even your link said that if your site is secure against XSS you probably do not need to regenerate tokens on every request. But I would tentatively suggest Breach Attacks and Replay Attacks could be examples. And I highly doubt my sites are entirely safe from XSS attacks anyway. I hope they are, but I have not had pro's bashing away for three days like you have.

And no, "if they can get it once they can get it 100 times" is simply not true. What if I got it by getting you to click on a malicious link? Are you going to click on that link 100 times? No, you are not.

And the A in AJAX stands for 'AND', is that the A you were referring to?

And in the same straw-man manner that you began, only a complete moron would claim the pacific ocean is a lake :-)

Please don't ask me to search for any more examples. For some reason people do not like posting good solid examples of hacking on the web - I wonder why that is?

Finally, in theory if they get your token...

Blah Blah Blah

Paul.

Overview. The standard advice is to use a unique CSRF token that is unique for each request. Why? Because a per-request token is a bit more resilient to certain kinds of implementation errors than a per-session token. This makes per-request tokens arguably the best choice for new web application development. Also, no security auditor is going to hassle you about using a per-request CSRF token.

If you're a web application developer, this is all you need to know, and you can stop reading here.