Google and OAuth 2.0

Andrew Sutherland asutherland at asutherland.org
Fri May 2 19:04:14 UTC 2014


On 05/02/2014 10:19 AM, Onno Ekker wrote:
> http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/

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 
man-in-the-middle server.

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, 
specifically:
- 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]".

Andrew



More information about the tb-planning mailing list