Subject: [OAUTH-WG] open redirect in rfc6749

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 15:43:17 +0000

hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
   redirection URI, or if the client identifier is missing or invalid,
   the authorization server SHOULD inform the resource owner of the
   error and MUST NOT automatically redirect the user-agent to the
   invalid redirection URI.

   If the resource owner denies the access request or if the request
   fails for reasons other than a missing or invalid redirection URI,
   the authorization server informs the client by adding the following
   parameters to the query component of the redirection URI using the
   "application/x-www-form-urlencoded" format, per Appendix B<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let’s assume this.
I am registering a new client to the victim.com<http://victim.com> provider.
I register redirect uri attacker.com<http://attacker.com>.

According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com<http://attacker.com>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this doesn’t apply since the resource owner MUST approve the app via the consent screen (at least once).

A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1

---

From: Bill Burke <[email-masked]>
Date: Wed, 03 Sep 2014 12:10:23 -0400

I don't understand.  The redirect uri has to be valid in order for a 
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
>     "application/x-www-form-urlencoded" format, perAppendix B  <https://tools.ietf.org/html/rfc6749#appendix-B>:
>
> Now let’s assume this.
> I am registering a new client to the victim.com <http://victim.com>
> provider.
> I register redirect uri attacker.com <http://attacker.com>.
>
> According to [0] if I pass e.g. the wrong scope I am redirected back to
> attacker.com <http://attacker.com>.
> Of course in the positive case if all the parameters are fine this
> doesn’t apply since the resource owner MUST approve the app via the
> consent screen (at least once).
>
> A solution would be to return error 400 rather than redirect to the
> redirect URI (as some provider e.g. Google do)
>
> WDYT?
>
> regards
>
> antonio
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

---

From: John Bradley <[email-masked]>
Date: Wed, 3 Sep 2014 12:14:37 -0400

In the example the redirect_uri is vlid for the attacker.

The issue is that the AS may be allowing client registrations with arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs the security consideration.

John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <[email-masked]> wrote:

> I don't understand.  The redirect uri has to be valid in order for a redirect to happen.  The spec explicitly states this.
>

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 16:19:03 +0000

On Sep 3, 2014, at 6:10 PM, Bill Burke <[email-masked]<mailto:[email-masked]>> wrote:

the redirect uri is indeed valid. The wrong parameter is the scope.

So if the attacker is the person that registers the app and register as redirect uri attacker.com<http://attacker.com> he can redirect anybody to attacker.com<http://attacker.com> levering the provider website uri…

Now let’s assume this.
I am registering a new client to the victim.com<http://victim.com/> <http://victim.com<http://victim.com/>>
provider.
I register redirect uri attacker.com<http://attacker.com/> <http://attacker.com<http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com<http://attacker.com/> <http://attacker.com<http://attacker.com/>>.
Namely I prepare a url that is in this form:

WDYT?

regards

antonio

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

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com<http://bill.burkecentral.com/>

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

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 16:46:35 +0000

hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

(this is the first time :p) but I do disagree with you. It would be pretty unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely returning 400 with the cause of the error..

400. That’s an error.

Error: invalid_scope

Some requested scopes were invalid. {invalid=[l]}

said that I hope you all agree this is an issue in the spec so far….

regards

antonio

John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <[email-masked]<mailto:[email-masked]>> wrote:

Now let’s assume this.
I am registering a new client to the victim.com<http://victim.com> <http://victim.com>
provider.
I register redirect uri attacker.com<http://attacker.com> <http://attacker.com>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com<http://attacker.com> <http://attacker.com>.
Namely I prepare a url that is in this form:

WDYT?

regards

antonio

---

From: Hans Zandbelt <[email-masked]>
Date: Wed, 03 Sep 2014 18:51:23 +0200

Let me try and approach this from a different angle: why would you call 
it an open redirect when an invalid scope is provided and call it 
correct protocol behavior (hopefully) when a valid scope is provided?

Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>> In the spec it is unspecified how a AS validates that a client
>> controls the redirect_uri it is registering.
>>
> (this is the first time :p) but I do disagree with you. It would be
> pretty unpractical to block this at registration time….
> *400.* That’s an error.
> *Error: invalid_scope*
>>>>   "application/x-www-form-urlencoded" format, perAppendix B
>>>>  <https://tools.ietf.org/html/rfc6749#appendix-B>:
>>>>
>>>> Now let’s assume this.
>>>> <http://victim.com>
>>>> I register redirect uri attacker.com <http://attacker.com>
>>>> <http://attacker.com>.
>>>>
>>>> attacker.com <http://attacker.com> <http://attacker.com>.
>> [email-masked] <mailto:[email-masked]>

-- 
Hans Zandbelt              | Sr. Technical Architect
[email-masked] | Ping Identity

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 16:56:12 +0000

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <[email-masked]<mailto:[email-masked]>> wrote:

Let me try and approach this from a different angle: why would you call it an open redirect when an invalid scope is provided and call it correct protocol behavior (hopefully) when a valid scope is provided?

as specified below in the positive case (namely when the correct scope is provided) the resource owner MUST approve the app via the consent screen (at least once).

Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely returning
400 with the cause of the error..

*400.* That’s an error.

*Error: invalid_scope*

regards

antonio

John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

Now let’s assume this.
I am registering a new client to the victim.com<http://victim.com/> <http://victim.com<http://victim.com/>>
<http://victim.com<http://victim.com/>>
provider.
I register redirect uri attacker.com<http://attacker.com/> <http://attacker.com<http://attacker.com/>>
<http://attacker.com<http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com<http://attacker.com/> <http://attacker.com<http://attacker.com/>> <http://attacker.com<http://attacker.com/>>.
Namely I prepare a url that is in this form:

