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

Daniel Roesler <daniel@utilityapi.com> Fri, 08 November 2019 12:50 UTC

Return-Path: <daniel@utilityapi.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 76E8A1200C5 for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 04:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=utilityapi.com
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 wAqsoaIsc2Ol for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 04:50:17 -0800 (PST)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B5F120086 for <oauth@ietf.org>; Fri, 8 Nov 2019 04:50:17 -0800 (PST)
Received: by mail-qv1-xf2b.google.com with SMTP id g12so2110498qvy.12 for <oauth@ietf.org>; Fri, 08 Nov 2019 04:50:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=utilityapi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nrmA2b5oip4kC0RuyZmSkw+7F/ozylD/sLqM2Gf0aVA=; b=sV2ROlOkO9ZZjf8aPm8b12I7YW7dHQhYICwLhdG30nwu56hBbOsYgNOvCYYQAJenwq W1Y6nq+S8aoO+dl0cXYTnEwvk+skRIdwX3Rpq4NRoLgqt1JeHEwbMBxaFuDTsAF9MSbB JQYnDA1ELfSGtJZ9yKgj5UUwpM1StCwRccO6Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nrmA2b5oip4kC0RuyZmSkw+7F/ozylD/sLqM2Gf0aVA=; b=sAKLYRgp/dqwB9Ei7XlP/wQcsomArHpuCbJ0zJ2U2nnS4NhguodO1tWpcHM4ZwpCIb 8d6gZNK+DLsh3ZdXgWDi05lgyVAfft7jYtO1k/8KvYUTu9mPwcbfXZT/vYBWS9vt9kE9 /OYR7EieaRvgAUDQ4V/GogGXW5k7LM9/3K1PDfQ9kMD6OVxpkqEwHe3zAjuBf+fuoBSO 4fCOCfs/WMFbmsM9B61brTGefaNrW441bxVSY0XKIhDeTnJaLUzOynrjABwwUwb6lp7R 3/5If6c/UtuxiW8oOZ1nJpxSWsnbqTolFNjP++Z7lDcF4ahIrof847Uoy+MupDDNixG0 3AWQ==
X-Gm-Message-State: APjAAAXnkG+380tQvjDumUXukL8HDF83Gb08Y3uV1jdfC1siRuwcG269 RvhTLVH8XBDsmwX1jbCGqYi1n6vpsfy1jWIjrDMG+3n+VmQ=
X-Google-Smtp-Source: APXvYqxTWwMj7OvA3FARC0g90V4YFtRwW5kKA8QT6Xmmhb9rhLyRLT1fnz3DfnfB2ldQiyZd5sJpmVsPHR48vECe6ls=
X-Received: by 2002:a0c:b88f:: with SMTP id y15mr9287880qvf.161.1573217416166; Fri, 08 Nov 2019 04:50:16 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR08MB5360FBBAF0D3A38BDBED618BFA790@VI1PR08MB5360.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR08MB5360FBBAF0D3A38BDBED618BFA790@VI1PR08MB5360.eurprd08.prod.outlook.com>
From: Daniel Roesler <daniel@utilityapi.com>
Date: Fri, 8 Nov 2019 06:49:40 -0600
Message-ID: <CAF2Zz1RPt4sfoNuPMLJOPJPUCVo1Go8VvJNJSuM88Eouc9KSMA@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/YMznTv-14c47Q2s1vQ1Y2pu58A0>
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 12:50:20 -0000

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:

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).

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.

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.

[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