Torii Vulnerability Disclosure
Security researcher Devin Weaver recently disclosed to us at 201 Created that Torii, the Auth Ember.js addon that we maintain, has a potential security vulnerability. The vulnerability affects all versions of Torii before 0.9.1 and can allow third parties to obtain the provided
code and any other parameters passed in the query string of a redirect callback URL from an OAuth provider.
Update May 25 2017: Edited to suggest using v0.9.5 of Torii.
Is Your App Affected?
Your app is only affected if all of the following are true:
- It uses any Torii OAuth Provider that uses a web redirection flow (such as the OAuth 2.0 Authorization Code Grant flow) that passes sensitive parameters in the the redirect URL query string. This includes all of the built-in OAuth 2 code and OAuth 1 providers. Any Torii provider that requires configuring a
redirectUriis potentially affected.
- It uses a
redirectUrithat loads your Ember app. This is the Torii default.
- Your Ember app loads third-party assets (scripts, images or stylesheets).
Your App Is Not Affected If
Your app is not affected if any of the following are true:
- It doesn’t use any Torii OAuth providers.
- It uses the
- It uses the
google-oauth2-bearerprovider or another provider that passes sensitive data through the URL hash rather than the query string.
- Your Ember app doesn’t load any third-party assets.
- You have configured a
redirectUriwith the OAuth provider that loads a page outside of your Ember app (and that page doesn’t load any third-party assets).
What To Do If Your App is Affected
Take the following steps:
- Upgrade Torii to version ^0.9.5
- Change the registered
redirectUriat the OAuth provider(s) that you use to be:
- Ensure your Ember app’s Torii configuration specifies this new URL for its
redirectUri. Torii 0.9.5 uses this as its default.
Explanation of Vulnerability
For redirect-based OAuth flows, Torii opens a popup window (or iframe) from the app’s main window. The popup window is loaded with the URL for an OAuth provider (e.g. “https://accounts.google.com/o/oauth2/auth”). After the user has logged in with the provider and clicked to allow access, the OAuth provider will redirect the window to your registered
redirectUri with a
codeparameter appended in the query string.
If the page that it redirects to loads any third-party assets, the browser will fetch those assets and send the current URL in the HTTP
referer header, including the sensitive
code parameter in the query-string, effectively transmitting this parameter to the third-party server.
Impact of Vulnerability
code parameter from an OAuth provider can be used by an attacker to replay an OAuth request. Possession of the
code by itself does not grant access to a user’s data at the OAuth provider (unlike an OAuth
access_token). In order to obtain an access token, your backend must communicate securely, server-to-server, using the obtained
code as well as the OAuth provider-issued client id and secret. As a result, possession of the
code by itself is usually not sufficient for an attacker to obtain an access token, but by replaying an OAuth request flow, an attacker could trick your backend into associating their OAuth Provider account with a victim’s account. The impact of leaking the
code parameter is mitigated somewhat by the fact that the only potential third parties that could view the code are third parties that you have already implicitly trusted (somewhat) by adding their scripts/images/css to your app.
For more detail on relevant security considerations see section 4.4 on the authorization code in RFC 6819, “OAuth 2.0 Threat Model and Security Considerations”.
For additional context on OAuth see this guide to the OAuth 2.0 authorization code grant flow, Aaron Parecki’s OAuth 2 Simplified, and a post I wrote titled Some Surprising Things About OAuth 2.0. A description of this particular type of OAuth vulnerability is described in more detail here.
We appreciate the efforts of Devin Weaver to responsibly disclose this vulnerability to us and work with us to put together an effective mitigation strategy. As a result of this experience we have also updated Torii’s readme section to have a dedicated Security section. If you discover a vulnerability in Torii please let us know by emailing firstname.lastname@example.org. You can encrypt the message with our public key.