Which is quite astounding. These aren't novice programmers fresh from a comp-sci course and in to the big bad world. Making this kind of mistake (which is a mistake on not one, but many grounds) is extraordinary. It's as if the ideas of idempotence, REST, basic security, treating external input as hostile, etc. have never even been mentioned between them.
I'm not foolish enough to imagine that this is anything other than a blip for them - their first mover momentum and market dominance is invincible for the time being, but they don't deserve it if they keep putting users at risk as casually as they seem to be. So far, we've seen nothing too nasty (though this could be embarrassing I suppose), but it's a bad sign looking ahead.
I agree, I can't quite believe they put something so poor security wise out. I'm not convinced when they say it's fixed that's it's really fixed yet either - in that someone could just create another page with the problem.
The fact that they're using a GET is not the problem (though it is slightly bad). The malicious javascript would have to be only slightly more complex if it was a POST. The issue is that there is no security token required when making the request to do the status update.
No, it's entirely the fault of GET. They're opening an iframe on their page with a source your post URL. If it were POST-only, they'd be blocked by Javascript being unable to communicate across domains.
Seriously. Search the web for documents on "cross site request forgery". Most of the documents discuss the POST issue. Some documents don't mention GET because GET should not be used when the request has side effects.
If browsers didn't support cross-site form submission, many common "web gadgets" wouldn't work: there would be no site-customized Google search boxes, and none of those third-party "share this page" buttons. Sure, the merit of those things is itself debatable—but they exist, and web developers will increasingly rely on them (e.g. the Facebook Like button.)
Also, sure, every webserver could proxy the requests—but then you have to guarantee that you haven't created an open proxy, which is a much worse hole than a simple CSRF—and then you have to do some more server-side configuration every time you want to enable your views to touch a new third-party API—which excludes a lot of hosted sites, like blogs, from using any API that their server admin hasn't considered.
16 comments
[ 2.8 ms ] story [ 52.2 ms ] threadI'm not foolish enough to imagine that this is anything other than a blip for them - their first mover momentum and market dominance is invincible for the time being, but they don't deserve it if they keep putting users at risk as casually as they seem to be. So far, we've seen nothing too nasty (though this could be embarrassing I suppose), but it's a bad sign looking ahead.
Also, sure, every webserver could proxy the requests—but then you have to guarantee that you haven't created an open proxy, which is a much worse hole than a simple CSRF—and then you have to do some more server-side configuration every time you want to enable your views to touch a new third-party API—which excludes a lot of hosted sites, like blogs, from using any API that their server admin hasn't considered.
Though I haven't seen that error consistently.