StalkDaily worm hits Twitter

Found a full post mortem of the latest worm to hit the Social Media scene – StalkDaily. Very interestingly, twitter allowed to add script tags in their profile, and 17-year old Mickeyy Mooney employed a cross-site scripting attack to not just post an update promoting his own site, but also added the same malicious javascript on the profile pages of who-ever visited an infected page. The modus operandi of the attack is described in more detail here.

This of course, made use of the authentication tokens that are present when you are logged into twitter – and while it couldn’t scrape passwords, it did its harm. Twitter is kinda more open than all others, since it reveals pretty much all its functionality through its API – it even gives the users the ability to even update their profiles. This, along with the fact that they allow Javascript inclusion in the profile (extremely surprising! why would they allow this!), makes it easy to do cross-scripting attacks here.

I was wondering what means can be employed to control this — and there are a few strategies that can be used here:

  1. Input Cleanup – Always clean up inputs when you are accepting anything from a foreign agent (user, website, api). This should include cleaning up script tags, cleaning up for SQL injection, etc.
  2. Secure Account Settings – Ensure that before changing account settings, users are at least made to put in their password once again, or it’s on a separate location (https) that prevents the same authentication tokens to be used. Yahoo/Google do that for all important account settings
  3. Sandbox External Code – If you do have to run any custom code that the user sends your way, run it in a sandbox. Rather than giving it access to all your data structures, create a new datstructure, populate it appropriately and let it spit out the results in some predefined format (say, XML). You can parse the results and display it again. Showing users’ code directly can be quite dangerous.
  4. Extra authentication for APIs – Give the API an extra authentication token, say an api key, that prevents the users to access your api’s without it. The challenge here would be distribution of this extra information. This can either be done by asking users to put in an extra api key when they give api access to somebody, or to make the software pass through a API validation step (a la OpenID, or Vista UAC) that only gives out the api key, after correctly informing the user.

Do you have any other tips?

%d bloggers like this: