thanks Phil for pointing the sections out but reading them I still think the case I brought up is still a different one :) On Sep 3, 2014, at 9:49 PM, Phil Hunt <[email protected]> wrote:
> ooops,, that 6819 not 6810 > > Phil > > @independentid > www.independentid.com > [email protected] > > > > On Sep 3, 2014, at 12:47 PM, Phil Hunt <[email protected]> wrote: > >> in RFC6810, see section 3.5 and 4.1.5. >> >> Phil >> >> @independentid >> www.independentid.com >> [email protected] >> >> >> >> On Sep 3, 2014, at 12:36 PM, Antonio Sanso <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> >>>> >>>> >>>> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <[email protected]> >>>> 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 <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <[email protected]> >>>>>>>> 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 <[email protected] >>>>>>>>> <mailto:[email protected]>> 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 protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>> <mailto:[email protected]>> 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 >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> [email protected] <mailto:[email protected]><mailto:[email protected]> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> [email protected] <mailto:[email protected]>| Ping >>>>>>>>>> Identity >>>>>>>> >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> [email protected] | Ping Identity >>>>>>> >>>>> >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> [email protected] | Ping Identity >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
