Subject: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect

From: Michael D Adams <[email-masked]>
Date: Sat, 24 Jul 2010 02:23:45 -0700

The second to last paragraph in section 3 of draft-10 states:

> The authorization server validates the request to ensure all required
> parameters are present and valid.  If the request is invalid, the
> authorization server immediately redirects the user-agent back to the
> client using the redirection URI provided with the appropriate error
> code as described in Section 3.2.

There's a couple problems here.

1. What if the client didn't register a redirect_uri and also didn't
include one in the request?  The request is invalid, but there's
nowhere to redirect the user-agent.

2. A malicious client can use the end-user authorization endpoint as
an open redirect by intentionally making an invalid request.  For
example:

End-User Authorization Endpoint: http://service.example.com/oauth/authorize/
Malicious Site: http://jerk.example.net/

I send a phishing attempt to a user of service.example.com with
something like the following link in it:

http://service.example.com/oauth/authorize/?redirect_uri=http%3A%2F%2Fjerk.example.net%2Fsteal-your-identity%2F&response_type=haha

The link looks OK at a glance, but clicking on it takes the victim to:

http://jerk.example.net/steal-your-identity/?error=unsupported_response_type

And now I do whatever evil thing I've planned.

Mike
--mdawaffe

---

From: Luke Shepard <[email-masked]>
Date: Mon, 26 Jul 2010 00:19:58 +0000

This is a great point.

Facebook validates that the client_id matches the registered redirect_uri before giving a redirect error. Otherwise, just display a screen directly saying that the app is misconfigured. Mis-specifying the redirect_uri is the type of error that should normally be caught in development, so there's no need for an official error code for it (since it shouldn't ever happen in production).

We should specify that the provider should only redirect an error code to a known-good location (or at least, a somewhat vetted one) to prevent open redirectors.

On Jul 24, 2010, at 2:23 AM, Michael D Adams wrote:

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 26 Jul 2010 08:07:06 -0400

And this is even a bigger potential problem when you combine it with unregistered or dynamically-registered clients, which we know some instances are going to support. In these cases, though, it's hard to trust *any* URL that the client is asking for, even for valid responses. 

 -- justin

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Luke Shepard [[email-masked]]
Sent: Sunday, July 25, 2010 8:19 PM
To: Michael D Adams
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] End-User Authorization Endpoint is an Open Redirect

This is a great point.

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 26 Jul 2010 10:29:56 -0700

> And this is even a bigger potential problem when you combine it with unregistered or dynamically-registered clients, which we know some instances are going to support. In these cases, though, it's…

The user must approve a valid response, so it should not work as a
redirector. Right?

An immediate mode will only work if the user explicitly approved at
least once in the past.

Marius

---

From: Luke Shepard <[email-masked]>
Date: Mon, 26 Jul 2010 19:01:17 +0000

Correct. If the user has to approve the response, then it doesn't function as an open redirector. I'm only worried about returning an error immediately.