WDYT?

regards

antonio

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

--
Hans Zandbelt              | Sr. Technical Architect
[email-masked]<mailto:[email-masked]> | Ping Identity

---

From: Hans Zandbelt <[email-masked]>
Date: Wed, 03 Sep 2014 19:10:18 +0200

Is your concern clients that were registered using dynamic client 
registration?

Otherwise the positive case is returning a response to a valid URL that 
belongs to a client that was registered explicitly by the resource owner 
and the negative case is returning an error to that same URL.

I fail to see the open redirect.

Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>
> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Let me try and approach this from a different angle: why would you
>> call it an open redirect when an invalid scope is provided and call it
> as specified below in the positive case (namely when the correct scope
> is provided) the resource owner MUST approve the app via the consent
> screen (at least once).
>
>
>>
>> Hans.
>>
>>>>>> I am registering a new client to thevictim.com
>>>>>> <http://victim.com/><http://victim.com <http://victim.com/>>
>>>>>> <http://victim.com <http://victim.com/>>
>>>>>> provider.
>>>>>> I register redirect uriattacker.com
>>>>>> <http://attacker.com/><http://attacker.com <http://attacker.com/>>
>>>>>> <http://attacker.com <http://attacker.com/>>.
>>>>>>
>>>>>> attacker.com <http://attacker.com/><http://attacker.com
>>>>>> <http://attacker.com/>> <http://attacker.com <http://attacker.com/>>.
>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>| Ping
>> Identity
>

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 17:14:18 +0000

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <[email-masked]> wrote:

> Is your concern clients that were registered using dynamic client registration?

yes

> 
> Otherwise the positive case is returning a response to a valid URL that belongs to a client that was registered explicitly by the resource owner

well AFAIK the resource owner doesn’t register clients…

> and the negative case is returning an error to that same URL.

the difference is the consent screen… in the positive case you need to approve an app.. for the error case no approval is needed,,,

> I fail to see the open redirect.

why?

---

From: Hans Zandbelt <[email-masked]>
Date: Wed, 03 Sep 2014 19:40:38 +0200

>> Is your concern clients that were registered using dynamic client registration?

I think your issue is then with the trust model of dynamic client 
registration; that is left out of scope of the dynreg spec (and the 
concept is not even part of the core spec), but unless you want 
everything to be open (which typically would not be the case), then it 
would involve approval somewhere in the process before the client is 
registered. Without dynamic client registration that approval is admin 
based or resource owner based, depending on use case.

> well AFAIK the resource owner doesn’t register clients…

roles can collapse in use cases especially when using dynamic client 
registration

>> I fail to see the open redirect.

because the client and thus the fixed URL are explicitly approved at 
some point

Hans.

---

From: John Bradley <[email-masked]>
Date: Wed, 3 Sep 2014 19:52:25 +0200

I agree that the error case where there is no UI is the problem, as it can be used inside a Iframe. 

However error responses are generally useful.   

OAuth core is silent on how redirect_uri are registered and if they are verified. 

Dynamic registration should warn about OAuth errors to redirect_uri from untrusted clients.  

For other registration methods we should update the RFC. 

John B. 

Sent from my iPhone

> On Sep 3, 2014, at 7:14 PM, Antonio Sanso <[email-masked]> wrote:
> 
>

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 17:54:02 +0000

Well,
I do not know if this is only dynamic registration...
let’s talk about real use cases, namely e.g. Google , Facebook , etc.. is that dynamic client registration? I do not know… :)

Said that what the other guys think?  :)
Would this deserve some “spec adjustment” ? I mean there is a reason if Google is by choice “violating” the spec right? (I assume to avoid open redirect…)
But other implementers do follow the spec hence they have this open redirector… and this is not nice IMHO...

On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <[email-masked]<mailto:[email-masked]>> wrote:

yes

I think your issue is then with the trust model of dynamic client registration; that is left out of scope of the dynreg spec (and the concept is not even part of the core spec), but unless you want everything to be open (which typically would not be the case), then it would involve approval somewhere in the process before the client is registered. Without dynamic client registration that approval is admin based or resource owner based, depending on use case.

roles can collapse in use cases especially when using dynamic client registration

why?

because the client and thus the fixed URL are explicitly approved at some point

Hans.

Hans.

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

*400.* That’s an error.

*Error: invalid_scope*

regards

antonio

John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Now let’s assume this.
I am registering a new client to thevictim.com<http://thevictim.com>
<http://victim.com/><http://victim.com <http://victim.com/>>
<http://victim.com <http://victim.com/>>
provider.
I register redirect uriattacker.com<http://uriattacker.com>
<http://attacker.com/><http://attacker.com <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected
back to
attacker.com<http://attacker.com> <http://attacker.com/><http://attacker.com
<http://attacker.com/>> <http://attacker.com <http://attacker.com/>>.
Namely I prepare a url that is in this form:

WDYT?

regards

antonio

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

--
Hans Zandbelt              | Sr. Technical Architect
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>| Ping
Identity

---

From: Hans Zandbelt <[email-masked]>
Date: Wed, 03 Sep 2014 20:42:37 +0200

fine, you're talking security considerations about untrusted clients; 
that's a different use case than the protocol flaw reason why Google 
would not do rfc6749 as written

Hans.

---

From: Phil Hunt <[email-masked]>
Date: Wed, 3 Sep 2014 12:23:41 -0700

