just sharing with you how this very “issue” has been lately used in a real life attack:
http://andrisatteka.blogspot.ch/2014/09/how-microsoft-is-giving-your-data-to.html regards antonio On Oct 9, 2014, at 3:34 PM, Antonio Sanso <[email protected]> wrote: > hi again *, > > apologies to bother you again with this :), just wasn’t really clear to me > if this is considered like ‘solved’ (namely the discussion is over, no action > to be taken) or we need still to discuss about this topic in order to reach > some sort of consensus :) > > regards > > antonio > > On Sep 16, 2014, at 4:40 PM, Bill Burke <[email protected]> wrote: > >> I'll reiterate what convinced me if it helps. >> >> The danger was a matter of expectations. In Antonio's scenario, the user is >> more likely to be expecting a login screen and thus more likely to be fooled >> by a login-screen spoof. Antonio's suggested changes don't break any >> compatibility either, it just requires the AS to display an error page on >> *any* parameter error instead of redirecting back. Something the spec >> already requires for a bad client id. >> >> On 9/16/2014 5:08 AM, Antonio Sanso wrote: >>> 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 >>> >> >> -- >> 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
