Re: [OAUTH-WG] Caution about open redirectors using the state parameter

Pieter Philippaerts <pieter.philippaerts@kuleuven.be> Wed, 22 April 2020 13:14 UTC

Return-Path: <pieter.philippaerts@kuleuven.be>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FA43A0BEB for <oauth@ietfa.amsl.com>; Wed, 22 Apr 2020 06:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 NA38ma02WyDS for <oauth@ietfa.amsl.com>; Wed, 22 Apr 2020 06:14:47 -0700 (PDT)
Received: from rhcavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F523A0BE6 for <oauth@ietf.org>; Wed, 22 Apr 2020 06:14:46 -0700 (PDT)
X-KULeuven-Envelope-From: pieter.philippaerts@kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 4DFCB120008.A2F9C
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by rhcavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 4DFCB120008 for <oauth@ietf.org>; Wed, 22 Apr 2020 15:14:35 +0200 (CEST)
Received: from ICTS-S-EXMBX24.luna.kuleuven.be (icts-s-exmbx24.luna.kuleuven.be [10.112.11.59]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTPS id 29A65200A9 for <oauth@ietf.org>; Wed, 22 Apr 2020 15:14:35 +0200 (CEST)
Received: from ICTS-S-EXMBX19.luna.kuleuven.be (10.112.11.50) by ICTS-S-EXMBX24.luna.kuleuven.be (10.112.11.59) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Apr 2020 15:14:34 +0200
Received: from ICTS-S-EXMBX19.luna.kuleuven.be ([fe80::b0b6:d4f7:5b6e:2396]) by ICTS-S-EXMBX19.luna.kuleuven.be ([fe80::b0b6:d4f7:5b6e:2396%21]) with mapi id 15.00.1497.006; Wed, 22 Apr 2020 15:14:34 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Philippaerts <pieter.philippaerts@kuleuven.be>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Caution about open redirectors using the state parameter
Thread-Index: AdYXSOJMqPEgvXlOQI+GZQm5PJwZ3AAuVAyAAARymQAAJBIdiw==
Date: Wed, 22 Apr 2020 13:14:34 +0000
Message-ID: <1587561273967.95187@kuleuven.be>
References: <8ef6dfa2-a3b0-3908-ac7d-b496908d07e1@aol.com>, <39FB95F6-4542-4DA3-9F5A-7D64FDF507DD@forgerock.com>
In-Reply-To: <39FB95F6-4542-4DA3-9F5A-7D64FDF507DD@forgerock.com>
Accept-Language: en-US, nl-BE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.112.50.1]
Content-Type: multipart/alternative; boundary="_000_158756127396795187kuleuvenbe_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/abnge8YBZYGWho1u-kZwV69Nvoc>
Subject: Re: [OAUTH-WG] Caution about open redirectors using the state parameter
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 22 Apr 2020 13:14:51 -0000

> I think the correct defence is to validate the URL


I agree. The URL can be whitelisted, signed, encrypted, ...


> > Can we please add an explicit prohibition of this practice in draft-ietf-oauth-security-topics?

> However, we should be careful how we prohibit it...


You could argue that it's already there. Section 4.7.1 says:


If "state" is used for carrying application state, and integrity
of its contents is a concern, clients MUST protect "state" against
tampering and swapping.  This can be achieved by binding the
contents of state to the browser session and/or signed/encrypted
state values [I-D.bradley-oauth-jwt-encoded-state].


Implementations, like the ones you're seeing, where "state" stores a URL and is used without validation do not comply with the above paragraph.


I do agree that the above paragraph is somewhat hidden in the CSRF section. Perhaps a new subsection could be added to section 4 where attacks on the "state" parameter are discussed (and where countermeasures like signing the state are repeated)?


Regards,

Pieter



________________________________
From: OAuth <oauth-bounces@ietf.org> on behalf of Neil Madden <neil.madden@forgerock.com>
Sent: Tuesday, April 21, 2020 23:35
To: George Fletcher
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Caution about open redirectors using the state parameter

I think the correct defence is to validate the URL (eg check against a whitelist) at the point you are going to redirect to it after the OAuth flow completes, rather than before you begin the OAuth flow.

But this feels like generic web app security advice rather than anything specific to OAuth - always validate URLs before performing a redirect.

Neil

On 21 Apr 2020, at 20:28, George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

? +1

However, we should be careful how we prohibit it... because if the state value is actually signed, having the URL there isn't a problem as the attacker can not manipulate the value without breaking the signature.

On 4/20/20 5:28 PM, Mike Jones wrote:

I've seen several circumstances where "clever" clients implement an open redirector by encoding a URL to redirect to in the state parameter value.  Attackers can then utilize this open redirector by choosing a state value.

Can we please add an explicit prohibition of this practice in draft-ietf-oauth-security-topics?

                                                       Thanks,
                                                       -- Mike






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


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