AppSec Blog

LinkedIn OAuth Open Redirect Disclosure

During a recent mobile security engagement, I discovered an Insecure Redirect vulnerability in the LinkedIn OAuth 1.0 implementation that could allow an attacker to conduct phishing attacks against LinkedIn members. This vulnerability could be used to compromise LinkedIn user accounts, and gather sensitive information from those accounts (e.g. personal information and credit card numbers). The following describes this security vulnerability in detail and how I discovered it.

The Vulnerability
Section 4.7 of the OAuth 1.0 specification (RFC 5849) warns of possible phishing attacks, depending on the implementation. A vulnerable OAuth implementation could enable phishing attacks via user-agent redirection. The stated emphasis, further supported by OAuth 2.0 (RFC 6749 via "redirect_uri" parameter), is intended to raise awareness of open-redirection as a security vulnerability that should be avoided.

LinkedIn's implementation lacked validation between the value of its "redirect_uri" parameter and the origin (base) of a registered client's endpoint. In other words, if a redirect_uri (although optional) was entered during establishment of the OAuth integration, that redirect_uri value was not validated to ensure it belonged to a valid client. Manipulating this parameter to an unexpected location resulted in the application redirecting the user away from the intended web site.

The Attack
According to LinkedIn API documentation, the steps involved in obtaining an OAuth authorization token are as follows (prior to the fix recently put in place by LinkedIn):

First, a GET request specifying access permission is requested:,rw_nus,r_network&state=some_random_string_of_your_choice &redirect_uri=any_url

Upon successful authorization, a code is generated by LinkedIn and the end user's browser (user-agent) is redirected to the URL specified in the redirect_uri parameter. Notice that the domain specified in the "redirect_uri" parameter in the above screenshot is the payload specified by our hypothetical attacker that redirects the end user to the malicious site.

Next, the browser redirects the user to an impersonated LinkedIn login page via the "redirect_uri" parameter, which attempts to gather the LinkedIn user's credentials.

Finally, the victim then enters their credentials, trusting that the site is the official LinkedIn web application.

The proof-of-concept demonstrated the ability to phish for user's credentials, but could have a larger impact if used against LinkedIn Premium members with credit card numbers stored with their personal account information.

LinkedIn Remediation
I contacted LinkedIn about the vulnerability in October 2013, and it was a pleasant experience working with the LinkedIn Information Security team members. They confirmed the vulnerability within 2 days. From confirmation of the vulnerability to deployment of its remediation, LinkedIn spent approximately seven months (from October 2013 to May 2014) developing the patch. LinkedIn took advantage of this opportunity to upgrade its OAuth implementation to v2.0, while still supporting its legacy API (v1.0) for compatibility with existing applications. Based on the information provided by LinkedIn, such remediation required deep collaboration with several partners on how OAuth tokens are handled.

At the time of writing of this document, a patch for the disclosed vulnerability had already been deployed. For a detailed disclosure, please visit to obtain a free electronic copy (PDF).

About the Author
Phillip Pham is a security engineer with a strong passion for Information Security. Phillip has worked in various sectors and for organizations of various sizes, ranging from small start-ups to Fortune 500 companies. Prior to transitioning into an Information Security career, Phillip spent ten years in software engineering. His last five years of Information Security experience have been focused on Application Security. Some of his application security assessment strengths (both onpremise and cloudbased) include web applications, web services, APIs, Windows client applications, and mobile applications. He currently holds a GCIH certification and is cofounder of APT Security Solutions. Follow Phillip on Twitter @philaptsec.

Post a Comment


* Indicates a required field.