Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

Neil Madden <neil.madden@forgerock.com> Wed, 17 March 2021 07:55 UTC

Return-Path: <neil.madden@forgerock.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 328973A0ADB for <oauth@ietfa.amsl.com>; Wed, 17 Mar 2021 00:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=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=forgerock.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 0xDXgDDR4yRe for <oauth@ietfa.amsl.com>; Wed, 17 Mar 2021 00:55:43 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 32EB63A0AD7 for <oauth@ietf.org>; Wed, 17 Mar 2021 00:55:43 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id h10so1039991edt.13 for <oauth@ietf.org>; Wed, 17 Mar 2021 00:55:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=vC9a7jbAnfv6p8NXw0b7XiU1dqejVbQhKKe5zKZPXUg=; b=dMAX71YbK0g1CBExPBa9LTiqrF0vRAaSnOF5xnWwsiIJK6FL1miAtEreWtzRp5QJcw JFRk6hYZ8SR/6SSaGqZJZOxAWQQM38pmP6EjISo3OR+bK3bHPuoRNLueqM1jAdZ1Z/dQ aMq8a3yDLfM5rWOZrHNA7H/5vle1Fy8PRcsU0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=vC9a7jbAnfv6p8NXw0b7XiU1dqejVbQhKKe5zKZPXUg=; b=cxAvzOOyL+zLCL7Tw/NTbFfsSDEa9koVftDyyaz7Zq9iOhyEYEdKxxjcy/4avMkF7f hOz4uw9xa1jdoyfFPBvGClqHNv8BqJZzVpr6e5e7EbNYiPYDt23FPDwldzqbpy/hMrWf gqLuB4NI+knAYmG4J6d0CPxSxVISAnTQuO4tfqLHWP6gUZ4KTxI+cCg6UlnOr3z+ozYG KNxm0sJ66fold8YkS1CtLOUkQibQSXubEbCiRTnmFE5fE2ZEHZn1xzavdQvFCXDR1oeS P995dWoW60qWhlAhVLfLUYpJvGl+6SGgxf9uACqkYRNE7UarTtjPhQCe//a24v1vOA68 txag==
X-Gm-Message-State: AOAM531qNZvGFlWr/DKBlT+cDtKEG98MHTvu/CoKzk2AQaeue0YPlsRB CrsbVPyPgFAta1vt5ryoXAuCXybC3KPeKLEbaRXO9B8F32zbNkfICRGlYTQ7GzgVqTBwy8u7RKY qxDxp0wJq
X-Google-Smtp-Source: ABdhPJzsrmsQ/pj8dVVB9ZAQB26n5e1DMlXrOjmad1+E7ieu7uZvAdUWnh3Ez9x0S8nO2d90pNagDg==
X-Received: by 2002:aa7:c815:: with SMTP id a21mr41017498edt.38.1615967740259; Wed, 17 Mar 2021 00:55:40 -0700 (PDT)
Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id u13sm10866340ejy.31.2021.03.17.00.55.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Mar 2021 00:55:39 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 17 Mar 2021 07:55:38 +0000
Message-Id: <01AA7223-40F0-438E-8819-062DFDAED563@forgerock.com>
References: <CAJTOVTbXpU5HmeXUY90kcM4qe5gOQAhdT6RrZTZ8qPLykeJsWQ@mail.gmail.com>
Cc: George Fletcher <gffletch@aol.com>, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org>, oauth <oauth@ietf.org>, Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
In-Reply-To: <CAJTOVTbXpU5HmeXUY90kcM4qe5gOQAhdT6RrZTZ8qPLykeJsWQ@mail.gmail.com>
To: Om <omkarkhair@gmail.com>
X-Mailer: iPhone Mail (18D52)
Content-Type: multipart/alternative; boundary="Apple-Mail-6A0E9866-34C9-498D-8BEB-F51A91A00D35"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iAiCDeJyWSC49qy-9FHpQA9JVr0>
Subject: Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]
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, 17 Mar 2021 07:55:45 -0000

No, it doesn’t mention this attack. The issue is that if the redirect_uri is not strongly bound to a legitimate client then a malicious app on the user’s device can initiate an OAuth flow and impersonate the legitimate client and then intercept the response by claiming to handle the redirect_uri. 

We thought this was solved by using claimed https redirect_uris (Universal Links on iOS, AppLinks on Android), as these require the webserver to publish a document explicitly granting permission for a particular app to claim part of its https address space. But it turns out that Android has a hole in this because it allows any app to claim to be a web browser and so handle all URIs. 

(I thought this attack was discussed in the security topics bcp, but I can’t see it). 

The 2.1 draft currently requires (MUST) ASes to support private-use URL schemes, which makes this problem much worse. IMO private-use URL schemes are un-securable and shouldn’t be encouraged let alone mandated. 

— Neil

> On 17 Mar 2021, at 05:17, Om <omkarkhair@gmail.com> wrote:
> 
> If I read this correctly, https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10 the 2.1 draft already addresses this under best practices.
> 
>>> On Mon, Mar 15, 2021 at 3:31 PM Neil Madden <neil.madden@forgerock.com> wrote:
>> I want to come back to this topic as a new thread.
>> 
>> As I understand things, the difference on Android is that any app can claim to be a generic web browser and so claim to handle all URIs. Whereas on iOS only specifically vetted apps can claim to be web browsers. Is that correct?
>> 
>> If so, this does seem like a quite large hole in security of OAuth on Android. Should we be considering a new draft recommending alternative measures (such as attestation) on Android? Presumably the same issue is also true on most desktop OS?
>> 
>> — Neil
>> 
>>> On 23 Feb 2021, at 15:20, George Fletcher <gffletch@aol.com> wrote:
>>> 
>>> Unfortunately, in the mobile app world this isn't sufficient. On iOS using Universal Links will bind the https redirect_url to your app in a secure way but it doesn't work the same way on Android with App Links. There is still a problem with "mobile app impersonation". If you have an app that you want to ensure is "your" app then the most secure way is to look at "app attestation". This is however, way off topic for this thread :)
>>> 
>>>>> On 2/14/21 9:28 AM, Neil Madden wrote:
>>>> Public clients are implicitly authenticated by their ownership of the registered redirect_uri. This why it’s important to use a redirect_uri for which ownership can be reasonably established, such as HTTPS endpoints with exact URI matching. 
>>>> 
>>>> There are more things that can go wrong with that (see the security BCP), but it can be made reasonably secure. 
>>>> 
>>>> — Neil

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>