Journal of Computer Security and Usability

May 29, 2012

Addressing Vulnerabilities in Single Sign On Networks

Last week marks the end of a nearly sixteen week research project in the field of cloud and distributed system security, with the centerpiece of this research addressing and resolving a privacy vulnerability within OpenID, a distributed Single Sign On protocol. This research addresses a privacy flaw that has been documented since 2010. This vulnerability is capable of leaking unique, identifiable information to a third party, and therefore poses a risk for unauthorized tracking. Because this tracking occurs without any user consent – or the user really even knowing that their credentials were leaked in the first place – any resolution of this vulnerability would offer a leap forward in securing distributed authentication networks such as OpenID.

A Little Bit About OpenID

As more computer applications and services become available on the Internet, users are facing a daunting task of having to remember dozens and dozens of usernames and passwords. In response, a class of software known as Single Sign On systems have emerged in order to combat the problem. What SSO allows is for an authoritative Identity Provider to validate the credentials of a user to many web applications across many domains while providing only a single login prompt and login method to the user that is controlled, secured, and maintained by only one entity. Therefore, the user only needs to remember one username and one password.

The most popular open SSO protocol and software that is available today is OpenID. OpenID is a distributed system that allows for anyone to establish their own SSO system, making it ideal for companies with dozens of internal applications who want to implement a system to allow employees to use all of these applications with only one login. However, OpenID has failed to gain widespread adoption in a more general role of validating users across public websites, which was the original intention of OpenID. Instead, closed and proprietary SSO protocols such as ones offered by Facebook and Google have become much more popular.

A reason for this has to do with several unresolved flaws in the OpenID protocol itself, one of them being a vulnerability caused by what is usually very useful diagnostics data encoded within HTTP, OpenID’s underlying transport protocol. This vulnerability allows information that is globally unique for every user of OpenID to leak to third parties, such as computer systems maintained by advertising companies. Exploitation of this vulnerability would allow a third party to effortlessly track an OpenID user without that user’s knowledge or consent.

The "Referer" Vulnerability

The vulnerability in OpenID originates from the choice of how transaction information is encoded and transmitted. OpenID transaction information is transmitted within URL parameters, and this can unsafely expose unique and identifying information about a user to a third party. HTTP contains a curiously misspelled utility feature known as the “Referer” value. Web pages may contain various external resources in order to render as intended, and all modern browsers will attempt to retrieve these resources automatically as they begin to render the page. On retrieval of an external resource, modern browsers will attach a Referer value that contains the original URL that requires the external resource, including all URL parameters and other information that was encoded into the original URL. Now, OpenID uses HMAC signed messages to prevent tampering, but for the most part OpenID data is transmitted with no encryption. In consequence, unencrypted OpenID information becomes exposed if a page used as part of the OpenID transaction contains any external resources, such as pictures, stylesheets, and executable scripts.

Testing for in-the-wild instances of this vulnerability is fairly simple, and indicates just how prolific of a problem this has become. You can easily find vulnerable sites by capturing all HTTP data transmitted and received by your web browser during each step of an OpenID transaction. Any external resources that are retrieved can be traced to a unique step in the transaction. When we analyze the last step in particular, when the Identity Provider hands the user back to the Relying Party, we may begin to notice resources that are outside of the “safe” region of the two domains participating in the OpenID transaction. Further inspection reveals that on many sites that support login via OpenID, HTTP Referer information contains our OpenID credentials, including our globally unique OpenID identifier.

Of all sites analyzed during this research, an overwhelming majority of the third parties that had OpenID information leaked to them belonged to companies whose primary business models were advertising and consumer analytics.

Resolving the Vulnerability

The solution proposed through this research is a system that had to overcome the challenges of working within the decentralized, distributed architecture of OpenID. The solution must be convenient and require no cumbersome setup or installation steps that need to be taken by the individual OpenID user, as my experiences as a sysadmin has shown that users are extremely averse to installing software on their computers that is actually good for them.

Additionally, a solution must be devised that cannot be circumvented by Relying Parties, as the evidence collected during the course of this research suggests that some Relying Parties may be intentionally exploiting this vulnerability for ad revenue. The best place to implement a solution was found to be at the Identity Provider, which theoretically should care the most about user security and privacy, as they are already trusted with keeping the user’s network credentials safe.

One potential and proposed method includes the Audit Method, which requires the active auditing of relying parties by identity providers that would check for and attempt to exploit known weaknesses in the distributed authentication infrastructure; passage of this audit would be certification of a secure relying party, at least in the eyes of that particular identity provider.