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
