Don’t Click The WTF Link On Twitter Unless You Do Like Sex With Goats | Hacker News Reader

Don’t Click The WTF Link On Twitter Unless You Do Like Sex With Goats

techcrunch.com

21 pointsjulien14 comments

More discussion here: http://news.ycombinator.com/item?id=1729601

They are using GET requests for status updates - possibly only on new twitter.

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.

No, it's not entirely the fault of GET. The browser does not prevent script from triggering POSTs to third party sites.

Seriously? Seems like a security problem waiting to happen... gotta give this a try now.

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.

Oooh, I see how it's done now. Guess that makes sense, though it's still strange that browsers allow cross-domain form submissions...

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.

They could really start improving their security model by not forcing me to whitelist them in noscript just to read a user page.

Though I haven't seen that error consistently.

seems like it's fixed now : http://twitter.com/twitter/status/25615345589

What's wrong with sex with goats?

Reply on news.ycombinator.com