Authentication methods used by major web sites like Facebook, Google, and others could end up redirected by attackers, a researcher said.
A blog posted last week revealed the details of security flaws in OAuth 2.0 and OpenID, two technologies widely used by the Web’s most popular sites to more quickly and easily verify the identity of a user. Wang Jing, a PhD student in mathematics at Nanyang Technological University discovered the vulnerability.
If you have ever allowed an application or website to verify your identity using your Facebook, Twitter, or Google account, then you have likely used OAuth or OpenID. OAuth is an open standard for authorization that gives client applications secure, delegated access to server resources on behalf of a resource owner.
OpenID an open standard that allows users to be authenticated by certain cooperating sites using a third party service, eliminating the need for webmasters to provide their own authentication systems and allowing users to consolidate their digital identities.
The vulnerability could allow an attacker to redirect the “token” used by OAuth 2.0 to access user information on a third-party site, making it possible to steal information such as the email address, age, or location of a user, the blog said. In OpenID, the vulnerability could enable attackers to collect user’s information directly.
The flaw is a “Covert Redirect” vulnerability, in which an application takes a parameter and redirects a user to the parameter value without sufficient validation. This differs from an Open Redirect, in which an application takes a parameter and redirects a user to the parameter value without any validation at all.
If a website ends up exposed to Open Redirect attack, it is often because the site’s operators failed to equip their own site with proper validation, the blog explains. But a Covert Redirect is trickier, because it is essentially a flaw in the handoff of validation between one site and another.
“The Covert Redirect vulnerability related to OAuth 2.0 and OpenID is, in the author’s view, a result of the provider’s overconfidence in its clients/partners,” the blog says. “The provider relies on the clients to provide a list of ‘trustworthy’ domains and assumes all would be safe. However, without sufficient verification of the redirected URLs, no safety could be guaranteed.”
It isn’t always clear who’s responsible for the vulnerability: The website requesting the authentication or the third-party provider that gives the validation, the blog observes.
“The vulnerability is usually due to the existing weakness in the third-party websites,” the blog said. “However, they may be unaware of the vulnerability. Or they do not bother to fix it. One concern is the cost. The other is that in their view, the host company is responsible for making the attacks appear more credible; therefore, it is not solely their problem. However, to the provider, the problem does not originate from its own website. Even if it is willing to take on the responsibility, it has to gain cooperation from all the clients, which is a daunting task.”
And because it isn’t clear who’s responsible for the vulnerability, it may be a difficult problem to fix, the blog notes.
“The patch of this vulnerability is easier said than done,” the blog says. “If all third-party applications strictly adhere to using a whitelist, then there would be no room for attacks. However, in the real world, a large number of third-party applications do not do this. This makes the systems based on OAuth 2.0 or OpenID highly vulnerable.” Providers need to develop a more thorough verification procedure, the blog suggests.