CSRF Flaws Found On Major Websites, Including a Bank
An anonymous reader sends a link to DarkReading on the recent announcement by Princeton researchers of four major Web sites on which they found exploitable cross-site request forgery vulnerabilities. The sites are the NYTimes, YouTube, Metafilter, and INGDirect. All but the NYTimes site have patched the hole. "... four major Websites susceptible to the silent-but-deadly cross-site request forgery attack — including one on INGDirect.com's site that would let an attacker transfer money out of a victim's bank account ... Bill Zeller, a PhD candidate at Princeton, says the CSRF bug that he and fellow researcher Edward Felton found on INGDirect.com represents ... 'the first example of a CSRF attack that allows money to be transferred out of a bank account that [we're] aware of.' ... CSRF is little understood in the Web development community, and it is therefore a very common vulnerability on Websites. 'It's basically wherever you look,' says [a security researcher]." Here are Zeller's Freedom to Tinker post and the research paper (PDF).
GET requests in practice change stuff on the server. Making everything POSTs is just annoying - you get all those "click OK to resubmit form" messages and you don't even know what form it is.
What they should do is sign urls (at least for significant stuff), so you can't just iframe a static url, you have to guess the correct url - which should change at least on a per session basis.
e.g. instead of http://slashdot.org/my/logout it should be something like http://slashdot.org/my/logout?salt=123955813&sig=01af85b572e956347a56
Where sig=sha1(concat(user session,salt,site secret,site time in hours))
If sig doesn't match, you try to see if sig matches the time that rolled over:
sig=sha1(concat(session,salt,site secret,site time in hours-1))
user session = random string+primary key.
For stuff that should not be resubmitted, you use another param to enforce that.