Re: [OAUTH-WG] open redirect in rfc6749

[Sergey Beryozkin <[e-mail]>]

Hi

I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redirect URIs, intentionally or unintentionally, then does it imply
there's serious a weakness present somewhere else, in the
registration process for example ? Should the client registrations be
validated ?

Sergey
>
> On 16/09/14 08:52, Hans Zandbelt wrote:
>> +1, Antonio and John convinced me that this is not limited to a
>> registration curation problem although that is where the problems starts
>> as Phil points out (and as much as I'd like it to stay there).
>>
>> There are and will be consumer OPs (like Google) that have no means to
>> do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security
>> consideration for OPs that have no policy in place to allow only trusted
>> clients to register would be a good thing.
>>
>> The advice for those OPs would be to not send errors back to untrusted
>> clients or do it only after explicit user interaction.
>>
>> Hans.
>>
>> On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote:
>>> I think a security considerations addendum makes sense.
>>>
>>> regards,
>>> Torsten.
>>>
>>>
>>> -------- Ursprüngliche Nachricht --------
>>> Von: "Richer, Justin P."
>>> Datum:15.09.2014 23:15 (GMT+01:00)
>>> An: Antonio Sanso
>>> Cc: [e-mail]
>>> Betreff: Re: [OAUTH-WG] open redirect in rfc6749
>>>
>>> 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 <[e-mail]> 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 <[e-mail]> 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
>>>  >> [e-mail]
>>>  >>
>>>  >>
>>>  >>
>>>  >> On Sep 15, 2014, at 1:00 PM, John Bradley <[e-mail]> 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 <[e-mail]>
>>> wrote:
>>>  >>>>
>>>  >>>> Simply not true.
>>>  >>>>
>>>  >>>> Phil
>>>  >>>>
>>>  >>>> @independentid
>>>  >>>> www.independentid.com
>>>  >>>> [e-mail]
>>>  >>>>
>>>  >>>>
>>>  >>>>
>>>  >>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso <[e-mail]>
>>> 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
>>> <[e-mail]> 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 <[e-mail]>
>>> 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
>>> <[e-mail]> 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 <[e-mail]
>>>  >>>>>>>>>>> <mailto:[e-mail]>> 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
>>> <[e-mail]
>>>  >>>>>>>>>>>> <mailto:[e-mail]>> 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
>>> <[e-mail]
>>>  >>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>  >>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote:
>>>  >>>>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
>>>  >>>>>>>>>>>>>>> <[e-mail]
>>> <mailto:[e-mail]>> 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
>>>  >>>>>>>>>>>>>>>>> <[e-mail]
>>> <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>> <mailto:[e-mail]>> 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
>>> <[e-mail]
>>>  >>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>> 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
>>> <[e-mail]
>>>  >>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>> 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
>>>  >>>>>>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>>>>> 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
>>>  >>>>>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>> <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>>>>>>>>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>  >>>>>>>>>>>>>>>>>>>> OAuth mailing list
>>>  >>>>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]><mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>>>>>>>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>>>>>>> _______________________________________________
>>>  >>>>>>>>>>>>>>>>>>> OAuth mailing list
>>>  >>>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>> <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>>>>>>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>>>>>> --
>>>  >>>>>>>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>  >>>>>>>>>>>>>>>>>> [e-mail]
>>> <mailto:[e-mail]>
>>>  >>>>>>>>>>>>>>>>>> <mailto:[e-mail]>| Ping
>>>  >>>>>>>>>>>>>>>>>> Identity
>>>  >>>>>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>>>> --
>>>  >>>>>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>  >>>>>>>>>>>>>>>> [e-mail]
>>> <mailto:[e-mail]> |
>>>  >>>>>>>>>>>>>>>> Ping Identity
>>>  >>>>>>>>>>>>>>
>>>  >>>>>>>>>>>>>> --
>>>  >>>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>  >>>>>>>>>>>>>> [e-mail]
>>> <mailto:[e-mail]>| Ping
>>>  >>>>>>>>>>>>>> Identity
>>>  >>>>>>>>>>>>
>>>  >>>>>>>>>>>> _______________________________________________
>>>  >>>>>>>>>>>> OAuth mailing list
>>>  >>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>  >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>>>>>>>>>
>>>  >>>>>>>>>> --
>>>  >>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>  >>>>>>>>>> [e-mail] | Ping Identity
>>>  >>>>>>>>>
>>>  >>>>>>>>> _______________________________________________
>>>  >>>>>>>>> OAuth mailing list
>>>  >>>>>>>>> [e-mail]
>>>  >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>>>>>>>
>>>  >>>>>>>> --
>>>  >>>>>>>> Bill Burke
>>>  >>>>>>>> JBoss, a division of Red Hat
>>>  >>>>>>>> http://bill.burkecentral.com
>>>  >>>>>>>>
>>>  >>>>>>>> _______________________________________________
>>>  >>>>>>>> OAuth mailing list
>>>  >>>>>>>> [e-mail]
>>>  >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>>>>>>
>>>  >>>>>>> _______________________________________________
>>>  >>>>>>> OAuth mailing list
>>>  >>>>>>> [e-mail]
>>>  >>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>>>>>
>>>  >>>>>> --
>>>  >>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>  >>>>>> [e-mail] | Ping Identity
>>>  >>>>>
>>>  >>>>> _______________________________________________
>>>  >>>>> OAuth mailing list
>>>  >>>>> [e-mail]
>>>  >>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>>>
>>>  >>>> _______________________________________________
>>>  >>>> OAuth mailing list
>>>  >>>> [e-mail]
>>>  >>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  >>
>>>  >
>>>  > _______________________________________________
>>>  > OAuth mailing list
>>>  > [e-mail]
>>>  > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com