Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 17 August 2011 06:51 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C6411E80A7 for <oauth@ietfa.amsl.com>; Tue, 16 Aug 2011 23:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbr4d4cTqkZ7 for <oauth@ietfa.amsl.com>; Tue, 16 Aug 2011 23:51:13 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 904A611E80A6 for <oauth@ietf.org>; Tue, 16 Aug 2011 23:51:13 -0700 (PDT)
Received: (qmail 26608 invoked from network); 17 Aug 2011 06:52:04 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Aug 2011 06:52:04 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 16 Aug 2011 23:52:02 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "eran@sled.com" <eran@sled.com>, OAuth WG <oauth@ietf.org>
Date: Tue, 16 Aug 2011 23:50:48 -0700
Thread-Topic: Authorization Code Leakage feedback (Yaron Goland)
Thread-Index: AcxcoxKThYc7pGPAToaDsdhSj5islAABbMpA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 17 Aug 2011 06:51:14 -0000

Noticed this follow up question after I sent this:

> 10.6. Authorization Code Leakage: Comment on "The authorization server
> SHOULD require the client to register their redirection URI": "Why is this a
> should?"

Because comparing the redirect_uri value used between the two calls (authorization and token) along with client authentication is sufficient to avoid the attack described for confidential clients. For public clients it is a MUST.


How about this:

10.6.  Authorization Code Redirection URI Manipulation

   When requesting authorization using the authorization code grant
   type, the client can specify a redirection URI via the "redirect_uri"
   parameter.  If an attacker can manipulate the value of the
   redirection URI, it can cause the authorization server to redirect
   the resource owner user-agent to a URI under the control of the
   attacker with the authorization code.

   An attacker can create an account at a legitimate client and initiate
   the authorization flow.  When the attacker is sent to the
   authorization server to grant access, the attacker grabs the
   authorization URI provided by the legitimate client, and replaces the
   client's redirection URI with a URI under the control of the
   attacker.  The attacker then tricks the victim into following the
   manipulated link to authorize access to the legitimate client.

   Once at the authorization server, the victim is prompted with a
   normal, valid request on behalf of a legitimate and familiar client,
   and authorizes the request.  The victim is then redirected to an
   endpoint under the control of the attacker with the authorization
   code.  The attacker completes the authorization flow by sending
   the authorization code to the client using the original redirection
   URI provided by the client.  The client exchanges the authorization
   code with an access token and links it to the attacker's client
  account which can now gain access to the protected resources
   authorized by the victim (via the client).

   In order to prevent such an attack, the authorization server MUST
   ensure that the redirection URI used to obtain the authorization
   code, is the same as the redirection URI provided when exchanging the
   authorization code for an access token.  The authorization server
   MUST require public clients and SHOULD require confidential clients to
   register their redirection URI and if provided in the request, MUST
   validate the redirection URI received in the authorization request
   against the registered value.

EHL