The team at David Naylor Search Monitoring today uncovered what is potentially a truly massive security hole in the Twitter API. They describe it simply and succinctly in their blog post on the topic:
So as I’m sure everyone heard about the other day, Twitter recently added rel=nofollow to links produced by their API (e.g. the client you used to send the tweet). I was playing around with some settings today and noticed something interesting.
If you change the link in the application settings, it affects all of the historical tweets generated by the application. So it’s pretty quick and easy to experiment with different URLs and see what happens.
Oh, no, wait. It works. A clean, followed link out of Twitter again. Isn’t that nice?
Actually, if they were that stupid… what’s to say I couldn’t drop some other content in there? Yup, that works too.Take a look for yourself. Do I hear anyone saying “cross-site scripting”?
Any Twitter application developers out there I wonder? Maybe I could be more subtle about it, just drop a script in there that goes to their application settings page and changes their URL to drop some malware links around the place.
As it turns out, the account that demonstrates the vulnerability has been terminated by Twitter, but the security hole, as of yet, has not been plugged.
If the language above is a bit too much developer-speak to understand, here is the lay version: the API that is used by Twitter to set meta-data on Tweets, like what an application is called, is vulnerable to being re-written by virtually anyone using the method he describes.
Code, potentially malicious code, is able to be inserted in that field. If an unsuspecting user were to click on the page where the Tweet lives on Twitter’s server, it has the potential of running the unauthorized code on the users machine, which has all sorts of devilish possibilities, as they described in their post.
The David Naylor team is promising a video tomorrow that demonstrates the vulnerability.