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.
The Problem
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
 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.
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.
Related Posts

2 Responses to OAuth 2.0 and RESTful Protocol Security Testing Challenges

  • hi,when i change the protocol code in avispa tool,I got only errors,please tell me how can i remove these errors?

  • Hi Dan,

    Its good to see your note. I am in strong agreement with your views that we need a set of tests that distinguish between a weak or broken OAuth implementation vs. an adequate implementation. But the challenge is that we dont have a forum or a community where these issues can be discussed. So how can we characterize “weak” vs “adequate”? How can we raise market awareness in this area?

    The major social/cloud/search giants view their security models are essentially proprietary (“no worries, we have the best security research team in the world”) so thats another area of complexity. Would it even be possible to engage with them in this arena?

    If you were interested in a workshop session at the next IIW, we would be interested in supporting that activity. Maybe we can figure out some concrete next steps at that time as well.

    Prateek period Mishra at bigSoftwareVendor dot com

Subscribe to Blog Notifications...  HERE