I do not believe this is a flaw specific to 6749. The flaw if any is within HTTP itself (RFC7230). Covert redirect is a well known problem. There are extensive recommendations that prevent this covered in 6749 and 6819.

There is no protocol fix that OAuth can make since it is a trait or feature of HTTP.

Instead we’ve made security recommendations which are the appropriate response to this issue. Further we published 6819 that provides further guidance.

Phil

@independentid
www.independentid.com
[email-masked]

On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <[email-masked]> wrote:

> fine, you're talking security considerations about untrusted clients; that's a different use case than the protocol flaw reason why Google would not do rfc6749 as written
> 
> Hans.
>

---

From: Takahiko Kawasaki <[email-masked]>
Date: Thu, 4 Sep 2014 04:33:15 +0900

I think the point is that the registered redirect URI is evil, meaning that
the person who registered the client application is evil. I don't think the
spec can take any countermeasure against this case.

If the registered redirect URI is evil, the issue happens even in the case
where the scope is valid and consent from the end-user has been obtained.
That is, an attacker would prepare an HTML page at http://attacker.com
which says "Sorry, an error occurred. Please re-authorize this
application." and has a login form that mimics the login form of victim.com.

IMHO, all we can do is to educate people like "Be cautious when you are
requested to login again."

Best Regards,
Takahiko Kawasaki

2014-09-04 4:23 GMT+09:00 Phil Hunt <[email-masked]>:

> I do not believe this is a flaw specific to 6749. The flaw if any is
> within HTTP itself (RFC7230). Covert redirect is a well known problem.
> There are extensive recommendations that prevent this covered in 6749 and
> 6819.
>
> Instead we’ve made security recommendations which are the appropriate
> response to this issue. Further we published 6819 that provides further
> guidance.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
> that's a different use case than the protocol flaw reason why Google would
> not do rfc6749 as written
> >
> > Hans.
> >
> >>>> Otherwise the positive case is returning a response to a valid URL
> that belongs to a client that was registered explicitly by the resource
> owner
> >>>
> >>> the difference is the consent screen… in the positive case you need to
> approve an app.. for the error case no approval is needed,,,
> >>>
> >>>>

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 19:36:47 +0000

hi Phil,
can you point out the relative paragraph that covers this specific case in RFC6819?

---

From: Phil Hunt <[email-masked]>
Date: Wed, 3 Sep 2014 12:37:09 -0700

One improvement we made in dyn reg was the introduction of software statements. This can be used to force all mobile clients claiming to be a particular client to register the same redirect uri. 

This closes the door on a large number of cases. 

Phil

> On Sep 3, 2014, at 12:33, Takahiko Kawasaki <[email-masked]> wrote:
> 
> I think the point is that the registered redirect URI is evil, meaning that the person who registered the client application is evil. I don't think the spec can take any countermeasure against this case.
> 
> If the registered redirect URI is evil, the issue happens even in the case where the scope is valid and consent from the end-user has been obtained. That is, an attacker would prepare an HTML page at http://attacker.com which says "Sorry, an error occurred. Please re-authorize this application." and has a login form that mimics the login form of victim.com.
> 
> IMHO, all we can do is to educate people like "Be cautious when you are requested to login again."
> 
> Best Regards,
> Takahiko Kawasaki
> 
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 3 Sep 2014 12:47:56 -0700

in RFC6810, see section 3.5 and 4.1.5. 

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Wed, 3 Sep 2014 12:49:02 -0700

ooops,, that 6819 not 6810

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 19:52:40 +0000

hi Takahiko

On Sep 3, 2014, at 9:33 PM, Takahiko Kawasaki <[email-masked]<mailto:[email-masked]>> wrote:

If the registered redirect URI is evil, the issue happens even in the case where the scope is valid and consent from the end-user has been obtained.

well in this case the consent screen is there …. in the case I pointed out the redirect happens automatically

That is, an attacker would prepare an HTML page at http://attacker.com<http://attacker.com/> which says "Sorry, an error occurred. Please re-authorize this application." and has a login form that mimics the login form of victim.com<http://victim.com/>.

IMHO, all we can do is to educate people like "Be cautious when you are requested to login again.”

this is another case different from a normal open redirect IMHO

Best Regards,
Takahiko Kawasaki

2014-09-04 4:23 GMT+09:00 Phil Hunt <[email-masked]<mailto:[email-masked]>>:
I do not believe this is a flaw specific to 6749. The flaw if any is within HTTP itself (RFC7230). Covert redirect is a well known problem. There are extensive recommendations that prevent this covered in 6749 and 6819.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <[email-masked]<mailto:[email-masked]>> wrote:

>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>>
>>>>>>> <mailto:[email-masked]<mailto:[email-masked]>>
>>>>>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>>>>
>>>>>>>> <mailto:[email-masked]<mailto:[email-masked]>>
>>>>>>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>>>>>
>>>>>>>>>> I am registering a new client to thevictim.com<http://thevictim.com/>
>>>>>>>>>> <http://victim.com/><http://victim.com<http://victim.com/> <http://victim.com/>>
>>>>>>>>>> <http://victim.com<http://victim.com/> <http://victim.com/>>
>>>>>>>>>> provider.
>>>>>>>>>> I register redirect uriattacker.com<http://uriattacker.com/>
>>>>>>>>>> <http://attacker.com/><http://attacker.com<http://attacker.com/> <http://attacker.com/>>
>>>>>>>>>> <http://attacker.com<http://attacker.com/> <http://attacker.com/>>.
>>>>>>>>>>
>>>>>>>>>> attacker.com<http://attacker.com/> <http://attacker.com/><http://attacker.com<http://attacker.com/>
>>>>>>>>>> <http://attacker.com/>> <http://attacker.com<http://attacker.com/> <http://attacker.com/>>.
>>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]>>
>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>| Ping
>>>>>> Identity
>>>>
>>>> --

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 3 Sep 2014 19:58:58 +0000

