Analyzing the BrowserID SSO System with Primary Identity Providers Using an Expressive Model of the Web

Abstract

BrowserID is a complex, real-world Single Sign-On (SSO) System for web applications recently developed by Mozilla. It employs new HTML5 features (such as web messaging and web storage) and cryptographic assertions to provide decentralized login, with the intent to respect users' privacy. It can operate in a primary and a secondary identity provider mode. While in the primary mode BrowserID runs with arbitrary identity providers, in the secondary mode there is one identity provider only, namely Mozilla's default identity provider. We recently proposed an expressive general model for the web infrastructure and, based on this web model, analyzed the security of the secondary identity provider mode of BrowserID. The analysis revealed several severe vulnerabilities, which have been fixed by Mozilla. In this paper, we complement our prior work by analyzing the even more complex primary identity provider mode of BrowserID. We do not only study authentication properties as before, but also privacy properties. During our analysis we discovered new and practical attacks that do not apply to the secondary mode: an identity injection attack, which violates a central authentication property of SSO systems, and attacks that break an important privacy promise of BrowserID and which do not seem to be fixable without a major redesign of the system. Interestingly, some of our attacks on privacy make use of a browser side channel that, to the best of our knowledge, has not gained a lot of attention so far. For the authentication bug, we propose a fix and formally prove in a slight extension of our general web model that the fixed system satisfies all the authentication requirements we consider. This constitutes the most complex formal analysis of a web application based on an expressive model of the web infrastructure so far. As another contribution, we identify and prove important security properties of generic web features in the extended web model to facilitate future analysis efforts of web standards and web applications.

The Web SSO Standard OpenID Connect: In-depth Formal Security Analysis and Security Guidelines

“…This shows that state cannot be known to any party except for b, i, and r. 19 Note that we have only web attackers. 20 We note that, as discussed earlier, without the Referrer Policy, state could leak to a malicious IdP or other parties.…”

“…The mitigation presented in Section III-A would have prevented the attack in Step 16 ff. Figure 5) 20 POST /start email 21 Response Redirect to HIdP authEP with client_id, redirect_uri, state 22 POST /token access_token , code, state 23 POST tokenEP code, client_id, redirect_uri, client_secret 24 Response access_token , id_token 25 Response session_cookie 26 POST tokenEP code, client_id, redirect_uri 27 Response access_token , id_token 28 Response access_token , id_token 29 GET /protectedResource access_token 30 GET /protectedResource access_token 31 Response secret user data dec a (enc a (x, pub(y)), y) = x…”

“…In this and the following two sections, we present the FKS model for the web infrastructure as proposed in [19], [20], and [24], along with the addition of a generic model for HTTPS web servers that harmonizes the behavior of such servers and facilitates easier proofs.…”

“…Also, since both scripts are always delivered with a restrictive Referrer Policy header, any requests that are caused by these scripts (e.g., the start of a new login flow) do not contain state in the referer header. 20 If state is contained in the fragment, then state is not immediately sent to r, but instead, a request without state is sent to r. Since this is a GET request, r either answers with a response that only contains the string ok but no script (Lines 23ff. of Algorithm 20), a response containing script_rp_index (Lines 2ff.…”

A Comprehensive Formal Security Analysis of OAuth 2.0

“…Then, as soon as the user starts a new OAuth flow with the same RP and an honest IdP, the malicious IdP can use the known state value to mount a CSRF attack, breaking the session integrity property. 14 We also model CSRF protection for some URIs as follows: For RPs, we model origin header checking 15 (1) at the URI where the OAuth flow is started (for the implicit and authorization code mode), (2) at the password login for the resource owner password credentials mode, and (3) at the URI to which the JavaScript posts the access token in the implicit mode. For IdPs, we do the same at the URI to which the username and password pairs are posted.…”