Slashdot Mirror
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).
The problem isn't really that flaws were found, but that NYTimes refused to change them. If you look in 2600, you will see that even when hackers have posted step-by-step guides to 0wning S3rv3rs, the businesses just claim that it is supposed to be like that, or never getting around to fixing them.
Taxation is legalized theft, no more, no less.
"If I got an E-mail that said that my servers could be owned by such and such exploit by doing this and this, I would immediately take action."
Except another recent E-mail says that your job just has been outsourced and you have five minutes to clean out your desk. Happy fixing.
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
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.
libertarian: (n) socially liberal, financially conservative; neither left, nor right.
Repeat after me boys and girls "GET requests shouldn't change anything on the server".
Me lost me cookie at the disco.
There are ways to safe GET requests. Unnecessarily avoiding the use of GET results in web sites that are not bookmarkable and where users can't provide links to their friends. So "hey check this out" and pasting a link becomes "hey check this out go to the main page, click here, then there, then on the other thing, then scroll down a bit to find the item in the list and then its halfway down that page".
I hate printers.
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).
That unfortunately doesn't defend against GET requests. This means that if your script allows anything vulnerable to be requested via GET, then the 'image' attack vector is not protected. This includes when GET requests are supposed to be made via xmlhttprequest..
It does defend against a form in a hidden iframe, however, you have to actually *use* it for your application to be protected.
Regarding browsers fixing the problem, you are correct. It's very very unlikely that the developers of browsers will implement a message that says something like 'I am about to load an image with full url .... you you accept'.
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.
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.
... CSRF exploits are not the reason that GET requests shouldn't change anything on the server. Implement all of your secret one time link programs, but you'll be disappointed when someone using an 'internet accelerator' that pre-fetches pages comes by and illustrates the reason that GET ought to be separate from POST...
Changing GET to POST does not, in any way shape or form, protect you from a CSRF attack.
If you think it does and have been doing this on your own site or projects, you have some more research and work to do.
All changing GET to POST does is make it a tiny bit harder for Joe n00b hacker. But anyone with half a clue knows how to use JS to do CSRF using POST requests.