ooops,, that 6819 not 6810 Phil
@independentid www.independentid.com phil.h...@oracle.com On Sep 3, 2014, at 12:47 PM, Phil Hunt <phil.h...@oracle.com> wrote: > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
