Subject: [OAUTH-WG] Blackhat US: OAuth Talk

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Oct 2014 18:35:00 +0200

During the OAuth conference call today I asked whether someone had
looked at this paper published at the recent Blackhat US conference and
nobody knew about it.

Hence, I am posting it here:

* Paper:

https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Million-Node-Social-Graph-In-Just-One-Week-WP.pdf

* Slides:
https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Million-Node-Social-Graph-In-Just-One-Week.pdf

Ciao
Hannes

---

From: Adam Renberg <[email-masked]>
Date: Mon, 13 Oct 2014 22:56:58 +0200

Hi!,

I have read through the paper, and what they consider a flaw in OAuth 2 is
the fact that for the implicit grant flow the access token is sent to the
client through the User Agent, and thus the User Agent can intercept it.
What they find is that "social network provider X" allows the implicit
grant flow for clients that normally use the authorization code flow. This
makes it possible for and attacker to construct an implicit flow request
and obtain an access token issued for the client, and this access token
might incorrectly be considered as for a confidential client by the
provider.

But the issue here is with the provider, which treats the same client as
both public and private, and not with OAuth 2.

The paper also takes issue with the fact that an API that is authorized
with OAuth 2 exposes more data than what is normally presented to the user
when browsing at provider X. This is not an issue with OAuth 2.

They also take issue with the fact that the provider does not throttle API
calls, so it is possible to make a crawler, using access tokens issued for
a registered client but through the implicit flow, and *authorized by a
resource owner complicit with the attackers / crawler builders*, to scrape
large amounts of data from the provider. Data that users might not think to
be so "publicly accessible".

I think that this is dealt with in

https://tools.ietf.org/html/rfc6749#section-10.1,
https://tools.ietf.org/html/rfc6749#section-10.2, and by RFC 6819 5.2.3.2.
Require User Consent for Public Clients without Secret
https://tools.ietf.org/html/rfc6819#page-60

Cheers,

Adam Renberg (first time poster :))

On Oct 13, 2014 6:35 PM, "Hannes Tschofenig" <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 14 Oct 2014 09:53:31 +0000

hi Hannes,

thanks for the link. It is interesting.
Said that I think the attack shown there are a bit “academic” and do not reflect the real life situation. Moreover it still mention the MAC flow when AFAIK the OAuth working group decided to deviate from it.
IMHO the majority of real life attacks (and I can provide many many examples taken from blog posts of people that hacked big providers such Google,Facebook, Github etc) are actually targeting two things:

- weak/incorrect validation of the redirect_uri parameter
- leak of the access token . authorization code from the referrer

just my 0.02 cents :)

regards

antonio