thanks Phil for pointing the sections out but reading them I still think the case I brought up is still a different one :)

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 4 Sep 2014 05:26:03 +0000

hi again *,

after thinking a bit further IMHO an alternative for the untrusted clients can also be to always present the consent screen (at least once) before any redirect.
Namely all providers I have seen show the consent screen if all the request parameters are correct and if the user accepts the redirect happens.
If one of the parameter  (with the exclusion of the client id and redirect uri that are handled differently as for spec) is wrong though the redirect happens without the consent screen being shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso <[email-masked]<mailto:[email-masked]>> wrote:

Well,

yes

why?

Hans.

Hans.

Hans.

*400.* That’s an error.

*Error: invalid_scope*

regards

antonio

John B.

Now let’s assume this.

WDYT?

regards

antonio

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Sep 2014 01:57:04 -0400

I think that is probably reasonable advice.  

Presenting a dialog to the user also has the beneficial side effect of removing the original referrer from being seen by the party hosting the redirect_uri.  
It is allowing dynamic parameters to be passed in the referrer that is the largest security issue in my opinion.   That is how the AS might be used as a redirector to attack itself.

John B.

On Sep 4, 2014, at 1:26 AM, Antonio Sanso <[email-masked]> wrote:

> On Sep 3, 2014, at 7:54 PM, Antonio Sanso <[email-masked]> wrote:
> 
>> Well,
>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <[email-masked]> wrote:
>>

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 4 Sep 2014 07:04:11 +0000

I think this advice isn't a bad idea, though it's of course up to the AS what an "untrusted" client really is. In practice, this is something that was registered by a non-sysadmin type person, either a dynamically registered client or something available through self-service registration of some type. It's also reasonable that a client, even dynamically registered, would be considered "trusted" if enough time has passed and enough users have used it without things blowing up.

 -- Justin

On Sep 4, 2014, at 1:26 AM, Antonio Sanso <[email-masked]<mailto:[email-masked]>> wrote:

hi again *,

WDYT?

regards

antonio

Well,

yes

why?

Hans.

Hans.

Hans.

*400.* That’s an error.

*Error: invalid_scope*

regards

antonio

John B.

Now let’s assume this.

WDYT?

regards

antonio

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 04 Sep 2014 09:47:09 +0200

Classifying like this must also mean that consent should not be stored 
until the client is considered (admin) trusted, and admin policy would 
interfere with user policy.

IMHO the security consideration would apply only to dynamically 
registered clients where registration is unrestricted; any other form 
would involve some form of admin/user approval at registration time, 
overcoming the concern at authorization time: there's no auto-redirect 
flow possible for unknown clients.

Hans.

On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
> I think this advice isn't a bad idea, though it's of course up to the AS
> what an "untrusted" client really is. In practice, this is something
> that was registered by a non-sysadmin type person, either a dynamically
> registered client or something available through self-service
> registration of some type. It's also reasonable that a client, even
> dynamically registered, would be considered "trusted" if enough time has
> passed and enough users have used it without things blowing up.
>
>   -- Justin
>
>> after thinking a bit further IMHO an alternative for the untrusted
>> clients can also be to always present the consent screen (at least
>> once) before any redirect.
>> Namely all providers I have seen show the consent screen if all the
>> request parameters are correct and if the user accepts the redirect
>> happens.
>> If one of the parameter  (with the exclusion of the client id and
>> redirect uri that are handled differently as for spec) is wrong though
>> the redirect happens without the consent screen being shown..
>>
>> WDYT?
>>
>> regards
>>
>> antonio
>>
>>> let’s talk about real use cases, namely e.g. Google , Facebook ,
>>> etc.. is that dynamic client registration? I do not know… :)
>>>
>>> Would this deserve some “spec adjustment” ? I mean there is a reason
>>> if Google is by choice “violating” the spec right? (I assume to avoid
>>> open redirect…)
>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <[email-masked]
>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>>>> everything to be open (which typically would not be the case), then
>>>> it would involve approval somewhere in the process before the client
>>>> is registered. Without dynamic client registration that approval is
>>>> admin based or resource owner based, depending on use case.
>>>>
>>>>>> that belongs to a client that was registered explicitly by the
>>>>>> resource owner
>>>>>
>>>>> the difference is the consent screen… in the positive case you need
>>>>> to approve an app.. for the error case no approval is needed,,,
>>>>>
>>>>>>
>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt
>>>>>>> <[email-masked] <mailto:[email-masked]>
>>>>>>>>>>>> <http://thevictim.com/>
>>>>>>>>>>>> <http://victim.com/><http://victim.com <http://victim.com/>
>>>>>>>>>>>> <http://victim.com/>>
>>>>>>>>>>>> <http://victim.com <http://victim.com/> <http://victim.com/>>
>>>>>>>>>>>> provider.
>>>>>>>>>>>> I register redirect uriattacker.com <http://uriattacker.com/>
>>>>>>>>>>>> <http://attacker.com/><http://attacker.com
>>>>>>>>>>>> <http://attacker.com/> <http://attacker.com/>>
>>>>>>>>>>>> <http://attacker.com <http://attacker.com/>
>>>>>>>>>>>> <http://attacker.com/>>.
>>>>>>>>>>>>
>>>>>>>>>>>> attacker.com <http://attacker.com/>
>>>>>>>>>>>> <http://attacker.com/><http://attacker.com
>>>>>>>>>>>> <http://attacker.com/>
>>>>>>>>>>>> <http://attacker.com/>> <http://attacker.com
>>>>>>>>>>>> <http://attacker.com/> <http://attacker.com/>>.
>>>>>>>>>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>>>>>>>>>>>
>>>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>>>> <mailto:[email-masked]><mailto:[email-masked]>
>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>> <mailto:[email-masked]>| Ping
>>>>>>>> Identity
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> [email-masked] <mailto:[email-masked]> |
>>>>>> Ping Identity
>>>>>
>>>>
>>>> --

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 4 Sep 2014 07:50:37 +0000

