Re: [OAUTH-WG] open redirect in rfc6749

[John Bradley <[e-mail]>]

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.


On Sep 4, 2014, at 2:09 PM, Hans Zandbelt <[e-mail]> wrote:

> 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:
>> 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.
>> 
>> On 9/4/14, 1:44 PM, Antonio Sanso wrote:
>>> hi Hans
>>> 
>>> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt
>>> <[e-mail]> 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):
>>>> 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
>>> 
>>> 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
>>> 
>>> 
>>> 
>>>> 
>>>> Hans.
>>>> 
>>>> On 9/4/14, 9:50 AM, Antonio Sanso wrote:
>>>>> 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
>>>>> <[e-mail]> 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.
>>>>>> 
>>>>>> 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 <[e-mail]
>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>>> 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 <[e-mail]
>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>> 
>>>>>>>>> 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
>>>>>>>>> <[e-mail]
>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>> 
>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
>>>>>>>>>>> <[e-mail]
>>>>>>>>>>> <mailto:[e-mail]>> 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
>>>>>>>>>>> 
>>>>>>>>>>> well AFAIK the resource owner doesn’t register clients…
>>>>>>>>>> 
>>>>>>>>>> roles can collapse in use cases especially when using dynamic
>>>>>>>>>> client
>>>>>>>>>> registration
>>>>>>>>>> 
>>>>>>>>>>>> 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?
>>>>>>>>>> 
>>>>>>>>>> because the client and thus the fixed URL are explicitly
>>>>>>>>>> approved at
>>>>>>>>>> some point
>>>>>>>>>> 
>>>>>>>>>> Hans.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Hans.
>>>>>>>>>>>> 
>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt
>>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>> <mailto:[e-mail]>> 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 <[e-mail]
>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> (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 <[e-mail]
>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>>>> 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, 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
>>>>>>>>>>>>>>>>>> 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/>>.
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>>> <mailto:[e-mail]><mailto:[e-mail]>
>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>> <mailto:[e-mail]>| Ping
>>>>>>>>>>>>>> Identity
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>>>> [e-mail] <mailto:[e-mail]> |
>>>>>>>>>>>> Ping Identity
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>> [e-mail] <mailto:[e-mail]>|
>>>>>>>>>> Ping
>>>>>>>>>> Identity
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>> [e-mail] | Ping Identity
>>>>> 
>>>> 
>>>> --
>>>> Hans Zandbelt              | Sr. Technical Architect
>>>> [e-mail] | Ping Identity
>>> 
>> 
> 
> -- 
> Hans Zandbelt              | Sr. Technical Architect
> [e-mail] | Ping Identity
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth