Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Daniel Fett <danielf+oauth@yes.com> Wed, 21 November 2018 08:39 UTC

Return-Path: <danielf+oauth@yes.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 7E286130EE9 for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 00:39:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 7C6EEB10nETZ for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 00:39:34 -0800 (PST)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 55BCB12870E for <oauth@ietf.org>; Wed, 21 Nov 2018 00:39:34 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id c126so4825687wmh.0 for <oauth@ietf.org>; Wed, 21 Nov 2018 00:39:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=FoVP0J9ghhatskfBTa5zuZaGbRQzmKOMzjd16yYG8dc=; b=AX5h7dw+YzOT7ftv8oljjus2hdtSbAXaYYdnfiKhRVpGLzlrmZyYkZkQ8vccuFRhEg idm701vppsIdW6TCqa36Z8i3V/IdgZOowJC7bq7TOoMklbj6zy0KnsE2a/ZVP5lwX/eU 6u6oGjZbknxTgjgFa+2GMbyvEHcWhLGG8Zzl4Px1ilqOO51RPO3621db4vWy/baCPYsJ eam+IjhAh07LpGTPUJ9munhiq7HXvsAcO+FCC9M+UiOiOho9RYccAbZNHGrEGe2K0/qc owJS0f0Ah66qDs7EAhmwpnP67PMnUTAlxYx84ZWaHrbVre2gJeveckftdDjpS20AnhEx RBwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=FoVP0J9ghhatskfBTa5zuZaGbRQzmKOMzjd16yYG8dc=; b=HNBMjFzQJVG6VH6mkDmAX/vUErRHgwNjI46A5fcYubIq8ORM7IAi0RU/F2gI5wiW9Y TKa6RqgeAzlz/mxQwmtksmK43DTFEx0nQ9bMyRwteP6j0Kn01PDChwEdmmwW47pkcShe 4A86KL4dIcN4XvdUlUj7MQSNvgDH4nNqiD2qKMWdTgHisvEPYhpDb+VWYrbAAz43FYUp lcCcC3HpaUWaup4PptM0Xr5rOV3vngBP8Rcpp43d+Fmrh5rUvqFw7I0Py0aEdvimy2gi XxZeqIq2HyulTshrIKkq4b+W2278Ubs99CqRU38kP28WU6N35tdExbXn7Px6hxrgzFXg 2ICA==
X-Gm-Message-State: AA+aEWb5XUHbsv+HKEtwI8MiRvCKNhQyYO0C5Ic9eBQPzDoGHu+5pzHA XzWXK2L6qT2GDviNsRMWogIaS/RTVdY=
X-Google-Smtp-Source: AJdET5eeioLIyF1BXXtHIIUzSglup0xdbCM3V7B6b9B8FRdbz/Lss+HEVq4q4nmx+c8xOfNNPWenzA==
X-Received: by 2002:a1c:9706:: with SMTP id z6mr5020672wmd.51.1542789572478; Wed, 21 Nov 2018 00:39:32 -0800 (PST)
Received: from [10.3.12.70] ([80.155.34.3]) by smtp.gmail.com with ESMTPSA id x142-v6sm641062wmd.20.2018.11.21.00.39.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 00:39:31 -0800 (PST)
To: Neil Madden <neil.madden@forgerock.com>
Cc: oauth@ietf.org
References: <VI1PR0801MB211266BA6F6E06FFB3081425FAD80@VI1PR0801MB2112.eurprd08.prod.outlook.com> <BL0PR00MB029244CACC634E2D2E923B77F5D80@BL0PR00MB0292.namprd00.prod.outlook.com> <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com> <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com>
From: Daniel Fett <danielf+oauth@yes.com>
Message-ID: <ccf62b34-5cd0-1473-ae7e-a7d166b28b80@yes.com>
Date: Wed, 21 Nov 2018 09:39:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com>
Content-Type: multipart/alternative; boundary="------------60C8011629E8C2C221A62E1F"
Content-Language: de-DE
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nuBOkQbBDpNxpVws1r7Iwnrd2zU>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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, 21 Nov 2018 08:39:36 -0000

Am 21.11.18 um 09:34 schrieb Neil Madden:
> On 21 Nov 2018, at 08:26, Daniel Fett <danielf+oauth@yes.com
> <mailto:danielf+oauth@yes.com>> wrote:
>
>> Am 20.11.18 um 13:24 schrieb Neil Madden:
>>> If we are discussing this in the context of client-side web apps/SPAs, then surely the threat model includes malicious 3rd party scripts - for which neither token binding nor mTLS constrained tokens are very effective as those scripts run in the same TLS context as the legitimate client?
>>
>> Please correct me if I'm wrong, but if a page/SPA/origin includes a
>> malicious third party script, the third party script can access all
>> data of that JavaScript. It can exfiltrate tokens and/or send
>> requests on behalf of that page/SPA/origin (using the
>> page/SPA/origin's TLS context, cookies, etc.).
>>
>> So I doubt that there is any better solution than token binding or mTLS.
>>
>> If we assume that an SPA includes a malicious third party script, it
>> is completely compromised.
>>
>
> No - same origin policy prevents those things. TLS doesn’t have those
> protections though because it acts at the transport layer and SOP is
> an application-layer concept.

If a page from origin A includes a third-party script from origin B,
that external script runs in origin A and has access to all cookies and
the JavaScript context of the page.

The SPA from origin A would be compromised. That is why we need things
such as Subresource Integrity.

-Daniel