Anyone who considers themselves an avid twitter user is at least somewhat familiar with the twitter API. The twitter API, which has been the subject of a large portion of twitters funding provides methods to complete almost any task that can be completed on twitter directly.

I recently began developing a web-based twitter client geared towards advertisement, when I fell across several potential flaws in the way they handle their authorization. I was able to hijack my friends twitter account and updated his status, change his background picture or even change his password, all because he trusted me. This was due to their authentication scheme.

API based authorization (OAuth) is a token based authentication scheme that works in the following way:

1. Application Developer applies for access to the OAuth. Once an application is granted (Almost immediately) a consumer key will be generated.
2. Users will then be able to connect their twitter account to this application. Once connected, they will have a token and a secret key which are used to verify their identity.
3. Once a user executes a query, the query will notify the API by saying “Hello this is the application with consumer key *CONSUMER KEY*. I want to execute the “set status” query with parameters “This twitter api is cool!” for user with token *token* and secret *secret*.
4. Assuming the token, secret and consumer key are all valid, the query will be executed.

The problem with this, is that twitter themselves tell us to store the token and secret in plaintext, probably in some sort of SQL database for easy fetching. So lets step back and think about this….

Typically we use hashes in practice to prevent our passwords from being stored in plaintext. But, doesn’t it seem like these tokens are a password? Well, we can think of these tokens as part of a password. The other part of a password is the consumer key, which is probably tucked away in a global configuration file or database somewhere.

The problem with this methodology is that the twitter developers are assuming the way an application handles their consumer key will be intelligent and secure. This is not always the case. Not to mention, what about disgruntled developers with access to both the user tokens and the consumer key?

I’m not writing this post hoping to see some miraculous changes with twitters security. In fact, months before I’m even writing this post I sent them an email explaining my research. They never responded. Two days later I read a job posting… It was twitter looking for security developers for their API. Coincidence?

I simply want people to know and understand the risk of using twitter applications. You’re not cool if you have 30 twitter applications. As you should now be aware, you’re just a walking vulnerability.

Note: Many websites with fully fledged API’s are also subject to these problems, including, I believe, Facebook. You’ve probably all seen the lovely Facebook viruses that once you click on, it begins sending notifications to your friends. Well, this is an example of abusing the privileges of an API and lack of user knowledge…