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 <ve7...@ve7jtb.com> 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. <jric...@mitre.org> 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 <asa...@adobe.com> 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 <phil.h...@oracle.com> 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 >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> On Sep 15, 2014, at 1:00 PM, John Bradley <ve7...@ve7jtb.com> 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 <phil.h...@oracle.com> wrote: >>>>>> >>>>>> Simply not true. >>>>>> >>>>>> Phil >>>>>> >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.h...@oracle.com >>>>>> >>>>>> >>>>>> >>>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso <asa...@adobe.com> 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 <hzandb...@pingidentity.com> >>>>>>>> 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 <bbu...@redhat.com> 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 >>>>>>>>>>>> <hzandb...@pingidentity.com> 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 <asa...@adobe.com >>>>>>>>>>>>> <mailto:asa...@adobe.com>> 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 <asa...@adobe.com >>>>>>>>>>>>>> <mailto:asa...@adobe.com>> 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 >>>>>>>>>>>>>>> <hzandb...@pingidentity.com >>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>>> <hzandb...@pingidentity.com >>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>> 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 >>>>>>>>>>>>>>>>>>> <hzandb...@pingidentity.com >>>>>>>>>>>>>>>>>>> <mailto: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> >>>>>>>>>>>>>>>>>>>>> <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> >>>>>>>>>>>>>>>>>>>>>> <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://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 >>>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>>>>>>>>> <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> >>>>>>>>>>>>>>>>>>>>> <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>>> hzandb...@pingidentity.com >>>>>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com> >>>>>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>| Ping >>>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>> hzandb...@pingidentity.com >>>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com> | >>>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> hzandb...@pingidentity.com >>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>| Ping >>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 | Ping Identity >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >> >> _______________________________________________ >> 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
