Underscoring the severity of of an exotic form of website bug, security researchers from Princeton University have cataloged four cross-site request forgeries in some of the world's most popular sites. The most serious vulnerability by far was in the website of global financial services company ING Direct. The flaw could have …
Why Don't They...
...just pull the plug on this whole intertubes abortion? Nowhere is safe, we are all going to die and, yes indeed, the sky is falling. If US Congress had approved a web-bubble-bailout back in '99 we could have avoided this whole mess and lived happily ever after.
Paris, cuz when they said NoScript, she thought they said NoSkirt=FTW!
Please read the article...
before commencing the usual my OS / browser is best...
false security based on dim presumption
If ING really sat down in a quiet corner for thirteen milliseconds they should surely understand just how poor their implementation must be: "because it was requested by the browser, it was invoked by the user"
A security philosophy that seems to be based on the notion that all client software is flawless!
This is a good ole HTML attack, noscript won't save your little hide here.
ING have created a bit of a blunder, cookies are always sent between the browser and the domain for each request where the conditions of the cookie apply.
So, in effect you are logged into a system until that cookie expires.
There are some workarounds, but I don't really feel like giving away the secrets for nothing, but I will mention the fundamental problem: business doesn't want to pay the correct amount of money to do it right.
simple solution ?
wouldn´t just denying execution of local dynamic scripts from external referers be enough to protect the sites ?
NYT A Problem?
The ING flaw is an issue certainly, but the NYT can rest easy (and obviously have) as no one registers for their site legitimately - thank God for bugmenot! Clearly the NYT dudes know this perfectly well and so have been able to take a rather relaxed attitude to the problem.
Re: simple solution?
The referrer header can be faked. Whilst many attack vectors inside the browser wouldn't allow it to be done, it is not impossible to do once you consider plugins like Flash. The resolutions suggested in the paper work fine. In fact, sending the psuedo-random value as a cookie isn't necessary - you can just store it in your session state on the server and only send it in the forms, then you don't need to worry about any cookie sniffing vulnerabilities discovering it either.
I notice the paper entirely fails to mention Microsoft .Net in its list of frameworks. This is one of those rare occasions when the Microsoft platform is actually more secure - it provides CSRF protection of of the box with the viewstate mechanism.
Re: simple solution?
True. I posted without reading the complete PDF (my bad), and was thinking about embedded images or similar. The referer would not be easily faked in those cases, and it is yet another layer of protection that can be easily deployed without rewriting entire websites.
- Product Round-up Smartwatch face off: Pebble, MetaWatch and new hi-tech timepieces
- Geek's Guide to Britain The bunker at the end of the world - in Essex
- FLABBER-JASTED: It's 'jif', NOT '.gif', says man who should know
- If you've bought DRM'd film files from Acetrax, here's the bad news
- VIDEO Herschel Space Observatory spots galaxies merging