Low Hanging Threats to OAuth Security

OAuth is quickly becoming the de facto standard for managing authorization for resource sharing among web API producers such as Twitter. It facilitates the development of third party applications that require access to protected user resources to extend the core functionality offered by the API provider. For example, using the OAuth support made available by the Twitter web API, the Twitpic service can upload pictures and videos to the user’s Twitter account without requiring them to share their Twitter credentials with the Twitpic client application. Although the protocol is quickly becoming popular, a flawed implementation can compromise the protected user resources on the server. This post provides a quick refresher on the OAuth process flow and then goes over vulnerabilities discovered in the wild, which incidentally can be fixed rather easily. Figure 1 shows the OAuth process flow: 





As depicted in Figure 1 TwitPic is ‘the client’ which allows users to post photos to their account on Twitter, which is ‘the server’. The user initiates the process with TwitPic. TwitPic generates a unique token to identify the user and redirects him to Twitter for authorization. The unique identity token is passed to Twitter in the redirect link. The user authenticates to Twitter using his Twitter credentials. Twitter verifies the credentials and associates the identity token passed in the redirect link with the authenticating user and sends a confirmation message to TwitPic. Subsequently, Twitpic finishes the association process to give the user access to TwitPic’s feature to post pics on the user’s Twitter account. From then on, whenever the user sends a photo to TwitPic, TwitPic sends it to Twitter along with user’s identity token. Twitter can identify which account the pic should be posted to by matching the token.


 The identity token is very important because it represents (and replaces) the actual user credentials used to authenticate to the server. Indeed, OAuth removes a big hurdle for websites with a need to share their protected user data without compromising user credentials. However, OAuth is loosely defined and this leaves room for implementation flaws that may compromise the user’s identity and access to protected resources.


On the top of the list of potential flaws is the absence of transport layer security. OAuth version 1.0 does not mandate the use of SSL/TLS. As we all know, the absence of an SSL connection between the client and the server exposes the tokens and other secrets in plain text over HTTP and can be seen by anyone eavesdropping on the traffic. This allows an eavesdropper to obtain sufficient information to craft requests to the server, imitating the client acting on the user’s behalf.


The second issue where the OAuth protocol fails to provide adequate protection is session fixation[1].  As shown above, OAuth allows web API producers and consumers to tie a user’s identity to a token. The possession of a valid token, associated with an authenticated user, is all an attacker needs to gain access to the user’s protected resources. To achieve this, the attacker initiates the authentication process with the client to access resources from the server. He intercepts the redirect request that the client generates (Step 2 in Figure 1). The request contains the token that the client intends to use to identify the attacker when communicating with the server. Instead of the attacker directly authenticating to the server, the attacker uses social engineering to trick the victim user into following the redirect URL and authenticating to the server. The victim provides the server their credentials and the attacker’s token is tied to the victims account. The attacker then finishes the process with the client (Step 6 in Figure 1). Hence, the attacker was able to fixate a token to the victim user’s identity against the server.


Due to this session fixation flaw, both the client and the server fail to ensure that the same user is initiating and completing the authentication process (Steps 1 and 4 in Figure 1). Having the authenticated victim user token associated with his account, the attacker can continue impersonating the victim user as long as it remains valid. 


Luckily, the solution to both of the aforementioned issues is straightforward:


  • Mitigating steps were taken for session fixation in OAuth 1.0a. Make sure that you are implementing either OAuth 1.0a[3] or above.
  • Implement SSL/TLS for any OAuth communication.


[1] http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/