Account login services that implement applications from Google, Facebook, and other commercial providers are prone to flaws that allow adversaries unauthorized access to private user profiles on the third-party Websites that use them, a team of computer scientists has concluded.

Their 10-month study found that many SSO, or single sign-on, services supplied by IdPs or ID Providers including Google, Facebook, and PayPal weren't properly integrated into Websites that used the services. As a result, private data on RP, or relying party, sites belonging to Farmville, Freelancer, Nasdaq, Sears, JanRain, and other sites were all vulnerable to snoops.

"The result shows that these prominent web SSO systems contain serious logic flaws that make it completely realistic for an unauthorized party to log into their customers' accounts," the scientists wrote in a research paper (PDF) scheduled to be presented at the IEEE Symposium on Security and Privacy in May. "These flaws are also found to be diverse, distributed across the code of [third-party Websites] and [SSO providers], and at the stages of login and account linking."

The researchers reported the vulnerabilities to parties responsible for the code and in the vast majority of cases, those parties have already implemented fixes. But in an email, XiaoFeng Wang, an associate professor of informatics and computer science at Indiana University and one of the report's coauthors, wrote: "We strongly believe that given the complexity of web SSO service integration, particularly the coordination between RP and IdP, other web SSO systems can also be error-prone."

SSO services have grown in popularity with the increased use of social networking. Part of its appeal is the promise that security professionals from Google, Facebook and other large properties can build and maintain sensitive services that smaller Websites can deploy. Many end users prefer them because they allow them to use a single password to access scores of individual accounts, saving them the hassle of having to use a unique code for each one.

SSOs typically work by offering programming interfaces that relay the visitor's login information to the provider of the service. If the user credentials are valid, the provider usually returns some sort of certified token that instructs the third-party Website to give the user access to the requested account. The problem with this "proof-by-possession" scheme is that the data relayed from Website to provider is sent to the end user's browser first, creating the opportunity for adversaries to manipulate the credentials that are sent to and from the provider. As a result, an attacker can obtain a token granting him access to an account without supplying the user name and password that are normally required for authorization.

A critical bug affecting the Google SSO service, for example, stemmed from the ability to change queries received from the RP before a user's browser sent it to Google. That allowed an attacker to remove the Gmail address the website was asking Google to vouch for before the request was sent and then append a victim's Gmail address to the response returned by Google. The flaw, which Wang said was the result of a miscommunication between the website and Google over whether the email address the Website receives had been signed, has since been addressed.

The researchers also found weaknesses in OpenID, a popular open standard that the researchers said Google, PayPal, and 9 million other sites use to grant access to more than 1 billion accounts. The OpenID foundation has since addressed those bugs as well.

In some respects, Wang said, the bugs were the result of oversights made by the SSO providers, which tested custom-made implementations of OpenID software and failed to discover the problems. But in other cases, the vulnerabilities existed because the third-party sites didn't implement otherwise secure SSOs correctly. Ensuring they are set up correctly is difficult given the huge number of modifications typically made when a system is integrated into a given Website.

"During this process, a protocol serves merely as a loose guideline, which individual RPs often bend for the convenience of integrating SSO into their systems," the paper states. "Some IdPs do not even bother to come up with a rigorous protocol for their service. For example, popular IdPs like Facebook and Google, and their RPs either customize published protocols like OpenID or have no well-specified protocols at all."

In an e-mail, a Facebook spokesman thanked the researchers for privately reporting the bug. "It was fixed shortly after it was reported and we are not aware of any cases in which it was used maliciously. Developers can find our documentation on Authentication using Facebook Platform here. A Google spokesman declined to comment for this article.

The researchers also found that the security of otherwise safe SSOs were sometimes undermined when the systems were combined with certain components. Cross-domain capabilities built into Adobe Flash, for instance, "totally crippled Facebook SSO security," they said.

The researchers, who also included Indiana University professor Rui Wang and Shuo Chen of Microsoft Research, designed an automated black-box test to analyze the series of HTTP messages that passed between the RPs and the IdPs to invoke the SSO's programming interfaces. Their analyzer worked by capturing and parsing browser response messages and in some cases later modifying them. Among other things, it used the Fiddler web proxy and the Firebug tool for web development.

While the blue prints of a given system aren't always available to attackers, the web traffic that the SSO systems generate is trivial to view, often making it easy to spot errors that can be exploited, the researchers warned.

They wrote: "Our study shows that not only do logic flaws pervasively exist in web SSO deployments, but they are practically discoverable by the adversary through analysis of the SSO steps disclosed from the browser, even though source code of these systems is unavailable."