Hi John, agree that there are at two different things (as you pointed out below) where we could spend some word and provide some advice.
To summarize: - one is the 'open redirect’ issue (net of semantic :), pointed by me, where nothing is leaked - one is the leakage, pointed by John Those two scenarios are different and might deserve to be discussed independently… :) On Sep 15, 2014, at 11:56 PM, John Bradley <[email protected]> wrote: > Something might get leaked by the browser, the fragment may be leaked by the > browser if the redirect URI doesn't contain a fragment in some browsers. > > A simple security consideration might be to add a fragment to the > redirect_uri in the error case. > > The other way that information may leak is via the referrer. If there is > only one redirect by the AS the URI that was sent to the AS including all the > parameters would still be available to the target. > A simple fix is to redirect to a intermediate page before redirecting to the > registered client, this clears the referrer. > > It is true that nothing is leaked in the redirect_uri itself but there are > side channels in the browser that need to be considered. > > The fixes are quite simple implementation issues and don't break anything. > > Yes if the client is trusted then this is probably unnecessary but wouldn't > hurt anything. > > John B. > > PS for OAuth this would really only be exploitable if exact redirect_uri > matching is not happening. > > As I am a inherently bad person, I could hypothetically use this to attack a > AS that is doing domain level pattern matching of redirect URI and has a > public client in the same domain as the AS. > > I should also note that domains using pattern matching are also vulnerable if > they allow other sorts of user hosted content like blog posts that pull in > images and leak the referrer. if somebody is curios about some real world attack this is one I performed to Facebook that does exactly what John describes here http://intothesymmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html regards antonio > > So we do probably need to provide some advice. > > John B. > > On Sep 15, 2014, at 6:15 PM, Richer, Justin P. <[email protected]> wrote: > >> As we discussed before: This isn't really an open redirection in the >> classical sense since nothing gets leaked and the URI is tied back to a >> known (albeit malicious) client registration. And I thought the clear >> solution was to have an AS not automatically redirect to an untrusted client >> in error conditions, where "untrusted" is defined by the AS with guidance. >> If anything this is a security considerations addendum. >> >> -- Justin >> >> On Sep 15, 2014, at 4:52 PM, Antonio Sanso <[email protected]> wrote: >> >>> The problem is that a malicious client can register a malicious redirect >>> uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest >>> (as previously discussed) >>> >>> regards >>> >>> antonio >>> >>> On Sep 15, 2014, at 10:43 PM, Phil Hunt <[email protected]> wrote: >>> >>>> If a server accepts a URL from a client to be used as a redirect that the >>>> server doesn’t recognize or is not registered, that is an open redirect. >>>> >>>> The specification does no allow open-redirects, it considers this a >>>> mis-configuration. >>>> >>>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> [email protected] >>>> >>>> >>>> >>>> On Sep 15, 2014, at 1:00 PM, John Bradley <[email protected]> wrote: >>>> >>>>> There may be a problem with semantics in this discussion. >>>>> >>>>> There is a redirect performed by athe authorization endpoint to a fixed >>>>> uri that is pre registered with the authorization server without user >>>>> prompting. >>>>> >>>>> That probably doesn't fit the strict definition of a open redirector. >>>>> >>>>> It may however create similar security issues in situations with >>>>> relatively open registration of clients. >>>>> >>>>> The largest issues are that the browser might leak information across the >>>>> redirect in the fragment or referrer. That has been used in attacks >>>>> against Facebook in the past. >>>>> >>>>> This is no where near the end of the world, however we need to look at >>>>> the security considerations and see if we can provide better advice to >>>>> implementors. In some cases returning a error to the browser may be >>>>> best. >>>>> >>>>> I don't think we need to go so far as not returning any error to the >>>>> client under any circumstance. >>>>> >>>>> John B. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt <[email protected]> wrote: >>>>>> >>>>>> Simply not true. >>>>>> >>>>>> Phil >>>>>> >>>>>> @independentid >>>>>> www.independentid.com >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso <[email protected]> wrote: >>>>>>> >>>>>>> hi *, >>>>>>> >>>>>>> my understanding is that there is a rough consensus that if an OAuth >>>>>>> Provider follows rfc6749 verbatim will end up having an open redirector. >>>>>>> My next question would be now, is there anything we can do to raise >>>>>>> some awareness about this issue? >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> antonio >>>>>>> >>>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I am convinced about the issue in the use case Antonio provided but I >>>>>>>> hope not to close the door on returning errors to known and trusted >>>>>>>> clients. Not sure anymore if that's possible though because the >>>>>>>> distinction can't be "registered"... >>>>>>>> >>>>>>>> Hans. >>>>>>>> >>>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>>> hi Bill >>>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM >>>>>>>>>> project. Thanks Antonio. What convinced me was that the user is >>>>>>>>>> probably expecting a login screen. Since there is this expectation, >>>>>>>>>> it might make it a little easier for the attacker to convince the >>>>>>>>>> user that a spoofed login screen is real. I know this issue can >>>>>>>>>> only happen with unrestricted registration, but, IMO, this proposed >>>>>>>>>> change doesn't really have much of an effect on usability and is >>>>>>>>>> even backward compatible with the current RFC. >>>>>>>>>> >>>>>>>>>> Wouldn't it better though to never do a redirect on an invalid >>>>>>>>>> request and just display an error page? >>>>>>>>> >>>>>>>>> thanks for sharing your thoughts :). Display an error 400 is what >>>>>>>>> Google does :) >>>>>>>>> >>>>>>>>> regards >>>>>>>>> >>>>>>>>> antonio >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>>> Hi Hans, >>>>>>>>>>> >>>>>>>>>>> I really fail to see how this can be addressed at registration time >>>>>>>>>>> for cases where registration is unrestricted (namely all the big >>>>>>>>>>> Providers) >>>>>>>>>>> >>>>>>>>>>> regards >>>>>>>>>>> >>>>>>>>>>> antonio >>>>>>>>>>> >>>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Classifying like this must also mean that consent should not be >>>>>>>>>>>> stored until the client is considered (admin) trusted, and admin >>>>>>>>>>>> policy would interfere with user policy. >>>>>>>>>>>> >>>>>>>>>>>> IMHO the security consideration would apply only to dynamically >>>>>>>>>>>> registered clients where registration is unrestricted; any other >>>>>>>>>>>> form would involve some form of admin/user approval at >>>>>>>>>>>> registration time, overcoming the concern at authorization time: >>>>>>>>>>>> there's no auto-redirect flow possible for unknown clients. >>>>>>>>>>>> >>>>>>>>>>>> Hans. >>>>>>>>>>>> >>>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>>> I think this advice isn't a bad idea, though it's of course up to >>>>>>>>>>>>> the AS >>>>>>>>>>>>> what an "untrusted" client really is. In practice, this is >>>>>>>>>>>>> something >>>>>>>>>>>>> that was registered by a non-sysadmin type person, either a >>>>>>>>>>>>> dynamically >>>>>>>>>>>>> registered client or something available through self-service >>>>>>>>>>>>> registration of some type. It's also reasonable that a client, >>>>>>>>>>>>> even >>>>>>>>>>>>> dynamically registered, would be considered "trusted" if enough >>>>>>>>>>>>> time has >>>>>>>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Justin >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> hi again *, >>>>>>>>>>>>>> >>>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the >>>>>>>>>>>>>> untrusted >>>>>>>>>>>>>> clients can also be to always present the consent screen (at >>>>>>>>>>>>>> least >>>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>>> Namely all providers I have seen show the consent screen if all >>>>>>>>>>>>>> the >>>>>>>>>>>>>> request parameters are correct and if the user accepts the >>>>>>>>>>>>>> redirect >>>>>>>>>>>>>> happens. >>>>>>>>>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>>>>>>>>> redirect uri that are handled differently as for spec) is wrong >>>>>>>>>>>>>> though >>>>>>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>>>>> >>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>> >>>>>>>>>>>>>> regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Well, >>>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know… :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>>> Would this deserve some “spec adjustment” ? I mean there is a >>>>>>>>>>>>>>> reason >>>>>>>>>>>>>>> if Google is by choice “violating” the spec right? (I assume to >>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>> open redirect…) >>>>>>>>>>>>>>> But other implementers do follow the spec hence they have this >>>>>>>>>>>>>>> open >>>>>>>>>>>>>>> redirector… and this is not nice IMHO... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is your concern clients that were registered using dynamic >>>>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think your issue is then with the trust model of dynamic >>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec >>>>>>>>>>>>>>>> (and the >>>>>>>>>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>>>>>>>>> everything to be open (which typically would not be the case), >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> it would involve approval somewhere in the process before the >>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>> is registered. Without dynamic client registration that >>>>>>>>>>>>>>>> approval is >>>>>>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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… >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> roles can collapse in use cases especially when using dynamic >>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly >>>>>>>>>>>>>>>> approved at >>>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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]> >>>>>>>>>>>>>>>>>>> <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]> >>>>>>>>>>>>>>>>>>>>> <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]> >>>>>>>>>>>>>>>>>>>>>> <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://thevictim.com/> >>>>>>>>>>>>>>>>>>>>>>>> <http://victim.com/><http://victim.com >>>>>>>>>>>>>>>>>>>>>>>> <http://victim.com/> >>>>>>>>>>>>>>>>>>>>>>>> <http://victim.com/>> >>>>>>>>>>>>>>>>>>>>>>>> <http://victim.com <http://victim.com/> >>>>>>>>>>>>>>>>>>>>>>>> <http://victim.com/>> >>>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>>>> <http://uriattacker.com/> >>>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com/><http://attacker.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/>> <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] <mailto:[email protected]> >>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>>>> <http://bill.burkecentral.com/> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> 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]> >>>>>>>>>>>>>>>>>>>>>> <mailto:[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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>>>>> <mailto:[email protected]>| Ping >>>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> <mailto:[email protected]> | >>>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>| Ping >>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> [email protected] | Ping Identity >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
