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).

Comments

Hanlon's Razor

[A non-mouse Coward]

I think Hanlon's Razor is in play here.

Never attribute to malice that which can be adequately explained by stupidity.

Don't assume these people don't care or don't want to fix it. CSRF is in the class of "WebAppSec" (what the kids call it these days) that is not "syntactic" in nature; meaning that you cannot just say "here, use this API and you're safe". It's a "semantic" problem; the developer has to both understand "how" sensitive transactions can be abused AND "how" these transactions can be fixed (like with a nonce).
It's probably just that they don't know how to do it, at least not manageably on an average budget.

Re:Computer systems need security audits.

[zobier]

Repeat after me boys and girls "GET requests shouldn't change anything on the server".

Stopping CSRF attacks

[this great guy]

[A pseudorandom token] doesn't really stop it. All it does is reduce the problem to a cryptographic attack -- which is subject to brute force.

Saying that is like saying "cryptography doesn't really provide privacy, because it is subject to brute force". Of course pseudorandom tokens stop CSRF attack (when implemented properly).

Re:Computer systems need security audits.

[spec8472]

While GET does in practice change stuff on the server, the idea is that it should be repeatable without adverse effect.

So, calling GET on a document might increase a hit counter, or update some other information - having me repeatedly call that function again should be safe.

However using GET for Updating Account Details, or Moving money (just some purely /random/ examples) is just plain bad design.

The example of signing GET requests is useful in some situations, but *mostly* not necessary if the design is right.