Thursday, January 29th, 2009

Twitter’s protected updates privacy problem

Category: Security

<p>This morning I had a fun email (in 60 pixel letters) concerning TweetEffect – a Twitter analysis tool I’ve written (details on my blog). In essence I was being accused of making protected updates of the Twitter user available to the world.

I tried it out and couldn’t reach their updates. I then started wondering what on earth would have given that person the idea that a tool that needs no authentication and uses the API output of the user timeline could breach the security of their protected updates. If I tried to access the timeline of a protected user, the API rightfully asks me to authenticate.

However it then dawned on me: the complaining user was logged into Twitter and thus could see the data without being asked to authenticate. So I was about to dismiss the problem and explained that this is not much more of a security breach as the old trick of showing someone a web page with an iframe pointing to their harddrive content via file://.

However, things are not as easy – as followers of this person that are allowed to see the updates – friends so to say – can also get to this data via the API. So in order to get to someone’s protected updates I could do the following:

  1. Sign into Twitter
  2. Click the followers link of the user and find a trusting person
  3. Send this person a “look at the cute kitten” link that contains some clever code

All this clever code would need to do is to call the user_timeline in JavaScript, populate a hidden field or DOM element, read out its value and post it somewhere else (either via Ajax or an image or whatever else).

This is a problem, especially as disallowing that would break most Twitter clients. I can think of a few solutions: disallow the listing of followers of users with protected updates for non-followers or instead of doing a “protected updates” replace this feature with “trusted friends” groups and an own API.

In any case, it shows again that staying logged in and trying to protect information from going out when using a browser environment is simply not a clever idea.

Related Content:

Posted by Chris Heilmann at 2:13 pm
3 Comments

+++--
3.6 rating from 13 votes

3 Comments »

Comments feed TrackBack URI

Isn’t this the standard XSRF attack?
http://en.wikipedia.org/wiki/Cross-site_request_forgery

I include a post/get variable whose value equals a hash of the user id (or another stored bit of data about the user). Then I check if the submitted variable’s value equals myCheckFunction(user id). If it does, I send the data; if not, there’s a problem. This seems to protect well, since you’d have to know the bit of private info about the user AND the myCheckFunction() in order to send a valid test variable.

But if I do this for the minor sites I build (and I started doing it several years ago), then why isn’t Twitter doing it for their big-ass site?

My conclusion: Twitter is serious unorganized, sloppy, and messed up. No?

Comment by jamienk — January 29, 2009

I don’t think this is a CSRF issue as the previous commenter suggested especially since you are not tricking the user into doing something. However this would be an issue if one is able to make cross domain javascript requests. So I would submit that this is a problem only if you believe there is a problem that would allow cross domain javascript requests to go through. Would certainly want to know that answer, since that would open up the door for a lot more possible attacks.

Comment by dnene — January 30, 2009

I think the key is, don’t stay logged into twitter. use a twitter client, and only log in temporarily (don’t click the “remember me”) if you have to.

Comment by shadedecho — January 30, 2009

Leave a comment

You must be logged in to post a comment.