kthxbai, I just deleted 99 of your twitter friends

By Matt Topper • January 7th, 2009 • View Comments

No really, I just did it.  99 of your closest friends, if you have that many, are gone.  Go ahead and check…I can wait.

Well, not really, if you are logged in to your twitter account through your browser right now I could have.  Ajaxian had an interesting article on everyone’s favorite microblogging site today.  One of the biggest features of the site is the REST based API it provides.  Whiles its dead simple to use, its also one of its biggest risks.

I’ve been working on a site that looks through all your friends last tweets and sorts them by the timestamp of their last update.  Not very powerful, but a quick, nice to have, when you’re looking to clean up the ever growing list of virtual friends.  If you have an active twitter session in your browser, I give you the option to unfollow them.  All of this is done with javascript right in your browser, and the only time you hit my server is to load the initial page.

Now if I was malicious I could have just grabbed your first 100 friends, parsed the returned xml, and delete the first 99 of them.  I could do more, except twitter limits you to 100 requests an hour.  Pretty scary, huh? Do you read every line of javascript for every site you visit? How about doing more, like posting a status for you (…is visiting theappslab.com), making you my friend, update your picture with my corporate logo/ad.  What gets scary is that I can also update any attribute on your profile. So I could update your email address to one of my liking and send a request to reset your password sending your new password to my account. (This could be fixed with an extra challenge question)

OK, now that I’ve scared you now here’s the fix…well, to be honest, there really isn’t one.   Some have proposed OAuth as the answer.  To me, its no different.  I could trust one of the many twitter apps today and tomorrow the owner could get a wild hair and decide to start making money off of my trust.  Twitter could add something like OAAM and OES, Oracle’s risk assessment engine and entitlements server to help with establishing application request patterns and ask the user to provide additional authentication factors when they trust a new site or the site starts behaving out of its norm. 

Really the best thing you can do is install something like NoScript in Firefox and make sure you know what site’s you’re visiting, and log out of twitter when you’re done.  Personally, I can live with the fact that someone might tweet for me or make changes to my account.  Twitter should rethink the ability to update profile attributes through the API.  I don’t think anyone would complain in return for the added security.

This is just the tip of the iceberg of things you can do without users knowing with XMLHttpRequest.  Figuring out what sites people visiting a site have already visited.  How scary would it be when your salesman calls and says he heard you visited the competitors product page recently and wanted to talk about how their product differs.  Maybe I’m missing something, but I don’t see any easy way to solve the problem.

It’s a wild wild web2.0 world out there, be safe my friends. ;)


Possibly Related Posts

  • The twitter and OAuth discussions heat up:
    http://simonwillison.net/2009/Jan/2/adactio/
    Alex Payne is the chief architect for Twitter.
  • Yeah, I know the name. This is good. Twitter isn't alone here; FB probably has a worse predicament on their hands as FB Connect spreads. I'd wager that FB has the lowest level of technical proficiency among its users, making it a prime target for phishing.

    It's going to be interesting to see how all this plays out as the shiny, happy API days fade.
  • Twitter's had a bad week, but let's face facts. Facebook is in a worse predicament with FB Connect. Neither system has a very solid authentication system, but now that FB Connect is spreading your creds all over the 'tubes, I think it's time to step up the difficulty factor and make it tougher to break into an account.

    We all hate remembering strong passwords, but that's a start, no?
  • It's really getting interesting in the online authentication space. The Commission for Cybersecurity just released an interesting "Recommendations for the 44th Presidency" found here: http://www.csis.org/component/option,com_csis_p...

    Some of the things they call for is a national online authentication system either public or private and companies who don't comply will have to assume a higher level of risk (i.e. be charged more for transactions) online.

    One of the best demos I've seen for OpenID had a one time use SMS message tied to authenticating a new account. The use case was that you could use your username and password over and over again for sites you've authenticated to in the past, but as soon as you try and authenticate to a new site they sent a text message to your phone with a unique password to make sure it was you. They also profiled where you logged in from i.e. an OSX machine through Firefox in Portland between 7am and 12pm. When you fell outside your normal range through a configurable set of factors it would send you a one time use password again to authenticate that new machine / profile to your account.

    They also gave you other less secure means if you didn't have a cell, or it was dead that you could use to override the system. Really cool stuff.

    (OK, enough IdM geekery)
  • I remember we talked about that profiling piece, which would be acceptable to secure my creds. It's creepy, but if I trust an OpenID provider, I want them to keep my crap secure.

    Trust is the issue though. The big networks (MySpace, FB), and the ones with high profiles (LinkedIn, Twitter) will see this problem get really bad, really fast, if they don't act quickly.

    Google is another ID vendor that needs to get its act together quickly; their OpenID support isn't moving fast enough.

    This is one area where enterprise pwns consumer web.
  • Looks to me like they are describing using a GET request to the API to load some JSON into the browser. I don't think this will work for POST requests, so the friend deletion probably won't work. I assume they don't use XMLHttpRequest because the cross-site request will fail, as it should.

    I don't think this is really a huge deal. It probably does raise a valid concern about privacy using HTTP basic authentication on an API in general, since one could use this to access the status messages of a user with a non-public timeline. If I understand OAuth (and I've had a bad week on that front), it would help with this problem because the javascript on the non-Twitter site wouldn't have access to the proper token value to access the API. However, Twitter would have to stop allowing Basic authentication for the API entirely to avoid what we see in this example and I don't see that happening in the near future.
  • I can do a post on a JSON request through jQuery pretty easily. You're right that I can't do it with XMLHTTPRequest and missed that point in my slumber last night.

    I agree that OAuth helps the problem because it'll prompt me to agree to authenticate the site to use the different pieces of the API, but the average user is going to check all the boxes and not think. If I decide to be a malicious developer I already have the authorization to modify your account privs.

    There has been some big discussions on the Twitter developer group about adding OAuth which they don't think will really solve the problems. As with anything security related its always a cat and mouse game and the standards are ever evolving. The next step in the process is going to be risk and pattern based profiling presenting people with secondary forms of authentication when they fall out of the box.
blog comments powered by Disqus