Hi Hans,

I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers)

regards

antonio

On Sep 4, 2014, at 9:47 AM, Hans Zandbelt <[email-masked]> wrote:

> Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy.
> 
> IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients.
> 
> Hans.
>

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 04 Sep 2014 10:58:23 +0200

Agreed, I see you point about the big providers using exactly the 
unrestricted flow for which the trust model (by definition) is out of 
scope of the spec. This may be the reason for the implemented behavior 
indeed and a security consideration is a good idea for other 
deployments; there's not much more that can be done.

But Google also provides explicit registration for API clients (which is 
where my mind was):
https://developers.google.com/accounts/docs/OAuth2 (step 1)
and they would not need to deviate from the spec for that, nor would the 
spec need to change

Hans.

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 4 Sep 2014 11:44:37 +0000

hi Hans

On Sep 4, 2014, at 10:58 AM, Hans Zandbelt <[email-masked]> wrote:

> Agreed, I see you point about the big providers using exactly the unrestricted flow for which the trust model (by definition) is out of scope of the spec. This may be the reason for the implemented behavior indeed and a security consideration is a good idea for other deployments; there's not much more that can be done.
> 
> But Google also provides explicit registration for API clients (which is where my mind was):
> and they would not need to deviate from the spec for that, nor would the spec need to change

I do really struggle to understand your point here :) (at least the "nor would the spec need to change part" :)).

Probably I need to explain myself better.
Since Google is “safe” (due the “deviation” from the spec) I would take Google as example here (I could point out open redirector in the wild to proof my point but I will not do…)

Let’s start from scratch…

If Google would have something like http://www.google.com?goto=attacker.com this is without any doubt an open redirector… see  also OWASP 10 [0].

Now if Google would have implemented the spec rfc6749 verbatim something like 

https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

would have redirect to http://attacker.com.

So why this is not an open redirect ? :)

Now maybe we are saying the same thing but I felt like better explain my point :)

regards

antonio

[0] https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 04 Sep 2014 13:58:25 +0200

yes, you are right about the unrestricted client use case; I just got 
caught by the fact that you were talking about *unrestricted* client 
registration all the time (standards-based or not) which deserves extra 
caution whereas Google (and the spec) also provides *restricted* client 
registration the deviation or caution is not needed

Hans.

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 04 Sep 2014 14:09:25 +0200

Maybe just to clarify my point: where did the client_id in the example 
that you gave come from?

Hans.

On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
>>> scope of the spec. This may be the reason for the implemented
>>> behavior indeed and a security consideration is a good idea for other
>> I do really struggle to understand your point here :) (at least the
>> "nor would the spec need to change part" :)).
>>
>> Since Google is “safe” (due the “deviation” from the spec) I would
>> take Google as example here (I could point out open redirector in the
>> wild to proof my point but I will not do…)
>>
>> If Google would have something like
>> http://www.google.com?goto=attacker.com this is without any doubt an
>> open redirector… see  also OWASP 10 [0].
>>
>> [0]
>> https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards
>>
>>
>>
>>>
>>> Hans.
>>>
>>>> I really fail to see how this can be addressed at registration time
>>>> for cases where registration is unrestricted (namely all the big
>>>> Providers)
>>>>
>>>> regards
>>>>
>>>> antonio
>>>>
>>>>> Classifying like this must also mean that consent should not be
>>>>> stored until the client is considered (admin) trusted, and admin
>>>>> policy would interfere with user policy.
>>>>>
>>>>> registered clients where registration is unrestricted; any other
>>>>> form would involve some form of admin/user approval at registration
>>>>> time, overcoming the concern at authorization time: there's no
>>>>> auto-redirect flow possible for unknown clients.
>>>>>
>>>>> Hans.
>>>>>
>>>>>>>>>> <[email-masked]
>>>>>>>>>>>> as specified below in the positive case (namely when the
>>>>>>>>>>>> correct
>>>>>>>>>>>> scope
>>>>>>>>>>>>>>> I think that if anything it may be the registration step
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the
>>>>>>>>>>>>>> spec so
>>>>>>>>>>>>>> far….
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> antonio
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> John B.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <http://uriattacker.com/>
>>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the
>>>>>>>>>>>>>>>>> app
>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than
>>>>>>>>>>>>>>>>> redirect
>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>> <http://bill.burkecentral.com/>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>>>>> <mailto:[email-masked]>

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 4 Sep 2014 12:20:36 +0000

I registered via the Google Developers Console [0]  :)

[0] https://console.developers.google.com/project
On Sep 4, 2014, at 2:09 PM, Hans Zandbelt <[email-masked]<mailto:[email-masked]>> wrote:

Maybe just to clarify my point: where did the client_id in the example that you gave come from?

Hans.

Hans.

On Sep 4, 2014, at 10:58 AM, Hans Zandbelt
<[email-masked]<mailto:[email-masked]>> wrote:

