Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

Brian Campbell <bcampbell@pingidentity.com> Tue, 08 December 2020 21:48 UTC

Return-Path: <bcampbell@pingidentity.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 CEEC83A119A for <oauth@ietfa.amsl.com>; Tue, 8 Dec 2020 13:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_FONT_FACE_BAD=0.001, 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 (2048-bit key) header.d=pingidentity.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 TJdvalekrzhR for <oauth@ietfa.amsl.com>; Tue, 8 Dec 2020 13:48:22 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 DBD8E3A0FC0 for <oauth@ietf.org>; Tue, 8 Dec 2020 13:48:21 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id r24so374819lfm.8 for <oauth@ietf.org>; Tue, 08 Dec 2020 13:48:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QlsiFj/nJwHPcIMZ9EPK5s1Ts7hyAYCO5T/oSFOa0yM=; b=D9gEeJcP078skeWeNbjDGRnsmBeCXNCGk+uWdW7pEdUlJu8hAEXKeNu5Y/KtwEYMz2 HAle+ycS/bxXV8D+4qxziW+6PVtffUVqWWicOaXdoY/4dH4qoVGvcdDpqwELuEUUu2xa ObaSzbFsf+L32SfNcgWLpJTzDP9K8SmsMk7+wdw3suMsBQs0YQWpNKllIUVM2w4vEs9l t14E0YdYdDD3+tslNdgW3D0BKWT0bz1reXh+1PpM7Cw9WZJoeO2EwMizFw2kEK6XXUga h3d6cagUPFMfUnefJ6IKp5zuOgCrLg47IcjKFp8uEj9tZOBnjfUIz6TcLqz9plkVEm9A nKOg==
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; bh=QlsiFj/nJwHPcIMZ9EPK5s1Ts7hyAYCO5T/oSFOa0yM=; b=Yq54DVInnG4dgCfvdSBYdzmYJj/YLh+lKvn5wCNLJDiXMl6DQ7d4ouSVgpp0ooOyLg Q1mKnon+Yc+dZpDn3fsX0aKR6dHjR4pw1CYCwt/tOvAVfpzocOG/g5u5t1gVmH+9MM3S MU7afpxMe/rlhg+Ez7O+7OwMBGRBuft4bA9jnyqvtXo5wUAfaxiocOmhY4b//MHP7u1c qhKOdDtg/QJk4p09sSal7pHcMMNs1NR5RlJMOLcLriHU+ivqbTIjYmTMIBdVn7kN0ouw XuHb23u9fKB/jwqNGP8WO3qcpCYfTuM5U8UVtv6f93ccas25yRoGOyCW76VwPSJC+GDD uiPA==
X-Gm-Message-State: AOAM533lpEeJFQ1NkGl2cgRRi0JEmZOhRv/uc9Mb3A9EkHcPaA/RVD3h iZE/l6fC/hOVR7EEj98ytSSgyz8nDh4jCd04n+OnejdjefIHZsKfwapYAWm2MBF21+y6KoweGK2 x7wWwGh1P4nIA0Q==
X-Google-Smtp-Source: ABdhPJzBPXBI+iwXmAyqcuL9Hxr/mNijgDXm3sybUM0elvk65887Cy8KpnX/it8ZVm8xJWBZ+zulSNvP0G1N9eUVCho=
X-Received: by 2002:a05:6512:330d:: with SMTP id k13mr4687885lfe.173.1607464099922; Tue, 08 Dec 2020 13:48:19 -0800 (PST)
MIME-Version: 1.0
References: <CA+k3eCSyMWyLYorWH7KY+XR1syAQUi4tQXdUuevKz4Y6xNMheA@mail.gmail.com> <CALAqi_8zWGAG8p5OnrTB=4q_jL00dJi5oYQrWXmzvqKGhfL28w@mail.gmail.com> <30D5F7BA-EA54-4E40-A2FC-222AA0C9AF8D@lodderstedt.net> <CALAqi_9AH5O6d2W+0UDz83=Csm9BbcU8j6qiRxz5rzLfzm6AQA@mail.gmail.com> <353E4494-2F80-44BC-9267-6FB8B37AA0FE@lodderstedt.net> <CE661132-5D86-4652-B115-E6089E39BC68@pragmaticwebsecurity.com> <1B663AA7-563D-4D25-A408-9ED10FD818AC@forgerock.com> <DE120562-2955-461B-9852-4F0B414B18FA@pragmaticwebsecurity.com>
In-Reply-To: <DE120562-2955-461B-9852-4F0B414B18FA@pragmaticwebsecurity.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 8 Dec 2020 14:47:53 -0700
Message-ID: <CA+k3eCTnfYOFmZzu9j5XWbsZUj74f3UG54ZiWtqqyzAqRRj17Q@mail.gmail.com>
To: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Cc: Neil Madden <neil.madden@forgerock.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aa7cff05b5fae683"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/M2mc6BaHQyeOHajUVpVrAREr9nk>
Subject: Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature
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: Tue, 08 Dec 2020 21:48:25 -0000

Danial recently added some text to the working copy of the draft with
https://github.com/danielfett/draft-dpop/commit/f4b42058 that I think aims
to better convey the "nutshell: XSS = Game over" sentiment and maybe
dissuade folks from looking to DPoP as a cure-all for browser based
applications. Admittedly a lot of the initial impetus behind producing the
draft in the first place was born out of discussions around browser based
apps. But it's neither specific to browser based apps nor a panacea for
them. I hope the language in the document and how it's recently been
presented is reflective of that reality.

