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

Adam Renberg <tgwizard@gmail.com> Mon, 13 October 2014 20:57 UTC

Return-Path: <tgwizard@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E258A1A006D for <oauth@ietfa.amsl.com>; Mon, 13 Oct 2014 13:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JNFzSx381a1 for <oauth@ietfa.amsl.com>; Mon, 13 Oct 2014 13:57:19 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0330F1A0055 for <oauth@ietf.org>; Mon, 13 Oct 2014 13:57:18 -0700 (PDT)
Received: by mail-ig0-f171.google.com with SMTP id h15so11982867igd.10 for <oauth@ietf.org>; Mon, 13 Oct 2014 13:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jAcpQBauD75FQVTdUI1ifyaLFXk66K9pNCcMN1u0tmQ=; b=D68o5mMztqGet9r32WqKfRoQI4Ah/zIhowhybJWMgXIvINzNujg8eOsDs/6Ik9eRMv QiwbtCRoQvOLWWLg9M7NqBKoTssX2BGcPwSxy1+L2rKLU4/WG7V4QeApW2q54q0O/sJ0 MyFrRXWUudKrpl3wccw4DDLyskpAygG2ONeU6N/oifnL6zzKdAaAEQya24nZIJ0athqm rF+DUw3MUj8j+3JdwMDzLscnc8/crfQmyxaGvbsG3GlfLraGqIQmJzn2ZEksczFWILLx v+YTsrDoS8szfCsmUe5To54RsyaYgoLa3/WRgAtgve1AMHRFzAz34GxHGYTd5OZTP549 OH6w==
X-Received: by 10.42.237.80 with SMTP id kn16mr1012256icb.29.1413233838401; Mon, 13 Oct 2014 13:57:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.72.44 with HTTP; Mon, 13 Oct 2014 13:56:58 -0700 (PDT)
In-Reply-To: <543BFF34.1070307@gmx.net>
References: <543BFF34.1070307@gmx.net>
From: Adam Renberg <tgwizard@gmail.com>
Date: Mon, 13 Oct 2014 22:56:58 +0200
Message-ID: <CABzQGh===i9GzLFuRf3P9CrZtDh4-610qRApjOTVxJNxeLi7dA@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="047d7bacb3f2ec30b00505542419"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9OiRrr8j2E1M5c_35sxTny1ZXo0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Blackhat US: OAuth Talk
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2014 20:57:21 -0000

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" <hannes.tschofenig@gmx.net>
wrote:

> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>