But Google also provides explicit registration for API clients (which
is where my mind was):
https://developers.google.com/accounts/docs/OAuth2 (step 1)
and they would not need to deviate from the spec for that, nor would
the spec need to change

Now if Google would have implemented the spec rfc6749 verbatim
something like

Now maybe we are saying the same thing but I felt like better explain
my point :)

regards

antonio

[0]

Hans.

regards

antonio

On Sep 4, 2014, at 9:47 AM, Hans Zandbelt
<[email-masked]> wrote:

Hans.

On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
I think this advice isn't a bad idea, though it's of course up to
the AS
what an "untrusted" client really is. In practice, this is something
that was registered by a non-sysadmin type person, either a
dynamically
registered client or something available through self-service
registration of some type. It's also reasonable that a client, even
dynamically registered, would be considered "trusted" if enough
time has
passed and enough users have used it without things blowing up.

 -- Justin

On Sep 4, 2014, at 1:26 AM, Antonio Sanso <[email-masked]
<mailto:[email-masked]>> wrote:

hi again *,

redirect uri that are handled differently as for spec) is wrong
though

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso <[email-masked]
<mailto:[email-masked]>> wrote:

Well,

Said that what the other guys think?  :)
Would this deserve some “spec adjustment” ? I mean there is a
reason
if Google is by choice “violating” the spec right? (I assume to
avoid
open redirect…)
But other implementers do follow the spec hence they have this open
redirector… and this is not nice IMHO...

On Sep 3, 2014, at 7:40 PM, Hans Zandbelt
<[email-masked]
<mailto:[email-masked]>> wrote:

Is your concern clients that were registered using dynamic
client
registration?

yes

I think your issue is then with the trust model of dynamic client
registration; that is left out of scope of the dynreg spec (and
the
concept is not even part of the core spec), but unless you want
everything to be open (which typically would not be the case),
then
it would involve approval somewhere in the process before the
client
is registered. Without dynamic client registration that
approval is
admin based or resource owner based, depending on use case.

Otherwise the positive case is returning a response to a
valid URL
that belongs to a client that was registered explicitly by the
resource owner

roles can collapse in use cases especially when using dynamic
client
registration

the difference is the consent screen… in the positive case you
need
to approve an app.. for the error case no approval is needed,,,

why?

because the client and thus the fixed URL are explicitly
approved at
some point

Hans.

Hans.

Let me try and approach this from a different angle: why
would you
call it an open redirect when an invalid scope is provided and
call it
correct protocol behavior (hopefully) when a valid scope is
provided?

as specified below in the positive case (namely when the
correct
scope
is provided) the resource owner MUST approve the app via the
consent
screen (at least once).

Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <[email-masked]
<mailto:[email-masked]>
<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

The issue is that the AS may be allowing client
registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a
client
controls the redirect_uri it is registering.

(this is the first time :p) but I do disagree with you. It
would be
pretty unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely
returning
400 with the cause of the error..

*400.* That’s an error.

*Error: invalid_scope*

regards

antonio

John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <[email-masked]
<mailto:[email-masked]>
<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

I don't understand.  The redirect uri has to be valid in
order for a
redirect to happen.  The spec explicitly states this.

IMHO providers that strictly follow rfc6749 are vulnerable
to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or
mismatching
redirection URI, or if the client identifier is missing or
invalid,
the authorization server SHOULD inform the resource
owner of the
error and MUST NOT automatically redirect the
user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the
request
fails for reasons other than a missing or invalid
redirection URI,
the authorization server informs the client by adding the
following
parameters to the query component of the redirection URI
using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let’s assume this.
I am registering a new client to thevictim.com
<http://thevictim.com/>
<http://victim.com/><http://victim.com
<http://victim.com/>
<http://victim.com/>>
<http://victim.com <http://victim.com/>
<http://victim.com/>>
provider.
I register redirect uriattacker.com
<http://uriattacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/> <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>
<http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am
redirected
back to

and this is works as an open redirector.
Of course in the positive case if all the parameters are
fine this
doesn’t apply since the resource owner MUST approve the
app
via the
consent screen (at least once).

WDYT?

regards

antonio

--
Hans Zandbelt              | Sr. Technical Architect
[email-masked] <mailto:[email-masked]>|
Ping
Identity

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Sep 2014 14:22:03 +0200

Registration requiring a valid email address is not sufficient to stop a "bad" person from registering a client that appears to be perfectly legitimate but is later used as a redirect.

So it is a bit slippery to differentiate good from bad.

In general clearing the referrer and fragment from incoming requests is a good practice on redirects to prevent leakage of information across the redirect.

The other concern is using the redirect as part of a phishing attack to make the target site look more legitimate.
That is a more complicated problem unless you validate every client by looking at them to make sure they are not bad in some way.

John B.

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 4 Sep 2014 12:28:12 +0000

> Registration requiring a valid email address is not sufficient to stop a "bad" person from registering a client that appears to be perfectly legitimate but is later used as a redirect.

totally agree!

> In general clearing the referrer and fragment from incoming requests is a good practice on redirects to prevent leakage of information across the redirect.

+1

> That is a more complicated problem unless you validate every client by looking at them to make sure they are not bad in some way.

and here it comes the "error 400"  or the "always show the consent screen” approach

regards

antonio

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 04 Sep 2014 14:29:10 +0200

exactly, but my point would be that the attacker needs to have an 
relationship/account with the OP; this is where the approval is and I 
agree with Antonio/you that that is tricky for consumer ASs and deserves 
a warning

Hans.

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Sep 2014 14:44:04 +0200

In a enterprise case likely there is some trusted relationship.

