Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

David Waite <david@alkaline-solutions.com> Fri, 08 November 2019 20:01 UTC

Return-Path: <david@alkaline-solutions.com>
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 B79C6120C7A for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 12:01:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.227
X-Spam-Level: **
X-Spam-Status: No, score=2.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 7GpVVYIEEnJj for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 12:01:43 -0800 (PST)
Received: from alkaline-solutions.com (unknown [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 73C6E120B23 for <oauth@ietf.org>; Fri, 8 Nov 2019 12:01:27 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:bc69:2824:515c:c2c2] (unknown [IPv6:2601:282:202:b210:bc69:2824:515c:c2c2]) by alkaline-solutions.com (Postfix) with ESMTPSA id A2B9C31628; Fri, 8 Nov 2019 20:01:25 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.2\))
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <CAF2Zz1RPt4sfoNuPMLJOPJPUCVo1Go8VvJNJSuM88Eouc9KSMA@mail.gmail.com>
Date: Fri, 8 Nov 2019 13:01:25 -0700
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E15A89A1-F7C6-4466-BAD9-232C98C0D14A@alkaline-solutions.com>
References: <VI1PR08MB5360FBBAF0D3A38BDBED618BFA790@VI1PR08MB5360.eurprd08.prod.outlook.com> <CAF2Zz1RPt4sfoNuPMLJOPJPUCVo1Go8VvJNJSuM88Eouc9KSMA@mail.gmail.com>
To: Daniel Roesler <daniel=40utilityapi.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2WdqO1YlaP-CZQrGHVuYE1SSKpk>
Subject: Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
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: Fri, 08 Nov 2019 20:01:45 -0000

Hello Daniel!

> 1. The client makes an ajax HEAD request to the OAuth authorization
> endpoint, which will silently create the authorization grant (this was
> the security exploit that was patched).

> Anyway, I'm trying to find guidance on transparent redirects for
> authorization code grants. There's a whole host of both security and
> application logic issues that could come up from such behavior, so I'd
> like to ask for clarification in best practices.

OAuth does not provide a way to recover from an expired access token barring a refresh token, which also can be invalidated. In particular, the only front channel ‘continuation’ parameter I know of is ‘id_token_hint’ in OIDC.

There are deployments today (admittedly mostly using implicit flow) which do not have refresh tokens. A mandate that you SHOULD ask for re-consent would be a recommendation that they have to interrupt the user periodically to continue access - which would just create another security vs usability decision.

Per your point above, the actual security issue was that GitHub 1) had the authorization endpoint serve double-duty and 2) treated HEAD requests as a quasi GET/POST to create a grant in their database to the client without user confirmation. The solution for this is not to ask the user to re-confirm on every request..

That said, it does make sense for some deployments to periodically invalidate a refresh token, even for the purpose of bringing the user back to re-consent permissions (aka self-audit). An application could theoretically distinguish from tokens granted by the protected user needing to be invalidated to drive the user to re-consent, and operationally granted tokens which are assumed to be actively managed and not tied to any user account.

-DW

> On Nov 8, 2019, at 5:49 AM, Daniel Roesler <daniel=40utilityapi.com@dmarc.ietf.org> wrote:
> 
> Howdy,
> 
> In the "3.1 Protecting Redirect-Based Flows" > "3.1.1. Authorization
> Code Grant" section, is there guidance on when it is appropriate (if
> ever) to automatically generate a new authorization code and redirect
> back to the client?
> 
> A recent exploit[1] on Github's OAuth implementation was practical
> because if you make an authorization request and the resource owner is
> already authenticated and the scope is already authorized, Github will
> silently generate a new authorization code and redirect the user back
> to the redirect_uri without asking them to click "Authorize" again.
> 
> How the exploit worked:
> 
> 
> 2. However, since the ajax response was blocked via CORS, the client
> couldn't receive the authorization code in the response parameters.
> 
> 3. So, the client then redirected the user to Github's authorization
> endpoint with the same authorization code request (only this time as a
> real GET redirect).
> 
> 4. Github instantly redirected the user back to the client's
> redirect_uri with a new authorization code and without asking for any
> user interaction.
> 
> It seems strange to me that OAuth should allow for transparent
> authorization code redirects without resource owner confirmation. This
> situation only comes up when something weird is happening, such as
> when a client loses their valid access|refresh_token, but isn't that
> all the more reason to clarify that you should always ask for resource
> owner confirmation of the scope, even in scenarios where you are just
> re-authorizing the same scope as before?
> 
> Had Github asked for confirmation on step 4 above, the practicality of
> the HEAD exploit would have been reduced because the user would have
> been presented with an unexpected Allow/Deny Github OAuth dialogue,
> possibly alerting them to the fact that something strange was going
> on.
> 
> 
> [1]: https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html
> 
> Daniel Roesler
> Co-founder & CTO, UtilityAPI
> daniel@utilityapi.com
> 
> 
> 
> On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig
> <Hannes.Tschofenig@arm.com> wrote:
>> 
>> Hi all,
>> 
>> this is a working group last call for "OAuth 2.0 Security Best Current Practice".
>> 
>> Here is the document:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
>> 
>> Please send you comments to the OAuth mailing list by Nov. 27, 2019.
>> (We use a three week WGLC because of the IETF meeting.)
>> 
>> Ciao
>> Hannes & Rifaat
>> 
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>> 
>> _______________________________________________
>> 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