I attended mainly the presentations within the technical track, but overall enjoyed the presentations throughout the entire conference. The common themes among the presentations were Web 2.0 threats, using security in the cloud, botnet analysis, PCI, and cyber crime responsibilities.
Our talk, "P0wning the Programmable Web," was presented in the technical tracks. Its basic idea is that more Web APIs are being used and created every day, but the barrier to entry has been set very low in order to gain a larger user base. As a result, security has been completely left out or poorly implemented in many of the applications and mashups built on these Web APIs. What's more, in many cases, the core Web API itself is vulnerable.
Websense CTO, Dan Hubbard
Websense Security Labs Researcher, Stephan Chenette
In fact, on the ProgrammableWeb, a site that tracks major Web APIs, there are more than 1300 web APIs, plus more than 3900 registered mashups that use the APIs. An estimated 10-15 new APIs are created each week.
We outlined various threats to Web services, including:
- Man-in-the-middle attacks
- Message alteration
- Message replay attacks
- Identity spoofing
- Denial of Service attacks
- Confidentiality issues
We showed a few real-world examples of each of these threats, but focused mainly on the Twitter API because of its explosive popularity.
New Twitter mashups are popping up every day, quickly gaining hundreds of users. Unfortunately, these mashups focus mainly on rapid development, and not on security. Our research shows that the majority of Twitter mashups that require a user name and password send credentials over HTTP. That means that a sniffer installed on the network would be able to collect the user names and passwords. Any Web site development team should know that sensitive credentials should always be sent over HTTPS, rather than HTTP. A signed HTTPS certificate can be purchased for under $10, so it's more a matter of security education and prioritization in the development process than cost.
We also outlined the fact that many people who use Twitter mashups think that their user name and password are going directly to Twitter, which is false in most cases. When you log into a Twitter mashup, your user name and password are sent from your browser to the mashup, and then to Twitter. As a user, you should always question the legitimacy of any site that requires you to sign in with a sensitive and shared user name and password. Even if it is a trustworthy source, the more sites that you send your direct credentials to, the more chances there are for those credentials to be compromised.
So just what can an attacker do with a Twitter username and password?
Here are a few examples:
- Most users use the same password everywhere. So, if an attacker captured a Twitter user name and password, the same credentials will likely give access to that user's Facebook and Gmail/Yahoo/Live Mail accounts, and potentially even their corporate email accounts.
- For users with multiple followers, sending a tweet from their account allows attackers to spread disinformation or, worse, spread malicious links. Due to the nature of transitive trust within Twitter and most social networks, users are more likely to click on a link from someone they are following on Twitter than from a random email. Plus, Twitter obfuscates any URLs that are sent using the URL shortening service tinyurl.com. That makes it even more difficult for a user receiving a tweet with a URL to determine the true origin.
In researching content for our talk, we analyzed multiple Twitter mashups, applications, and gadgets. We found that many Twitter mashups that request a user name and password, and then authenticate users via their Twitter credentials, don't then protect their session and are vulnerable to Cross-Site Request Forgery (CSRF). This could allow attackers who fool an authenticated user into visiting a site under their control to send tweets on their behalf.
We chose Twitter not only because of its explosive growth, but also because the Web applications built on top of it represent some of the worst applications from a security perspective. Because Twitter allows communication over HTTP and authentication via Basic HTTP Authentication for a low barrier to entry, and HTTPS as well as OAuth for a higher barrier to entry, we found that most applications were still all using HTTP and Basic HTTP Authentication. I recently was told that Twitter might deprecate the use of Basic HTTP Authentication. This would set a good example for the applications that want to interface with Twitter, prompting them to take security more seriously.
Our presentation also showed examples of the dangers in Web APIs that use HTTP, given their vulnerability to message alteration attacks. Many mashups use weather and stock Web services. We demonstrated the mayhem that could be caused by sitting at a central point between these services and altering weather, stock, or real-estate pricing data.
Web service redirection attack
Web service man-in-middle message alteration attack
So far, attacks against Web APIs are rare. APIs that provide a low barrier, however, such as HTTP Basic Authentication, or APIs that only allow communication over HTTP, promote bad security practices. Many mashups that use these Web APIs are mostly concerned with rapid development, and have shown zero regard for security. It's nothing new that usability and flexibility win over security, but typically security gets at least some investment. Twitter's API has gone through a great number of changes, and has quickly learned from their initial security mistakes. Hopefully other Web APIs will follow Twitter's lead as they begin to take security more seriously.
Security Researcher: Stephan Chenette (thanks to Chris Duggan, Websense sales in Sydney, for the photos)