in RFC6810, see section 3.5 and 4.1.5. Phil
@independentid www.independentid.com phil.h...@oracle.com On Sep 3, 2014, at 12:36 PM, Antonio Sanso <asa...@adobe.com> wrote: > hi Phil, > can you point out the relative paragraph that covers this specific case in > RFC6819? > On Sep 3, 2014, at 9:23 PM, Phil Hunt <phil.h...@oracle.com> wrote: > >> 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 >> phil.h...@oracle.com >> >> >> >> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <hzandb...@pingidentity.com> >> 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 <asa...@adobe.com> wrote: >>>>> >>>>> >>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandb...@pingidentity.com> >>>>>> 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 <hzandb...@pingidentity.com >>>>>>> <mailto:hzandb...@pingidentity.com>> 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 <ve7...@ve7jtb.com >>>>>>>>> <mailto:ve7...@ve7jtb.com> >>>>>>>>> <mailto:ve7...@ve7jtb.com>> 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 <bbu...@redhat.com >>>>>>>>>> <mailto:bbu...@redhat.com> >>>>>>>>>> <mailto:bbu...@redhat.com>> 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 >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Bill Burke >>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>| Ping >>>>>>>> Identity >>>>>> >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandb...@pingidentity.com | Ping Identity >>>>> >>> >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandb...@pingidentity.com | Ping Identity >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