In the Web 2.0 API economy case there is a tension between providers wanting the maximum number of users and validating the developer registering the client.
Often having a email someplace is sufficient to register a client.  That is not a particularly high bar if you are someone intent on hacking or phishing.

Each AS is going to have some different policy regarding the vetting of clients/developers.

So AS need to take appropriate precautions based on there policies.

John B.
On Sep 4, 2014, at 2:29 PM, Hans Zandbelt <[email-masked]> wrote:

> exactly, but my point would be that the attacker needs to have an relationship/account with the OP; this is where the approval is and I agree with Antonio/you that that is tricky for consumer ASs and deserves a warning
> 
> Hans.
>

---

From: Bill Burke <[email-masked]>
Date: Thu, 04 Sep 2014 08:52:32 -0400

FWIW, Antonio convinced me and I'm going to change this in our IDM 
project.  Thanks Antonio.  What convinced me was that the user is 
probably expecting a login screen.  Since there is this expectation, it 
might make it a little easier for the attacker to convince the user that 
a spoofed login screen is real.  I know this issue can only happen with 
unrestricted registration, but, IMO, this proposed change doesn't really 
have much of an effect on usability and is even backward compatible with 
the current RFC.

Wouldn't it better though to never do a redirect on an invalid request 
and just display an error page?

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 4 Sep 2014 13:01:09 +0000

hi Bill 
On Sep 4, 2014, at 2:52 PM, Bill Burke <[email-masked]> wrote:

> FWIW, Antonio convinced me and I'm going to change this in our IDM project.  Thanks Antonio.  What convinced me was that the user is probably expecting a login screen.  Since there is this expectation, it might make it a little easier for the attacker to convince the user that a spoofed login screen is real.  I know this issue can only happen with unrestricted registration, but, IMO, this proposed change doesn't really have much of an effect on usability and is even backward compatible with the current RFC.
> 
> Wouldn't it better though to never do a redirect on an invalid request and just display an error page?

thanks for sharing your thoughts :). Display an error 400 is what Google does :)

regards

antonio

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 04 Sep 2014 15:15:17 +0200

I am convinced about the issue in the use case Antonio provided but I 
hope not to close the door on returning errors to known and trusted 
clients. Not sure anymore if that's possible though because the 
distinction can't be "registered"...

Hans.

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 4 Sep 2014 13:32:53 +0000

hi Hans

On Sep 4, 2014, at 3:15 PM, Hans Zandbelt <[email-masked]> wrote:

> I am convinced about the issue in the use case Antonio provided but I hope not to close the door on returning errors to known and trusted clients. Not sure anymore if that's possible though because the distinction can't be "registered"…

an alternative is to show always the consent screen (at least once if the client id/redirect_uri is valid and accept the app) even if the scope or any other parameter is not valid before to redirect to the redirect uri.

regards

antonio

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 4 Sep 2014 13:42:30 +0000

The distinction can be made, and it's AS policy. Sometimes (like in our case) the AS distinguishes between client registered by an administrator vs. an end user vs. something dynamic (no user involved). And in the latter cases, the AS can still figure out how long something's been registered and how it's been used in the past (no user complaints across a large number of users) to make something more or less trusted over time. But it's still up to the AS, and it would be helpful to have some guidance on this in the security considerations. We might want to add it to the DynReg spec because that exacerbates the issue a bit.

 -- Justin

On Sep 4, 2014, at 9:15 AM, Hans Zandbelt <[email-masked]> wrote:

> I am convinced about the issue in the use case Antonio provided but I hope not to close the door on returning errors to known and trusted clients. Not sure anymore if that's possible though because the distinction can't be "registered"...
> 
> Hans.
>

---

From: Antonio Sanso <[email-masked]>
Date: Mon, 15 Sep 2014 19:10:20 +0000

hi *,

my understanding is that there is a rough consensus that if an OAuth Provider follows rfc6749 verbatim will end up having an open redirector.
My next question would be now, is there anything we can do to raise some awareness about this issue?

regards

antonio

---

From: Phil Hunt <[email-masked]>
Date: Mon, 15 Sep 2014 12:41:17 -0700

Simply not true.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Antonio Sanso <[email-masked]>
Date: Mon, 15 Sep 2014 19:50:16 +0000

On Sep 15, 2014, at 9:41 PM, Phil Hunt <[email-masked]> wrote:
hi Phil

> Simply not true.

why do you think so ?

regards

antonio

---

From: John Bradley <[email-masked]>
Date: Mon, 15 Sep 2014 17:00:54 -0300

There may be a problem with semantics in this discussion. 

There is a redirect performed by athe authorization endpoint to a fixed uri that is pre registered with the authorization server without user prompting. 

That probably doesn't fit the strict definition of a open redirector. 

It may however create similar security issues in situations with relatively open registration of clients. 

The largest issues are that the browser might leak information across the redirect in the fragment or referrer.  That has been used in attacks against Facebook in the past. 

This is no where near the end of the world,  however we need to look at the security considerations and see if we can provide better advice to implementors.  In some cases returning a error to the browser may be best.  

I don't think we need to go so far as not returning any error to the client under any circumstance. 

John B. 

Sent from my iPhone

> On Sep 15, 2014, at 4:41 PM, Phil Hunt <[email-masked]> wrote:
> 
> Simply not true.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [email-masked]
> 
> 
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 15 Sep 2014 13:43:16 -0700

If a server accepts a URL from a client to be used as a redirect that the server doesn’t recognize or is not registered, that is an open redirect.

The specification does no allow open-redirects, it considers this a mis-configuration.

Take a look at sections 3.1.2.2 and 10.15 of RFC6749.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 15 Sep 2014 17:48:22 -0300

