Security Experts:

Covert Redirect Issue in OAuth, OpenID Places Security Responsibility in Wrong Place

The Covert Redirect issue, the reportedly "serious vulnerability" uncovered recently in login tools OAuth and OpenID, places the responsibility for user security in the wrong place, a security expert said.

OAuth and OpenID is part of an ecosystem where responsibility for security is shared, Tal Klein, vice-president of strategy for Adallom, told SecurityWeek. Users use a trusted provider to access other sites, but if the site turns out to be malicious, it isn't the fault of the provider for letting the user go to the site in the first place. However, there may still be steps providers can take to help minimize the potential risks for users, he said.   

OAuth and OpenID Login Vulnerabilities

"I don't know if this [Covert Redirect] is a flaw," as it is not supposed to be the provider's responsibility to decide what sites can use OAuth or OpenID, Klein said.

A site owner has two choices: handle user authentication on the site, which means learning the security basics of how to properly store and manage user credentials, or have users log in via OAuth or OpenID providers such as Google and Facebook. In that situation, the site sends a request to the provider, who displays a login screen to the user, and when the user logs in, the provider sends a unique token back to the site confirming the user had logged in. The site just uses that token to identify the user, and there is no need to worry about proper password hashing procedures or trying to implement multi-factor authentication. Many sites act as OAuth or OpenID providers, including Facebook, Google, Yahoo, LinkedIn, Microsoft, PayPal, and GitHub.

This login functionality—played out over the Internet on thousands of Websites every single day—can potentially be abused by malicious sites, argued Wang Jing, a doctoral student at the Nanyang Technical University in Singapore. Attackers could craft a malicious site and ask users to log in with their Facebook credentials, Wang said. When the user logs in, the site becomes authorized to access some user data such as email address, age, and location. If higher privileges are granted, Facebook may wind up exposing more sensitive information such as the friends list, or even grant permission to access the account, Wang said.

When Wang contacted Facebook, the company told him it "understood the risks associated with OAuth 2.0," and that "short of forcing every single application on the platform to use a whitelist," this wasn't something that could be fixed in the short term.

Unlike a typical phishing attack, where the attackers pretend to be a legitimate site and try to trick users into handing over actual login credentials, this attack uses legitimate functionality on a recognized site to get access to other types of data.

Providers need to develop "a more thorough verification procedure to prevent such attacks," Wang said.

Klein disagreed, saying, "This is not a Google of Facebook problem."

Calling this behavior a vulnerability is inaccurate because of the expectation that it is the provider's job to decide whether or not the site the user is trying to access is a legitimate site or not, Klen said. A blog or news site may require users to log in with Facebook to comment on a post, for example. An independent developer working on a Web application may not be confident in his or her ability to implement authentication securely and would rather outsource it to companies who are already experts. The list of potential sites which may legitimately use OAuth or OpenID is tremendous, and expecting providers to maintain a whitelist of sites that are allowed to use OAuth or OpenID doesn't make sense.

"We cannot put the onus on the provider to decide who is or isn't allowed to authenticate," Klein said.

While it is not up to the providers—the Facebooks and Googles of the world—to preemptively decide that a site the user is trying to access is bad and that the login process should not proceed, there are some steps that may help minimize the risk to users, Klein noted. When providers receive an OpenID or OAuth request, they could look up the domain name or IP address against blacklists to determine whether the site is a known-bad, and warn the user about the potential dangers. They can refuse to share any kind of user data when authenticating via OAuth or OpenID, regardless of what permissions the application requests. That way, if the site turns out to be malicious, the only thing exposed is the user's email address.

"Creating a blacklist makes more sense than a whitelist," said Mike Gross, senior manager of risk strategy and professional services at 41st Parameter, a division of Experian. Automatic revocation of banned apps would minimize the risks of malicious sites extracting user data.

When asked about the new login mechanism for mobile apps that Facebook announced this week at its developer conference, which would restrict how much user information gets exposed, Klein predicted the functionality is "probably being fast-tracked now."

Any user who has an account with an OpenID or OAuth provider such as Google and Facebook are potentially at risk if they click on a malicious link. That's a given. However, the problem originates with the act of clicking on the malicious link—not the providers for letting the site use the login tool. This kind of attack "relies on user interaction: a user must be phished, lured or convinced to allow access with their account," said Brandon Edwards, vice-president of SilverSky Labs at SilverSky.

It's also important to remember that when users log in, they will be shown a message from the provider explaining what kind of information the site is requesting. The users have to actually agree and authorize the site before the login process completes. "The flaw is human behavior," Klein said, noting that users have a tendency to click-through everything. It's quite possible users will ignore the screen where Facebook says that by continuing with the login, they will be letting the site have access to all their images and friends list, Klein noted. Wang even acknowledged in his blog post that "the user needs to consent in the first place" to give attackers access to more sensitive information.

Users should never click URLs that show up in spam or shady IM conversations and, most importantly, should not perform any authentication or authorization request that pops up unexpectedly, warned Bogdan Botezatu, senior e-threat analyst at BitDefender.

Users should regularly check their accounts to see what applications and sites have access to their accounts. Google Apps users can see what apps have been authorized and what types of access has been granted to those apps. Users should ban and revoke any apps which are unrecognized, especially those with document, contact, email, or domain access, recommended Kevin O'Brien, director of product marketing at CloudLock. Facebook and Twitter also let users see what sites have requested access to their accounts, and any apps no longer being used should immediately be revoked.

It's worth remembering that despite the comparisons to Heartbleed because OAuth and OpenID is widely used, the risk of highly sensitive data being exposed via this method is not very high. Covert Redirect is "far less impactful than Heartbleed, which has the potential to expose the most critical information that a site processes," and is not embedded in networking equipment such as VPN gateways and routers, suggested SilverSky's Edwards.

There is a problem with how attackers can manipulate OAuth and OpenID, but it isn't because login providers such as Google and Facebook aren't acting as gatekeepers on what sites can use the login tool and which sites can't.

Subscribe to the SecurityWeek Email Briefing
view counter
Fahmida Y. Rashid is a Senior Contributing Writer for SecurityWeek. She has experience writing and reviewing security, core Internet infrastructure, open source, networking, and storage. Before setting out her journalism shingle, she spent nine years as a help-desk technician, software and Web application developer, network administrator, and technology consultant.