OAuth, OpenID Flaw: 7 Facts

Authentication-protocol implementation security flaws are not as serious as Heartbleed, but Facebook and other sites must be fixed, say security experts.

Mathew J. Schwartz, Contributor

May 8, 2014

7 Min Read

10 Ways To Fight Digital Theft & Fraud

10 Ways To Fight Digital Theft & Fraud

10 Ways To Fight Digital Theft & Fraud (Click image for larger view and slideshow.)

The recently disclosed security flaws in some implementations of the widely used OAuth and OpenID website authentication mechanisms are serious. But they're not nearly as bad as the recently discovered Heartbleed vulnerability in OpenSSL, and they pose much less of an immediate and direct threat to people's personal information.

That's the message from numerous security researchers who have been investigating the details of security flaws in OAuth 2.0 and OpenID. Mathematics Ph.D. student Wang Jing issued a covert redirect vulnerability warning earlier this month.

"The vulnerability could lead to open redirect attacks to both clients and providers of OAuth 2.0 or OpenID," Wang said. "Almost all major OAuth 2.0 and OpenID providers are affected, such as Facebook, Google, Yahoo, LinkedIn, Microsoft, PayPal, GitHub, QQ, Taobao, Weibo, VK, Mail.Ru, Sohu, etc."

[Deceptive downloads and ransomware is increasing at an alarming rate. Read Microsoft: Deception Dominates Windows Attacks.]

After Wang published his warning, some media outlets began conflating the severity of the federated identity implementation flaws he highlighted to Heartbleed. But many information security experts disagree. "This is not as big a deal as Heartbleed. It's totally different -- comparing apples to oranges," says Satnam Narang, security response manager at Symantec.

Without a doubt, however, multiple open-redirect-related problems do need to be fixed. Here are seven related facts:

1. At risk: open redirects
To be clear, the flaw highlighted by Wang -- which isn't new -- doesn't exist in OAuth 2 or OpenID, but rather in how some businesses have implemented those and other standards. The primary problem pertains to the use of open redirects, which redirect HTTP requests. "There have been open redirectors for as long as there's been HTML," said John Bradley, senior technical architect with Ping Identity, "so it's not a new problem." Bradley has contributed to SAML, OpenID Connect, Information Card (IMI), and XRI, among other identity standards and is also helping develop the next version of OpenID.

Furthermore, related protections are already available. "All those protocols have known about this problem since their inception, and have various mitigations," he explained by phone.

2. Developers, sites, don't follow security recommendations
Many sites and developers don't follow the security mitigations recommended by the standards. Facebook, for example, allows developers to use whitelisting to restrict the range of sites to which incoming open-redirect requests can be redirected, which would block related exploits. But Facebook made it an optional feature. "They did that, as near as I can tell, because developers are lazy," Bradley said.

Likewise, to make it easier to authenticate users, some developers append access tokens to their HTTP requests before they get sent to open redirects. This, however, makes it easy for an attacker to employ JavaScript to strip the tokens out and log on to the site as the user.

Figure 1:

3. ESPN abuse highlights attack seriousness
Wang demonstrated that precise flaw in a YouTube clip, showing how an open redirector located on the ESPN website -- which allowed users to authenticate using Facebook Connect -- could be abused. Notably, the open redirector redirected to any site specified in a URL parameter, and also passed the query string parameters to the receiving site.

"Probably the biggest security problem in what happened to ESPN was that someone who got the access tokens and replayed them at ESPN could have gotten into those accounts at ESPN," Bradley said. But because the redirector was also passing the query string, an attacker could strip it out and reuse the token. "The same token can be replayed at ESPN or the Facebook client, which lets the user get into the site as that user," he explained. "So it's not just leaking people's information,

Next Page

it's creating a backdoor attack on the Facebook client as well. That's why we take this so seriously."

4. Beware social engineering angle
Another way open redirectors can be abused is to send users to malicious sites. If that happened, though, Symantec's Narang said the site would have to trick the user into allowing their third-party credentials -- for example, from Facebook or Google -- to be used to log into the site. "So it involves social engineering -- that part needs to be clear," he pointed out.

While it will be up to affected sites and developers to put related fixes in place, users themselves should also beware of such attacks. "Users have to do their part too, and be cautious and skeptical," Narang said. "If you're not requesting to authenticate with ESPN's application, then you definitely shouldn't do it."

5. Developers: know your state
One way to mitigate related vulnerabilities is to restrict the URLs to which the redirector will redirect. "It's always best, if you can, to do exact URI redirect matching," Bradley advised. "The problem is, in the advice you give developers, if you give them an inch, they'll take a mile."

Many web applications that rely on third-party authentication use what's called an implicit flow. That involves giving a browser client an access token after the user gives that client access. Bradley says the approach is perfectly acceptable in some scenarios, such as for JavaScript in the browser.

Otherwise, however, he recommends that developers use the more complex "code flow" approach, which involves additional API calls to further verify the authenticity of the client, and which becomes essential for ensuring security when clients maintain any type of server-side state. It also adds the ability to refresh the token and provide offline access.

Many developers, however, have used implicit flows when they should be using code flows, and many sites have allowed them to do so. (Bradley recently published OAuth guidance for developers about how to employ the right flow techniques.)

In contrast, some organizations, such as telecommunications company Deutsche Telekom, allow only code flow and discard all implicit flow requests. As a result, Bradley said, the open redirector security flaws didn't affect them at all.

6. After coordinated disclosure, some sites fixed
Wang said he notified all businesses that he's listed as having vulnerable implementations of OAuth 2 or OpenID prior to making his public announcement earlier this month. "I found this vulnerability at the beginning of February and I have reported it to related companies," he said.

Google responded that it's aware of the problem and are tracking it at the moment, Wang said. Likewise, his reports were also acknowledged by Facebook, Microsoft -- which said the flaw he identified was due to a third party -- Chinese microblogging site Weibo, and LinkedIn.

Wang said Yahoo failed to respond in any way to his vulnerability warning, while Chinese online shopping site Taobao "closed my report without providing a reason." Finally, Wang said that he didn't notify other affected sites, including Russian sites VK and Mail.Ru, because he couldn't locate contact information for their security teams.

7. Fixing insecure implementations will take time
Some affected sites have already put related fixes in place. On March 13, for example -- evidently after receiving Wang's vulnerability report -- LinkedIn told developers they would have one month to register their OAuth 2 redirect URLs. "If you do not take the steps noted above by April 11, 2014, requests to authorize new members or refresh tokens will fail. We will display an error message and not redirect the member to your application," LinkedIn said.

But not every site appears willing to practice that type of tough love. Some are opting for more phased transitions. "Facebook making any type of change, because they have such a large client/developer base, if they turned on maximum security, all the people who wrote clients [that assume] weak security, they're going to break," Bradley said.

In other words, don't expect related OAuth 2 and OpenID fixes to appear overnight.

Cyber-criminals wielding APTs have plenty of innovative techniques to evade network and endpoint defenses. It's scary stuff, and ignorance is definitely not bliss. How to fight back? Think security that's distributed, stratified, and adaptive. Read our Advanced Attacks Demand New Defenses report today. (Free registration required.)

About the Author(s)

Mathew J. Schwartz


Mathew Schwartz served as the InformationWeek information security reporter from 2010 until mid-2014.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like

More Insights