Yes, but a redirect to a registered redirect_uri may still leak information in the referrer or fragment. 

That is the point Antonio is trying to make. 

It is not a open redirect but might be used as part of an attack on someone. 

John B. 

Sent from my iPhone

> On Sep 15, 2014, at 5:43 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Antonio Sanso <[email-masked]>
Date: Mon, 15 Sep 2014 20:52:24 +0000

The problem is that a malicious client can register a malicious redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as previously discussed)

regards

antonio

---

From: Phil Hunt <[email-masked]>
Date: Mon, 15 Sep 2014 14:08:17 -0700

I’m not sure I understand why this is an OAuth protocol problem?

If you are starting with a false client with a false registration, everything down stream is likely invalid. 

This seems like a registration curation (whitelisting) problem.

This is a bit like saying, how can I prove that the application on this jail-broken phone is legitimate?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Antonio Sanso <[email-masked]>
Date: Mon, 15 Sep 2014 21:11:56 +0000

> If you are starting with a false client with a false registration, everything down stream is likely invalid. 

registration is not false. But the client can be a malicious one…. 

> This seems like a registration curation (whitelisting) problem.

there is not way a whitelist can cover all the malicious uris..

regards

antonio

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 15 Sep 2014 21:15:32 +0000

As we discussed before: This isn't really an open redirection in the classical sense since nothing gets leaked and the URI is tied back to a known (albeit malicious) client registration. And I thought the clear solution was to have an AS not automatically redirect to an untrusted client in error conditions, where "untrusted" is defined by the AS with guidance. If anything this is a security considerations addendum.

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Mon, 15 Sep 2014 14:21:52 -0700

So, let’s say you have a client that has “obtained” a client Id from a legit registered client.  How does the malicious client exploit the previously registered URL if the server only redirects to that URL?

Are you referring to the case Nat Sakimura previously raised where mobile app stores do not enforce custom URL registrations?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 15 Sep 2014 18:56:32 -0300

Something might get leaked by the browser, the fragment may be leaked by the browser if the redirect URI doesn't contain a fragment in some browsers.

A simple security consideration might be to add a fragment to the redirect_uri in the error case.

The other way that information may leak is via the referrer.   If there is only one redirect by the AS the URI that was sent to the AS including all the parameters would still be available to the target.
A simple fix is to redirect to a intermediate page before redirecting to the registered client, this clears the referrer.

It is true that nothing is leaked in the redirect_uri itself but there are side channels in the browser that need to be considered.

The fixes are quite simple implementation issues and don't break anything.

Yes if the client is trusted then this is probably unnecessary but wouldn't hurt anything.

John B.

PS for OAuth this would really only be exploitable if exact redirect_uri matching is not happening.   

As I am a inherently bad person, I could hypothetically use this to attack a AS that is doing domain level pattern matching of redirect URI and has a public client in the same domain as the AS.

I should also note that domains using pattern matching are also vulnerable if they allow other sorts of user hosted content like blog posts that pull in images and leak the referrer.

So we do probably need to provide some advice.

John B.

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 16 Sep 2014 09:01:23 +0000

hi Phil.
On Sep 15, 2014, at 11:21 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

These are the steps:

- the malicious client can registers a malicious url (attacker.com<http://attacker.com>)
- the malicious client builds a malicious request to the AS (victim.com<http://victim.com>) that looks like http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

as per https://tools.ietf.org/html/rfc6749#section-4.1.2.1 the user is redirected to http://attacker.com (since the wrong parameter is the scope )

regards

antonio

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]

regards

antonio

Phil

@independentid
www.independentid.com
[email-masked]

regards

antonio

Phil

@independentid
www.independentid.com
[email-masked]

John B.

Sent from my iPhone

Simply not true.

Phil

@independentid
www.independentid.com
[email-masked]

hi *,

regards

antonio

Hans.

regards

antonio

regards

antonio

Hans.

-- Justin

hi again *,

WDYT?

regards

antonio

Well,

yes

why?

Hans.

Hans.

as specified below in the positive case (namely when the correct
scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).

Hans.

I think that if anything it may be the registration step that
needs
the security consideration.

*400.* That’s an error.

*Error: invalid_scope*

said that I hope you all agree this is an issue in the spec so
far….

regards

antonio

John B.

Now let’s assume this.

and this is works as an open redirector.
Of course in the positive case if all the parameters are
fine this
doesn’t apply since the resource owner MUST approve the app
via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect
to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 16 Sep 2014 09:08:40 +0000

Hi John,

agree that there are at two different things (as you pointed out below) where we could spend some word and provide some advice.

To summarize:

- one is the 'open redirect’ issue (net of semantic :), pointed by me,  where nothing is leaked 
- one is the leakage, pointed by John

Those two scenarios are different and might deserve to be discussed independently… :)

> I should also note that domains using pattern matching are also vulnerable if they allow other sorts of user hosted content like blog posts that pull in images and leak the referrer.

if somebody is curios about some real world attack this is one I performed to Facebook that does exactly what John describes here http://intothesymmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html

regards

antonio

---

From: Bill Burke <[email-masked]>
Date: Tue, 16 Sep 2014 10:40:12 -0400

I'll reiterate what convinced me if it helps.

The danger was a matter of expectations.  In Antonio's scenario, the 
user is more likely to be expecting a login screen and thus more likely 
to be fooled by a login-screen spoof.  Antonio's suggested changes don't 
break any compatibility either, it just requires the AS to display an 
error page on *any* parameter error instead of redirecting back. 
Something the spec already requires for a bad client id.