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.

 

 

 In 2011, Marino and Caterina Urban tested the original Facebook Connect implementation and documented their findings in a “Formalanalysis of Facebook Connect Single Sign-On authentication protocol.” The paper reads “Actually, there is no official description of this protocol; hence, in order to understand it we have analyzed all incoming and outgoing HTTP traffic between the browser, the Facebook login server and an application server during the authentication process…using security research tools including the high level protocol specification language (HLPSL) and the Automated Validation of Internet Service Protocols and Application (AVISPA)….we have found two security flaws, including a masquerade attack [with cookie interception]. In order to fix this problem, we have corrected the protocol by adding a message authentication mechanism which prevents an intruder to reuse cookies. This solution has been formally verified using AVISPA; finally, we have briefly described how this correction can be implemented in JavaScript.”

 

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.“

 

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?

 

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.

 

• REST Uneasy: Do we Need to Worry about OAuth 2.0?
• OAuth 2.0Assurance Issues 
• Mitigating OAuth Security Issues with Good Profiling 
• Ouath 2.0 and RESTful Protocol Security Testing Challenges