The more specific discussions/recommendations around in-browser apps are
valuable (if somewhat over my head) but might be more appropriate in the OAuth
2.0 for Browser-Based Apps
<https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/>
draft.

With respect to the contents of the DPoP draft, I am still keen to try and
flush out some consensus around the question posed in the start of this
thread, which is effectively whether or not to include a hash of the access
token in the proof.  Acknowledging that "XSS = Game over" does sort of
evoke a tendency to not even bother with such incremental protections (what
I've tried to humorously coin as "XSS Nihilism" with no success). And as
such, I do think that leaving it how it is (no AT hash in the proof) is not
unreasonable. But, as Filip previously articulated, including the AT hash
in the proof would prevent potentially prolonged access to protected
resources even when the victim is offline. And that seems maybe worthwhile
to have in the protocol, given that it's not a huge change to the spec. But
it's a trade-off either way and I'm personally on the fence about it.

Including an RT hash in the proof seems more niche. Best I can tell, it
would guard against prolonged offline access to protected resources when
access tokens are bearer and the RT was DPoP-bound and also gets rotated.
The trade-off there seems less worth it (I think an RT hash would be more
awkward in the protocol too).







On Fri, Dec 4, 2020 at 5:40 AM Philippe De Ryck <
philippe@pragmaticwebsecurity.com> wrote:

>
> The suggestion to use a web worker to ensure that proofs cannot be
> pre-computed is a good one I think. (You could also use a sandboxed iframe
> for a separate sub/sibling-domain - dpop.example.com).
>
>
> An iframe with a different origin would also work (not really sandboxing,
> as that implies the use of the sandbox attribute to enforce behavioral
> restrictions). The downside of an iframe is the need to host additional
> HTML, vs a script file for the worker, but the effect is indeed the same.
>
> For scenario 4, I think this only works if the attacker can trick/spoof
> the AS into using their redirect_uri? Otherwise the AC will go to the
> legitimate app which will reject it due to mismatched state/PKCE. Or are
> you thinking of XSS on the redirect_uri itself? I think probably a good
> practice is that the target of a redirect_uri should be a very minimal and
> locked down page to avoid this kind of possibility. (Again, using a
> separate sub-domain to handle tokens and DPoP seems like a good idea).
>
>
> My original thought was to use a silent flow with Web Messaging. The
> scenario would go as follows:
>
> 1. Setup a Web Messaging listener to receive the incoming code
> 2. Create a hidden iframe with the DOM APIs
> 3. Create an authorization request such as “*/authorize?response_type=code&client_id=...&redirect_uri=https%3A%2F%example.com
> <http://example.com>&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256&prompt=none&response_mode=web_message*
> ”
> 4. Load this URL in the iframe, and wait for the result
> 5. Retrieve code in the listener, and use PKCE (+ DPoP if needed) to
> exchange it for tokens
>
> This puts the attacker in full control over every aspect of the flow, so
> no need to manipulate any of the parameters.
>
>
> After your comment, I also believe an attacker can run the same scenario
> without the “*response_mode=web_message*”. This would go as follows:
>
> 1. Create a hidden iframe with the DOM APIs
> 2. Setup polling to read the URL (this will be possible for same-origin
> pages, not for cross-origin pages)
> 3. Create an authorization request such as “*/authorize?response_type=code&client_id=...&redirect_uri=https%3A%2F%example.com
> <http://example.com>&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256*
> ”
> 4. Load this URL in the iframe, and keep polling
> 5. Detect the redirect back to the application with the code in the URL,
> retrieve code, and use PKCE (+ DPoP if needed) to exchange it for tokens
>
> In step 5, the application is likely to also try to exchange the code.
> This will fail due to a mismatching PKCE verifier. While noisy, I don’t
> think it affects the scenario.
>
>
> IMO, the online attack scenario (i.e., proxying malicious requests through
> the victim’s browser) is quite appealing to an attacker, despite the
> apparent inconvenience:
>
>  - the victim’s browser may be inside a corporate firewall or VPN,
> allowing the attacker to effectively bypass these restrictions
>  - the attacker’s traffic is mixed in with the user’s own requests, making
> them harder to distinguish or to block
>
> Overall, DPoP can only protect against XSS to the same level as HttpOnly
> cookies. This is not nothing, but it means it only prevents relatively
> naive attacks. Given the association of public key signatures with strong
> authentication, people may have overinflated expectations if DPoP is
> pitched as an XSS defence.
>
>
> Yes, in the cookie world this is known as “Session Riding”. Having the
> worker for token isolation would make it possible to enforce a
> coarse-grained policy on outgoing requests to prevent total abuse of the AT.
>
> My main concern here is the effort of doing DPoP in a browser versus the
> limited gains. It may also give a false sense of security.
>
>
>
> With all this said, I believe that the AS can lock down its configuration
> to reduce these attack vectors. A few initial ideas:
>
> 1. Disable silent flows for SPAs using RT rotation
> 2. Use the sec-fetch headers to detect and reject non-silent iframe-based
> flows
>
> For example,  an OAuth 2.0 flow in an iframe in Brave/Chrome carries these
> headers:
> *sec-fetch-dest: iframesec-fetch-mode: navigatesec-fetch-site:
> cross-sitesec-fetch-user: ?1*
>
>
> Philippe
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._