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

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 16 Aug 2011 23:38:38 -0700

> 10.6. Authorization Code Leakage: Comment "I fancy myself as being

> reasonably intelligent and I'm unclear what attack is actually being described

> here."

Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about.

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

   SHOULD require the client to register their redirection URI and if

   provided, MUST validate the redirection URI received in the

   authorization request against the registered value.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 16 Aug 2011 23:50:48 -0700

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:

   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

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Wed, 17 Aug 2011 12:22:14 +0200

Text sounds very good.

wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not "authorization code phishing"?

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:[email-masked]]
Gesendet: Mittwoch, 17. August 2011 08:39
An: OAuth WG
Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)

How about this:

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 17 Aug 2011 23:06:11 -0700

I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions.

EHL

From: Lodderstedt, Torsten [mailto:[email-masked]]
Sent: Wednesday, August 17, 2011 3:22 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedback (Yaron Goland)

Text sounds very good.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Gesendet: Mittwoch, 17. August 2011 08:39
An: OAuth WG
Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)

How about this:

EHL

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 18 Aug 2011 09:11:35 +0200

The security document designates it as "Authorization code leakage through counterfeit client"

http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7

Von: Eran Hammer-Lahav [mailto:[email-masked]]
Gesendet: Donnerstag, 18. August 2011 08:06
An: Lodderstedt, Torsten; OAuth WG
Betreff: RE: Authorization Code Leakage feedback (Yaron Goland)

EHL

Text sounds very good.

regards,
Torsten.

How about this:

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 00:16:39 -0700

But it's not really a counterfeit client but a real client with modified redirection uri. It is a counterfeit redirection endpoint. *I* understand exactly what you mean, but I fear new readers will get completely confused by the title.

EHL

From: Lodderstedt, Torsten [mailto:[email-masked]]
Sent: Thursday, August 18, 2011 12:12 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedback (Yaron Goland)

EHL

From: Lodderstedt, Torsten [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, August 17, 2011 3:22 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedback (Yaron Goland)

Text sounds very good.

regards,
Torsten.

How about this:

EHL

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 18 Aug 2011 09:22:36 +0200

In my opinion, the counterfeit redirection endpoint is another client - the counterfeit client. The attacker must trick the victim into accessing this client and approving the authorization request. So I would assume the attacker would try to let his endpoint look like the real client.

Von: Eran Hammer-Lahav [mailto:[email-masked]]
Gesendet: Donnerstag, 18. August 2011 09:17
An: Lodderstedt, Torsten; OAuth WG
Betreff: RE: Authorization Code Leakage feedback (Yaron Goland)

EHL

EHL

Text sounds very good.

regards,
Torsten.

How about this:

EHL