Re: [OAUTH-WG] open redirect in rfc6749

Antonio Sanso <asanso@adobe.com> Tue, 16 September 2014 08:53 UTC

Return-Path: <asanso@adobe.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034E21A01E8 for <oauth@ietfa.amsl.com>; Tue, 16 Sep 2014 01:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Level:
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRjbtQteXzyR for <oauth@ietfa.amsl.com>; Tue, 16 Sep 2014 01:53:25 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0614.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:614]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE20A1A0428 for <oauth@ietf.org>; Tue, 16 Sep 2014 01:52:47 -0700 (PDT)
Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Tue, 16 Sep 2014 08:52:24 +0000
Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.112]) with mapi id 15.00.1024.012; Tue, 16 Sep 2014 08:52:24 +0000
From: Antonio Sanso <asanso@adobe.com>
To: Sergey Beryozkin <sberyozkin@gmail.com>
Thread-Topic: [OAUTH-WG] open redirect in rfc6749
Thread-Index: AQHP0YNSkKtdFG+ezkuqdvp/CtER9pwDckILgAAB8QA=
Date: Tue, 16 Sep 2014 08:52:23 +0000
Message-ID: <4DE5DA70-605F-42CD-A698-9AF930890393@adobe.com>
References: <5nofjvf5jjbcqjdv9bmdgdg0.1410846275737@email.android.com> <5417EC3D.8060601@pingidentity.com> <5417F820.8000804@gmail.com> <5417F886.4030801@gmail.com>
In-Reply-To: <5417F886.4030801@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.147.117.11]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 03361FCC43
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(51444003)(24454002)(377454003)(52604005)(479174003)(51704005)(199003)(189002)(587094003)(90102001)(87936001)(105586002)(110136001)(106356001)(107046002)(2656002)(101416001)(83072002)(83716003)(54356999)(15395725005)(85306004)(31966008)(19580405001)(36756003)(77982003)(74662003)(80022003)(81542003)(79102003)(81342003)(46102003)(74502003)(19580395003)(64706001)(85852003)(66066001)(93886004)(83322001)(97736003)(76176999)(20776003)(92726001)(76482001)(92566001)(86362001)(50986999)(106116001)(82746002)(99396002)(15202345003)(4396001)(99286002)(16236675004)(77096002)(15975445006)(33656002)(21056001)(95666004)(19617315012)(16601075003)(104396001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_4DE5DA70605F42CDA6989AF930890393adobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AJqpttwsaQPu7dn7YLD-KHw4PWA
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] open redirect in rfc6749
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Sep 2014 08:53:33 -0000

hi Sergey

On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin <sberyozkin@gmail.com<mailto:sberyozkin@gmail.com>> wrote:

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 ?

as previously discussed is pretty fought to filter bad redirect uri specially for big OPs like Facebook/Google et al where all you need to have in order to create a new OAuth client is an email address (the registration process is self-service).

Justin proposed some mitigation though… (namely a client can gain ‘reputation’ with time)

regards

antonio


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: oauth@ietf.org<mailto:oauth@ietf.org>
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 <asanso@adobe.com<mailto:asanso@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.hunt@oracle.com<mailto:phil.hunt@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<http://www.independentid.com>
>> phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>
>>
>>
>>
>> On Sep 15, 2014, at 1:00 PM, John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@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.hunt@oracle.com<mailto:phil.hunt@oracle.com>>
wrote:
>>>>
>>>> Simply not true.
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com<http://www.independentid.com>
>>>> phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>
>>>>
>>>>
>>>>
>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso <asanso@adobe.com<mailto:asanso@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
<hzandbelt@pingidentity.com<mailto:hzandbelt@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 <bburke@redhat.com<mailto:bburke@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
<hzandbelt@pingidentity.com<mailto:hzandbelt@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 <asanso@adobe.com<mailto:asanso@adobe.com>
>>>>>>>>>>> <mailto:asanso@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
<asanso@adobe.com<mailto:asanso@adobe.com>
>>>>>>>>>>>> <mailto:asanso@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
<hzandbelt@pingidentity.com<mailto:hzandbelt@pingidentity.com>
>>>>>>>>>>>>> <mailto:hzandbelt@pingidentity.com>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
>>>>>>>>>>>>>>> <hzandbelt@pingidentity.com<mailto:hzandbelt@pingidentity.com>
<mailto:hzandbelt@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
>>>>>>>>>>>>>>>>> <hzandbelt@pingidentity.com<mailto:hzandbelt@pingidentity.com>
<mailto:hzandbelt@pingidentity.com>
>>>>>>>>>>>>>>>>> <mailto:hzandbelt@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
<ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>
>>>>>>>>>>>>>>>>>>> <mailto:ve7jtb@ve7jtb.com>
>>>>>>>>>>>>>>>>>>> <mailto:ve7jtb@ve7jtb.com>
>>>>>>>>>>>>>>>>>>> <mailto:ve7jtb@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
<bburke@redhat.com<mailto:bburke@redhat.com>
>>>>>>>>>>>>>>>>>>>> <mailto:bburke@redhat.com>
>>>>>>>>>>>>>>>>>>>> <mailto:bburke@redhat.com>
>>>>>>>>>>>>>>>>>>>> <mailto:bburke@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://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://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/> <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
>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com
<mailto:hzandbelt@pingidentity.com>
>>>>>>>>>>>>>>>>>> <mailto:hzandbelt@pingidentity.com>| Ping
>>>>>>>>>>>>>>>>>> Identity
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com
<mailto:hzandbelt@pingidentity.com> |
>>>>>>>>>>>>>>>> Ping Identity
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>>>>>> hzandbelt@pingidentity.com
<mailto:hzandbelt@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
>>>>>>>>>> hzandbelt@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
>>>>>> hzandbelt@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





--
Sergey Beryozkin

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

Blog: http://sberyozkin.blogspot.com<http://sberyozkin.blogspot.com/>

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth