csrf is suble
@Anomalous Cowherd
Nothing technical about it. It can be coded either way. The server has all the same information. With broadband, conventional page reloading is not the tedium it once was with dial-up. I'm in agreement about the slick interface for an app feel. There are some very good ones out there. For the discussion of the article, however, the former does not demand JS, the latter cannot function without it. And JS opens up the prospect of CSRF...
@James Butler
It has nothing to do with phishing nor input validation. It is impersonation and forged requests. My website can be perfect but can still be the target of attacks from another site with XSS holes. But (and it's a big but) the requests are from my customers. I cannot distinguish real requests from forged ones unless I make user access such a pain that nobody wants to visit. With CSRF you'll realise there is almost no easy defence against it /and/ keep all your users. Hence the doom and gloom of the article.
To recap, it happens like this. We have four agents in this scenario.
- Bob, at home, using his browser.
- SiteA, perfect, with no XSS holes or anything. Perhaps a bank.
- Sid the bad guy who want to rip off Bob's account at SiteA.
- SiteB that hosts the malware created by Sid. A forum or blog perhaps. Could be a site owned or 0wn3d by Sid and/or has exploitable XSS holes. The malware is a combination of html (iframes etc) and javascript as needed to execute the CSRF.
(1) Sid puts malware on SiteB.
(2) Bob visits SiteA and logs into his account. SiteA sends Bob a cookie (a random token or nonce) so that further requests from his browser do not require him to re-enter his password for every requested page (a convenience feature).
(3) While still browsing SiteA, Bob opens up a new tab and surfs into SiteB.
(4) His browser downloads a page from SiteB along with Sid's malware. Remember, the browser will not allow SiteB to access SiteA's cookies. Not now. Not ever (bugs in IE excepted). His browser displays the page. The html part of the malware open a 1x1 pixel iframe to http://SiteA/... Bob can't see it as it's so tiny and tucked away. The javascript part of the malware has access to the cookie for SiteA and any request from within the iframe to SiteA will include this cookie (same-domain rules). The malware builds a request and sends it to SiteA, say a form POST. (GET attacks that do damage should be a thing of the past now.)
(5) SiteA receives this request. It is coming from Bob's browser at his IP address along with the Bob's cookie for SiteA. The server checks the cookie and sees that it's a valid cookie for Bob's current session and executes the request. Fill in the blanks of what the request could be. SiteA logs the request, IP address etc.
(6) Much later Bob complains to SiteA that his bank account is now empty. SiteA examine the logs and sees that it was Bob who made the request and tells him tough bananas.
Hopefully it will be clear now why the various solutions in the article have been given. It's the result of using iframes, xhr and javascript to sidestep same-domain rules set up to protect cookies (themselves used to overcome the limitations of stateless pages).
While it is up to SiteA to do all they can to thwart this (they don't want customers being ripped off) you need to be aware of what might be going on while browsing. If you browse one site at a time, logout and delete cookies before going somewhere else then leaving JS on is just fine. If you like to have many tabs open (I do) then you need to make the necessary security adjustments. You could keep one browser strictly for online banking.
A long post but I hope it clears up why this is important. It's not that I hate JS (or Web 2.0), it's that it's too dangerous to just give it free reign for no really good reason.
Biting the hand that feeds IT
