Google and OAuth 2.0
asutherland at asutherland.org
Fri May 2 19:04:14 UTC 2014
On 05/02/2014 10:19 AM, Onno Ekker wrote:
This does not appear to be anything that would affect Thunderbird's
implementation of OAuth2 unless the OAuth providers decide to
aggressively mitigate this threat model, in which case it may hurt
Thunderbird's use case. The risk model for Thunderbird's account setup
would continue to be vulnerabilities in the autoconfig process allowing
an attacker to interpose themself as a persistent or transient
The documentation available on the actual attack at
http://tetraph.com/covert_redirect/ is extremely limited given the
effort to build the website and post the same information multiple times
to different blogging networks, etc. But based on what is there, it
sounds like the attack is one of the familiar cases of making a
nefarious link look legitimate by using redirecting/link shortening
services hosted by a domain the user trusts. There may then be
secondary risks based on how much effort the OAuth provider put into
validating the application registrations. Since the authorization
screen will display this data and be hosted on (and look like it's
hosted on) the OAuth provider's website, it may cause the user to
believe the information is more trustworthy than it actually is. "Oh,
that first link looked sketchy, but now this looks okay, so I guess it's
okay after all."
The potential for the attacker to effectively never be showing their
origin in the process does contribute to the problem. The only
persistent UI that needs to exist is the OAuth provider's authorization
page. The attacker's server can just poll the server in the
background. Unfortunately the many possible OAuth flows where the
application can't keep a secret (ex: Thunderbird) and doesn't live as a
webpage in the user's browser means it's effectively impossible to
completely prevent the user from doing something dangerous under the
auspices of the client.
Total mitigation of this type of risk really depends on the user,
- Be aware of what they're clicking on (sketchy / obfuscated link?), and
where they're clicking on it (sketchy website?).
- Be aware of the context of the request too. You are unlikely to
randomly need to reauthorize Thunderbird.
But existing apps can also help with this:
- Popup blocking logic may be helpful.
- Browsers could detect suspicious redirects. Unfortunately, the
ubiquity of link shorteners for good and bad reasons can complicate this.
- Browsers already have safe browsing mechanisms.
- Mail clients can integrate similar mechanisms, although there is the
problem of piercing shortened links leaking information that an email
has been either displayed or received.
- Help the user by establishing reasonable standards for safety. When
using OAuth2 in cases where it might be conducive to pop-up the
authorization in the user's web browser (ex: for Thunderbird), make sure
to first use chrome in Thunderbird to say: "Hey, we need to
re-authorize. Click [No, be broken for now] or [Yes, let's reauthorize
in the browser]".
More information about the tb-planning