Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

Benjamin Häublein <Benjamin.Haeublein@cirosec.de> Wed, 05 January 2022 12:41 UTC

Return-Path: <Benjamin.Haeublein@cirosec.de>
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 5031F3A00E9 for <oauth@ietfa.amsl.com>; Wed, 5 Jan 2022 04:41:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cirosec.de
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 a0fBxg4krgFb for <oauth@ietfa.amsl.com>; Wed, 5 Jan 2022 04:41:18 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10042.outbound.protection.outlook.com [40.107.1.42]) (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 92C8B3A00DE for <oauth@ietf.org>; Wed, 5 Jan 2022 04:41:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cirosec.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C9iEzNT55WV6FufZ7QLRF5waLqQVtcBkMrJuMOylKas=; b=kWiOIKZ0gmEyQw+U7w+MmVDMz/ah2KoGa9LY+fDm5IG+grnlBd5ERJVjeUQfVkxhp+0MwHR4jjJl0ij9Ch1l153NbhLvnbvm/2irOJMO7zcpGFyRhn52FpkUJ4daGH+yuiu23d4Qd2icSiVZ38t25QadW+/VHul7H6oxfm3qYJQ=
Received: from AM6PR02CA0027.eurprd02.prod.outlook.com (2603:10a6:20b:6e::40) by AM8P192MB1058.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:1e6::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.7; Wed, 5 Jan 2022 12:41:07 +0000
Received: from VI1EUR04FT062.eop-eur04.prod.protection.outlook.com (2603:10a6:20b:6e:cafe::61) by AM6PR02CA0027.outlook.office365.com (2603:10a6:20b:6e::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.14 via Frontend Transport; Wed, 5 Jan 2022 12:41:07 +0000
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning cirosec.de discourages use of 195.243.60.194 as permitted sender)
Received: from z1.cirosec.com (195.243.60.194) by VI1EUR04FT062.mail.protection.outlook.com (10.152.29.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.7 via Frontend Transport; Wed, 5 Jan 2022 12:41:07 +0000
Received: from z1.cirosec.com (localhost [127.0.0.1]) by z1.cirosec.com (Postfix) with ESMTP id BD98740068; Wed, 5 Jan 2022 13:41:06 +0100 (CET)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp2057.outbound.protection.outlook.com [104.47.6.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by z1.cirosec.com (Postfix) with ESMTPS id 9CA6F40067; Wed, 5 Jan 2022 13:40:57 +0100 (CET)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B9S7pgWh/ZpkDwF4+1ojoy9/JsgKB880IZGCCp2ESys22hW07R7sR+w678Nr5vIY5X+oxqmZajC9XWdZCfgzRBDOCgudIITiWexg0fhKXccI2BW5iVFU5rFE1ayWSevK+eLB7GSb3zLs1aoYx76JxP3VcqrBzt2TTXe+GAy2IBAehf7X8SnlXSHT328btZFmLRdcc5bGXhTxHj7RwnA4bDg2Z4qP7Z3+5bq0TAGutr8HvjOmCbAcvDGz6ADc3JyRfXsUv9sEhj2qqhwu/9l2hSecyXZ/n9Qtox4SvX4pHAlkE5cKxOK9nkUq6Ao8lG3Jt18/oYfqlLLf18G6Rv3egA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r6opUfybfnE5Hu+xOfYFok1JIdKrSYNagwW1ccL+RdY=; b=Qcdd60JbcO5Omb0OredecD98OwBCpCzrmyenvuD6snwiRAPvxBCMWzkctKtwgFztaT8kZGnHtDWhHG/itF5XqibyOgX/ZAzQPdt5vVWRBYSfhbXGQoVfa8eaz+91FgHizVxbmgRsG0w+/eIjteEnXRsQUHJJu8wqfVN2fZBOJZF3rYtkt6LxYdJLqSp7Z7nDwHQuDFJD0n9f20r1D463IKHUfU8hJpxnKNBX27g9+jv2hn+FDEZP5YdoNCyx6vSmgZ9i8m8P33I3H6umf9UUuJrL09hJ95z/eUQzHPDDFZBrz54wCpLMG4W2PL3E3aXCES6yFal6i53eVYdbvw/9+Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cirosec.de; dmarc=pass action=none header.from=cirosec.de; dkim=pass header.d=cirosec.de; arc=none
Received: from AM7P192MB0819.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:176::17) by AM6P192MB0439.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:31::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.15; Wed, 5 Jan 2022 12:40:55 +0000
Received: from AM7P192MB0819.EURP192.PROD.OUTLOOK.COM ([fe80::5903:531c:f47:bc06]) by AM7P192MB0819.EURP192.PROD.OUTLOOK.COM ([fe80::5903:531c:f47:bc06%3]) with mapi id 15.20.4867.009; Wed, 5 Jan 2022 12:40:54 +0000
From: Benjamin Häublein <Benjamin.Haeublein@cirosec.de>
To: George Fletcher <gffletch@aol.com>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF
Thread-Index: AdgBWCxwol5UzlIbQPqsjH/C3LbbiAAGfQGAAC+fA9A=
Date: Wed, 05 Jan 2022 12:40:54 +0000
Message-ID: <AM7P192MB081909F590F651D656ACC892E44B9@AM7P192MB0819.EURP192.PROD.OUTLOOK.COM>
References: <AM7P192MB0819568B6CF315C3BC3A9B15E44A9@AM7P192MB0819.EURP192.PROD.OUTLOOK.COM> <b711bc01-9674-6072-d941-7e1ba8f8c9ec@aol.com>
In-Reply-To: <b711bc01-9674-6072-d941-7e1ba8f8c9ec@aol.com>
Accept-Language: de-DE, en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-bromium-msgid: 9c2b1390-d955-44ef-8e97-9cc35fe629a9
X-MS-Office365-Filtering-Correlation-Id: 695e2e71-8b49-4f2f-6be6-08d9d048a4e8
x-ms-traffictypediagnostic: AM6P192MB0439:EE_|VI1EUR04FT062:EE_|AM8P192MB1058:EE_
X-Microsoft-Antispam-PRVS: <AM8P192MB10584EFD4466437D5AD25D47E44B9@AM8P192MB1058.EURP192.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: Myg66clJWw1L/KRaalUciRvEQmZvpyGtTmBcf6nHE3Jvtd4bWggzNDa67YAmarg3rhfPSKnZ1in78E+uwfSpYOxKG7upEr+sYZtCrWmRZWLATezIMFJG2KiHVHXRbyNugA5PZ67sVno/KHeX5iQQAY1B3ppuaA9r/SHk417VAQD8B2QCAVewOH/Na1oLfxeAdj570mZI+wNINrZmnQKQ8ZyIc9fwLZRLIgNtoE7g68BoSe08wHkDlPrLLC4GT2EO6iQWupJ44AKv+t7W/V8Q2oHGsBEeS/+hlPNXjvkcvhgpX9P5ygN4ABcG2d/nejvFquXiutE2FETkN5Pvx1S3R2KnRLx8g4P0MqiupnScBV5VVc+0XriImD1VZOJwmMTEG5ZtH+vYWSioAGSUcZcnUtH1kkroZGirttrGPPN9AIxlsOsyR5Jxb0D9EAakji2tw+WDDYEBicFHWUsQPQTc+TGCCsd9EQ7Mopwk+eKvyIs4mD3Ks+lnH+wOIM8gIEcRlDMJbJUkZPtUDVvfV7LW9XM2V2knITmElNMJcFo97SGjWA9jBbzfEM7vsq4iDUkj2qDSo0OVKVQdUSqYdH41j9vBb39nwyc352RnPWdBvDhkWLTUZJ32AeWuS3sjwTFck6J50Md5ET1NG/k1LdFc0iDMTK/A365YUxWQXG2AZ5+ZjIWuPxITFCpFdQTRMTEwOlRKVh4ThQA50o97U7m3VhmdwUxf73fj+/CrFK6VjIegE8MUyMiOaMckC7hNmnKqYzQv+R0giPqdDldGp39MPcFS1YWAc80y4oUn8kKdqDU=
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7P192MB0819.EURP192.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(39840400004)(366004)(136003)(396003)(346002)(38100700002)(55016003)(66574015)(76116006)(66946007)(66446008)(2906002)(8676002)(85182001)(85202003)(316002)(19627235002)(38070700005)(122000001)(9686003)(53546011)(7696005)(5660300002)(33656002)(52536014)(6506007)(71200400001)(166002)(8936002)(83380400001)(508600001)(86362001)(26005)(966005)(110136005)(66476007)(66556008)(64756008)(186003); DIR:OUT; SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6P192MB0439
X-TBoneOriginalFrom: Benjamin Häublein <Benjamin.Haeublein@cirosec.de>
X-TBoneOriginalTo: George Fletcher <gffletch@aol.com>, "oauth@ietf.org" <oauth@ietf.org>
X-TBoneDomainSigned: false
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="----E3E59F9D59B3F46FCC01A1EAB8B46F34"
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VI1EUR04FT062.eop-eur04.prod.protection.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs: 016622d7-2a25-4837-5feb-08d9d0489d87
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: OJ3AnYf1vKfUki8/31ONtixxOIaI3SQzmB9JmemMvlbAVOsmBUGj3c9ezrggVuDUMjxpJjQY0NFVD7un+PYtvKh8MFFHiScaw+DXrqm382kW+oCrt2/pkJXBeotY6Hs86q4Q6YdQhd1yPTnL6mA65nzWXPhepceun1yljmV2SdpwHnz+AXvGtdt6oyIp0ixWJF1AsEefRpxdq3Es+v8MDOYzsFo4Db5kaZfeSwx/AuY5WjzcIY8h11P4wumAFLF+qergydgoxu4QIxz3Ktfc4do/F+T5wdbAGJmEcnDK+SJ2EpsjtE5DeQSU/s+hdVygj+nTQmKrrRDUuSlVLjukwnmNrMM/jgWsMkAFPKn5X32OEslHHQWWSd9BVpaL02XeKb/PupZDub2VSnITuPHuPC8q+TuxYOPcv8Cj2tI6hpXsf8t97KHr2Gx+MsV6k0vN0s6rXNkeNwbV6IVbqNQV0lbRqLYqwBTIbbdAJgUgwqJmoxzioyHHGf5kg4E108QqzqGnWDsz3wccR4bcCpvd/Hy8Mu5IoN1V7BcRnZhOGWeclSIPH6yQ5Xs6THLQj6PMG4Lk+mB6U++VdqmSgePHT4r8y1L/T0QkI4zNAY1eD7es1yI9YTUFBwzPG1HGuFWv2i8UMBTvLVUGLbQc3eL2nm9T7btvx48/NA8AGB0lHFlhln4QQOBLUNiiSAoYPszExO4pdrvEdcEhE8WnmLMnUfs0dj+UWQxrzb3uDTkTtFQNqVqu1/uSiap/g3o9MmVc3VmWIBeGL6fNvq+kC77zYavWqv7BO21u3gJQK/YU7iq5b/D26bbA+TQ2q7XzJUrY
X-Forefront-Antispam-Report: CIP:195.243.60.194; CTRY:DE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:z1.cirosec.com; PTR:z1.cirosec.com; CAT:NONE; SFS:(4636009)(136003)(346002)(376002)(396003)(39840400004)(46966006)(36840700001)(55016003)(82310400004)(19627235002)(15974865002)(316002)(336012)(33656002)(85202003)(6506007)(86362001)(9686003)(36860700001)(8936002)(33964004)(53546011)(186003)(8676002)(2906002)(7696005)(26005)(70586007)(85182001)(110136005)(47076005)(70206006)(66574015)(7636003)(7596003)(966005)(52536014)(508600001)(166002)(235185007)(5660300002)(356005)(30864003)(40480700001)(83380400001); DIR:OUT; SFP:1101;
X-OriginatorOrg: cirosec.de
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2022 12:41:07.1460 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 695e2e71-8b49-4f2f-6be6-08d9d048a4e8
X-MS-Exchange-CrossTenant-Id: 21fbdf28-bed3-4a1a-b1ca-8bb38fcb05e0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=21fbdf28-bed3-4a1a-b1ca-8bb38fcb05e0; Ip=[195.243.60.194]; Helo=[z1.cirosec.com]
X-MS-Exchange-CrossTenant-AuthSource: VI1EUR04FT062.eop-eur04.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P192MB1058
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9dlClSiMe6fF_F6qKKNr2MeTFeU>
Subject: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF
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, 05 Jan 2022 12:41:24 -0000

Finally, I'm not sure a client that doesn't send the 'code_challenge' and 'code_challenge_method' on the authorization request but does send the 'code_verifier' on the token request should consider that the client has implemented PKCE correctly and hence can rely on it for CSRF.
My point is not, that a client behaves that way. The problem is that an attacker could get a user (through social engineering) to start the authorization process and then click a link with an authorization response that the attacker provides.
Then the client has send the 'code_challenge' and 'code_challenge_method' in the authorization request, but the authorization response belongs to an authorization request that does not have these parameters.
When the client sends the token request based on the malicious authorization request but with the ‘code_verifier’ for the original authorization request.
When the AS behaves as described the client has no way to know that an attacker has interfered.

Best Regards,
Benjamin Häublein

Von: George Fletcher <gffletch@aol.com>
Gesendet: Dienstag, 4. Januar 2022 14:51
An: Benjamin Häublein <Benjamin.Haeublein@cirosec.de>; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

My guess is that for an Authorization Server that doesn't receive a 'code_challenge' and 'code_challenge_method' as part of the authorization request, they treat the request as a non-PKCE authorization request. Therefore when the 'code_verifier' is presented at the /token endpoint, the AS ignores the parameter because it doesn't consider the request to be a PKCE request. I can also see the AS returning an error regarding an "unexpected parameter" or "invalid request" error in this case.

I agree with your recommendation for the AS to require specific clients to use PKCE and consider an authorization request without PKCE to be an error.

Finally, I'm not sure a client that doesn't send the 'code_challenge' and 'code_challenge_method' on the authorization request but does send the 'code_verifier' on the token request should consider that the client has implemented PKCE correctly and hence can rely on it for CSRF.

Thanks,
George

On 1/4/22 5:45 AM, Benjamin Häublein wrote:
Hello everyone,
I think RFC 7636 “Proof Key for Code Exchange by OAuth Public Clients”, section 4.6. “Server Verifies code_verifier before Returning the Tokens” leaves a tiny gap regarding the handling of verification when no code challenge was present in the authorization request:
   Upon receipt of the request at the token endpoint, the server
   verifies it by calculating the code challenge from the received
   "code_verifier" and comparing it with the previously associated
   "code_challenge", after first transforming it according to the
   "code_challenge_method" method specified by the client.
It is unspecified how the server should behave when “code_verifier” is present, but “code_challenge” and “code_challenge_method” were not set in the initial authorization request.
The following example worked for three well-known authorization servers where the client was configured in a way that PKCE could be used, but was not enforced:
Authorization Request:
https://XXXX/auth?client_id=YYYY&response_type=code&scope=openid+profile&redirect_uri=https://localhost
Subsequent Token Request:
POST /token HTTP/1.1
Host: XXXX
Content-Length: 256

code=ZZZZ&grant_type=authorization_code&client_id=YYYY&redirect_uri=https%3A%2F%2Flocalhost&code_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
As a result, an access token was issued although the code_verifier provided in the token request did not match the code_challenge and code_challenge_method in the authorization request.

Many applications consider the usage of PKCE as enough protection from Login-CSRF and do not use state or nonce (for example this blog entry by Daniel Fett https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ suggests, that neither state nor nonce are necessary when PKCE is used). However, when the authorization server is not configured to require a specific code_challenge_method from the client and the authorization behaves as described in the example, PKCE does not protect from Login-CSRF.
I think the following mitigations are possible:

  1.  Enforce usage of PKCE in the client configuration in the Authorization Server
  2.  Implementation of the authorization server returns an error in the Access Token Response when code_verifier is present in the token request, but no code_challenge and code_challenge_method is present in the authorization request.
  3.  Additionally, when the behavior of an AS is correct (verification of code_verifier fails when no code_challenge was present), a client that relies on PKCE for CSRF protection must always include a code_verifier parameter in the token request (even if no code_verifier is present on the client side).

Best regards,

Benjamin Häublein
Senior Consultant

cirosec GmbH
Ferdinand-Braun-Strasse 4
74074 Heilbronn
Germany
Phone: +49 (7131) 59455-74
Fax: +49 (7131) 59455-99
Mobile: +49 (151) 122414-74
www.cirosec.de<http://www.cirosec.de>

HRB Stuttgart 107883
CEO Stefan Strobel, CFO Peter Lips




_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth