You may have heard about the recent OAuth security hole that left Twitter vulnerable to cross-site scripting attacks. The first response someone looking at the details of the attack and its high media coverage might be to throw up their hands and give up on OAuth altogether.
This is to the wrong way to look at these recent events. The OAuth specification is a great one. Like all great standards, it is easy to read and simple to implement. For example, one of the developers here at the Institute for Cyber Security wrote a robust Java implementation of it in three days from his first look at the specification; there just are not many specs that do something so useful but can be put into practice so easily.
What needs to be understood is that this is exactly how the crypto protocols process works. Any standard worth its salt takes years and years to mature. As an example, SSL was first developed in 1993; people far smarter than I are still improving it a decade and a half later! Yet no one would argue that SSL is not a secure or well-thought-out spec. The fact that this attack even detected shows OAuth is under scrutiny and is gaining traction, which is really a good thing for OAuth. Would you rather use a spec which smart people are trying to break, or a no name spec that only the "wrong smart people" know how to break.
In the end, we do not know what OAuth's fix to this vulnerability will be, but if developers want a quick solution, they may want to consider using the MashSSL protocol that ICS developed with SafeMashups. SafeMashups is our most mature company in incubation, and integrates with OAuth. as well as other popular Web 2.0 standards.
MashSSL a multi-party version of SSL running in the application layer, and from an OAuth-centric standpoint, MashSSL first runs between the Consumer and the Service Provider through the user's browser (using standard SSL certificates for each server; no certificate on the browser is needed or expected). We then set the OAuth credential type to "PLAINTEXT", but all the OAuth messages are encrypted with the SSL "master secret" (the session key the two parties share at end of any SSL session). Except for the first go-round which involves public key operations, all subsequent sessions use the SSL abbreviated handshake, which is very efficient and only uses symmetric key crypto. The session fixation attack will not work as the Service Provider won't operate with a site with which it cannot establish or share an SSL session. So when the "good" URL is moved to "bad" site (as in this OAuth vulnerability), the attack is detected and stopped.
More info on how OAuth can interoperate with MashSSL can be found here. Additionally, a video on MashSSL/OAuth interoperation can be found on the SafeMashups YouTube channel. and in the the education center on the SafeMashups site.
Disclaimers:
- MashSSL is moving towards becoming an open standard, but is not there yet (and I suppose that there is an infinitely small but non-zero probability that it may not, although the more people that cloamor for it, the sooner that will occur).
- The software though is available under a perpetual royalty free license so you do not have to pay anything to use it.
- At the moment it only works with certs from VeriSign (and our own free CA which we absolutely do NOT recommend you use except for testing).
Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu
Image is a graph of SSL's growth over time. Just as SSL was improved via a battery of tests over time, new cryptographic protocols like OAuth can certainly persevere to become ubiquitous standards.
