Re: [OAUTH-WG] open redirect in rfc6749

[Phil Hunt <[e-mail]>]

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 <[e-mail]> 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
> 
> 
> 2014-09-04 4:23 GMT+09:00 Phil Hunt <[e-mail]>:
>> 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
>> [e-mail]
>> 
>> 
>> 
>> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <[e-mail]> 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.
>> >
>> > On 9/3/14, 7:52 PM, John Bradley wrote:
>> >> 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 <[e-mail]> wrote:
>> >>>
>> >>>
>> >>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <[e-mail]> 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?
>> >>>
>> >>>>
>> >>>> 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]>> 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]>> 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]>> 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://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/>>.
>> >>>>>>>>>>
>> >>>>>>>>>> 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:
>> >>>>>>>>>>
>> >>>>>>>>>> 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]
>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>> Bill Burke
>> >>>>>>>>> JBoss, a division of Red Hat
>> >>>>>>>>> http://bill.burkecentral.com
>> >>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> OAuth mailing list
>> >>>>>>>>> [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
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> OAuth mailing list
>> >>>>>>> [e-mail] <mailto:[e-mail]>
>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>>>
>> >>>>>> --
>> >>>>>> Hans Zandbelt              | Sr. Technical Architect
>> >>>>>> [e-mail] <mailto:[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
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>