OAuth 2.0 and RESTful Protocol Security Testing Challenges
OAuth 2.0 has its advantages. It’s been written to accommodate multiple client environments from the real world. Whether you have a mobile application, just a browser or want to use a web service there’s an OAuth flow for you. But to achieve broad applicability, OAuth makes some security compromises that I’ve discussed already in my OAuth 2.0Assurance Issues post. And in my Mitigating OAuth Security Issues with Good ProfilingI describe ways to reduce the attack surface and minimize risk within the OAuth framework.
Better profiles, however, are only the starting point. Without a robust security implementation, the best intentions go out the window. You’d think that because OAuth is a widely adopted standard, customers would enjoy the benefits of lots of peer review and tools to test the protocol for security. But that’s not the case. While peer review of the protocol has been done at a general level, there’s no easy way for customers to verify a particular implementation has been built and operated in a secure manner. More testing and auditing of all implementations is needed in the short term; more tools and transparency from the industry will be required in the long term.
Professor Marino Miculan, a Professor at the University of Udine in Italy who has led formal security testing research into Facebook Connect and OAuth, uses this analogy: “OAuth 2 is like a specification for a car that says it should have four wheels, up to 5 seats, a steering wheel, an engine and a brake system. A truck does not fall in this specification. But a vehicle satisfying the specification is not necessarily “correct”: maybe the brake system is broken, or the engine is undersized and explodes after ten miles, or the tires are flat.”
As noted in my previous post, OAuth 2.0 isn’t a protocol with strict rules, it’s only an API framework. How the exchanges occur between the user’s browser, the client application, the authorization server and the resource server are minimally specified with critical security functions such as authentication of the user and authorization scopes left out of scope.
Most implementations also provide minimal guidelines to developers on how to invoke an authorization server and no detailed documentation of its protocols. They don’t describe what the authorization server will do if the app client misses a packet and has to submit the same authorization code again on a retry. They usually don’t say what happens if the user changes his or her mind about granting authorization, has an access token time out in the middle of a stateful interaction or how to deal with any one of many other potential edge cases.
Under-specification of OAuth 2.0 may make it easier for client developers to get an initial version of a client app running, but its a nightmare for anyone trying to do black box security testing or quality control from the outside. In a nutshell, the challenge is that the statelessness of OAuth which make it and other RESTful specifications seem simpler make them almost as difficult to test for security purposes as proprietary protocols.
What Does that Mean for Assurance?
For many years, the security community has deprecated proprietary encryption algorithms because they are likely to be complex and contain errors but unlikely to get peer review or impossible to peer review. I asked Marino if he thought proprietary protocols deserve the same disdain. Marino commented: “Defining a correct security protocol is VERY difficult; so much so that the issue has attracted the interest of hundreds of researchers worldwide for 20+ years, and now we have pretty good theories and tools for protocol verification. Amazingly, most protocols used in the industry are implemented and deployed without any formal verification!” Marino and I agreed that under-specified protocols based on RESTful specifications are probably about “half as difficult” to verify as proprietary protocols.
Formal Security Analysis of Facebook
But ominously: “In our opinion, the message authentication mechanism we have presented in this paper, can be applied in other situations where cookies are used to convey session credentials, and as such masquerade attacks are possible. On the other hand, it is not easy to distinguish a replay attack from a iteration of the same request by the legitimate user (like a page reload). One can apply known authentication mechanisms, e.g. based on sequence counters, to avoid this vulnerability.“
Problems May Never have Been Corrected
The problems that Marino and Caterina found may never have been corrected because Facebook has since moved to a new OAuth 2.0-based Facebook Login implementation. This year, Marino will test again: “Right now a student of mine is going to analyze Facebook Login, the component implementing OAuth 2, much in the same way Caterina did for Facebook Connect a few years ago. Our aim is to get a formal, abstract version of their implementation, and check whether it is secure or not. It’s going to be a quite time consuming job (since there is no official documentation of how this protocol works, we have to reverse engineer it), but we hope it will be worthwhile.”
A few years ago, Mark Zuckerberg from Facebook boasted that the company embraced “The Hacker Way” of rapid web development. For all we know, with Facebook’s new implementation, which is the most widely used social login system in the world, the old problems have resurfaced in a new form. Most relying parties and users don’t have free student labor like Marino to test and retest every time Facebook (or any other cloud service provider with OAuth) feels like making a change and not telling anyone about it. So what can be done?
A Way Forward
Few want to abandon the benefits of RESTful protocols in general or OAuth in particular. But in the future, spec authors should be more reluctant to include insecure flows in the first place, and should also include testing procedures and checklists to help customers determine whether implementations actually follow security recommendations. Security protocols should include security recommendations at least as detailed as OAuth’s RFC 6819, and those recommendations might also provide guidance for documentation of how an implementation turns the framework into a protocol and how to test the implementation.
Then, for the really important specifications like OAuth, its down to the industry to develop certification programs and testing tools. The HLPSLand AVISPA tools seem appropriate for advanced security research (which the likes of Facebook can certainly afford) but are a bit much for the typical customer evaluation team trying to get a sense for the risks of using a particular OAuth authorization server. A simpler solution might be take a tool like the Google OAuth Playground and endow it with some penetration testing capabilities. And perhaps to get some kind of OAuth 2.0 certification going so that everyone and his brother doesn’t have to become a pen tester. OAuth 2.0 is, after all, very broadly used.