From nobody Fri Dec 11 16:02:00 2020 Return-Path: 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 257B03A1059 for ; Fri, 11 Dec 2020 16:01:59 -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 RIKsmlO9T9bH for ; Fri, 11 Dec 2020 16:01:55 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 365793A1058 for ; Fri, 11 Dec 2020 16:01:55 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id r24so15688848lfm.8 for ; Fri, 11 Dec 2020 16:01:55 -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=wt0Q0fHvXwvaRReIKCB5zOTRyqGC8wCU3+zz0qitL/Y=; b=TrnS0ZTIkU6rEr8zC/7VFzCgxnXMtiwHk5AGPPVYaQqZLuB8XYmoAdNeaNmOiX+sMx ZEdZMfwILQkaVgZo78iarSKm4Nmhojtw/sFxNLhwOuwV2G0i4+SPvX3/0tjLcWlmsEL7 QnqvOHk4k913oAWE5a5EJ7YgaAWH1VcGPOr7FBukloYKhR2qZLoyG/y6GCSs4EP6MISq 6q7JSBa0KDil24WdjU8FRzKMNm63Py3nWO97o7ByScm9d6sYWtDJC5UuzxfjHwh1k9cc WpNd3Fe7xcfYcUgTtDVgOfgI+ohbjLHwfEzsnr4umJro7E+IcPKy1H/ifbCx6nNKuA1g RFmw== 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=wt0Q0fHvXwvaRReIKCB5zOTRyqGC8wCU3+zz0qitL/Y=; b=jOKdjmtEz/61cYbkV+JxkrBs2+xb111XU0/G0hpITDyrANi2cSo28ZxhXpIJnRuVB+ VVn0uUN9HZYwWKMEWo0/TnBb58LVEzYyMxCMDX5DYz8rup4/8PBX7QeWCCNxNPIqq1T4 21Bmsx3qm/ZRLJxC99UM2/2i5hGEHe2pmuKRLKZ7th8tJDeTwx9PxF6zHiyD1KwIDcV1 JdrFw6awLBBTi8jICCRcV1qS79080NaKL8w3VIb7UdJuV8yAh5I8pIlSUJ9WK6pn4QkC 27f7Kfq1U2z3Qsc4OlUUvv07hInvhcT99w80ZsK5ZqKnpRTRuQc7ROYGXY5NKejXCMKo hsLQ== X-Gm-Message-State: AOAM532ofbKGpPZHigwzssFK+ZgpOU3bzUb3XUhfiouktQcYlswMB/zY fDO3gHgygq7XS2dcQed/fgcrzpdCKbc1lo2RS1e3W6I52CFVlgVjhamxAGno+SfXhIanL7IcBDD HPjSJq1xJLjk0ejTxEO/TfQ== X-Google-Smtp-Source: ABdhPJxFh3M4I+rEC2i556zORrlHFcsezhEIK1m7fwfsha3mGYUj2YzJZ2ieDPsh53vZs1kMPMwD2rxTN1CjyoqvHh0= X-Received: by 2002:a19:650c:: with SMTP id z12mr5113949lfb.582.1607731313350; Fri, 11 Dec 2020 16:01:53 -0800 (PST) MIME-Version: 1.0 References: <30D5F7BA-EA54-4E40-A2FC-222AA0C9AF8D@lodderstedt.net> <353E4494-2F80-44BC-9267-6FB8B37AA0FE@lodderstedt.net> <1B663AA7-563D-4D25-A408-9ED10FD818AC@forgerock.com> <6b389264-96c2-497b-d8f5-204cf430bec1@manicode.com> In-Reply-To: <6b389264-96c2-497b-d8f5-204cf430bec1@manicode.com> From: Brian Campbell Date: Fri, 11 Dec 2020 17:01:26 -0700 Message-ID: To: Jim Manico Cc: Philippe De Ryck , oauth Content-Type: multipart/alternative; boundary="000000000000d3b78a05b6391d3f" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 00:01:59 -0000 --000000000000d3b78a05b6391d3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that puts Jim in the XSS Nihilism camp :) Implicit type flows are being deprecated/discouraged. But keeping tokens out of browsers doesn't seem likely. There is some menton of CSP in https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-= 9.7 On Wed, Dec 9, 2020 at 4:10 PM Jim Manico wrote: > The basic theme from the web attacker community is: > > 1) XSS is a game over event to web clients. XSS can steal or abuse > (request forgery) tokens, and more. > > 2) Even if you prevent stolen tokens from being used outside of a web > client, XSS still allows the attacker to force a user to make any request > in a fraudulent way, abusing browser based tokens as a form of request > forgery. > > 3) There are advanced measures to stop a token from being stolen from a > web client, like a HTTPonly cookies and to a lesser degree, JS Closures a= nd > Webworkers. > > 4) However, these measures to protect cookies are mostly moot. Attackers > can just force clients to make fraudulent requests. > > 5) Many recommend the BFF pattern to hide tokens on the back end, but > still, request forgery via XSS allows all kinds of abuse. > > XSS is game over no matter how you slice it. > > Crypto solutions do not help. Perhaps the world of OAuth can start > suggesting that web clients use CSP 3.0 in specific ways, if you still pl= an > to support Implicit type flows or tokens in browsers? > > Respectfully, > > - Jim > > > On 12/9/20 12:57 PM, Brian Campbell wrote: > > Thanks Philippe, I very much concur with your line of reasoning and the > important considerations. The scenario I was thinking of is: browser base= d > client where XSS is used to exfiltrate the refresh token along with > pre-computed proofs that would allow for the RT to be exchanged for new > access tokens and also pre-computed proofs that would work with those > access tokens for resource access. With the pre-computed proofs that woul= d > allow prolonged (as long as the RT is valid) access to protected resource= s > even when the victim is offline. Is that a concrete attack scenario? I > mean, kind of. It's pretty convoluted/complex. And while an access token > hash would reign it in somewhat (ATs obtained from the stolen RT wouldn't > be usable) it's hard to say if the cost is worth the benefit. > > > > On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck < > philippe@pragmaticwebsecurity.com> wrote: > >> Yeah, browser-based apps are pure fun, aren=E2=80=99t they? :) >> >> The reason I covered a couple of (pessimistic) XSS scenarios is that the >> discussion started with an assumption that the attacker already >> successfully exploited an XSS vulnerability. I pointed out how, at that >> point, finetuning DPoP proof contents will have little to no effect to s= top >> an attack. I believe it is important to make this very clear, to avoid >> people turning to DPoP as a security mechanism for browser-based >> applications. >> >> >> Specifically to your question on including the hash in the proof, I thin= k >> these considerations are important: >> >> 1. Does the inclusion of the AT hash stop a concrete attack scenario? >> 2. Is the =E2=80=9Ccost=E2=80=9D (implementation, getting it right, =E2= =80=A6) worth the benefits? >> >> >> Here=E2=80=99s my view on these considerations (*specifically for browse= r-based >> apps, not for other types of applications*): >> >> 1. The proof precomputation attack is already quite complex, and short >> access token lifetimes already reduce the window of attack. If the attac= ker >> can steal a future AT, they could also precompute new proofs then. >> 2. For browser-based apps, it seems that doing this complicates the >> implementation, without adding much benefit. Of course, libraries could >> handle this, which significantly reduces the cost. >> >> >> Note that these comments are specifically to complicating the spec and >> implementation. DPoP=E2=80=99s capabilities of using sender-constrained = access >> tokens are still useful to counter various other scenarios (e.g., >> middleboxes or APIs abusing access tokens). If other applications would >> significantly benefit from having the hash in the proof, I=E2=80=99m all= for it. >> >> On a final note, I would be happy to help clear up the details on >> web-based threats and defenses if necessary. >> >> =E2=80=94 >> *Pragmatic Web Security* >> *Security for developers* >> https://pragmaticwebsecurity.com/ >> >> >> On 8 Dec 2020, at 22:47, Brian Campbell >> wrote: >> >> 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 =3D Game over" sentiment and ma= ybe >> dissuade folks from looking to DPoP as a cure-all for browser based >> applications. Admittedly a lot of the initial impetus behind producing t= he >> draft in the first place was born out of discussions around browser base= d >> 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 >> >> 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 t= his >> thread, which is effectively whether or not to include a hash of the acc= ess >> token in the proof. Acknowledging that "XSS =3D Game over" does sort of >> evoke a tendency to not even bother with such incremental protections (w= hat >> 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 has= h >> in the proof would prevent potentially prolonged access to protected >> resources even when the victim is offline. And that seems maybe worthwhi= le >> 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 mor= e >> 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 ifr= ame >>> 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 ind= eed >>> 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 ar= e >>> 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 =E2=80=9C*/authorize?respons= e_type=3Dcode&client_id=3D...&redirect_uri=3Dhttps%3A%2F%example.com >>> &state=3D...&code_challenge=3D7-ffnU1EzHtMfxOAdlkp= _WixnAM_z9tMh3JxgjazXAk&code_challenge_method=3DS256&prompt=3Dnone&response= _mode=3Dweb_message* >>> =E2=80=9D >>> 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, s= o >>> no need to manipulate any of the parameters. >>> >>> >>> After your comment, I also believe an attacker can run the same scenari= o >>> without the =E2=80=9C*response_mode=3Dweb_message*=E2=80=9D. 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 =E2=80=9C*/authorize?respons= e_type=3Dcode&client_id=3D...&redirect_uri=3Dhttps%3A%2F%example.com >>> &state=3D...&code_challenge=3D7-ffnU1EzHtMfxOAdlkp= _WixnAM_z9tMh3JxgjazXAk&code_challenge_method=3DS256* >>> =E2=80=9D >>> 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 token= s >>> >>> 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= =E2=80=99t >>> think it affects the scenario. >>> >>> >>> IMO, the online attack scenario (i.e., proxying malicious requests >>> through the victim=E2=80=99s browser) is quite appealing to an attacker= , despite >>> the apparent inconvenience: >>> >>> - the victim=E2=80=99s browser may be inside a corporate firewall or V= PN, >>> allowing the attacker to effectively bypass these restrictions >>> - the attacker=E2=80=99s traffic is mixed in with the user=E2=80=99s o= wn requests, >>> making them harder to distinguish or to block >>> >>> Overall, DPoP can only protect against XSS to the same level as HttpOnl= y >>> cookies. This is not nothing, but it means it only prevents relatively >>> naive attacks. Given the association of public key signatures with stro= ng >>> authentication, people may have overinflated expectations if DPoP is >>> pitched as an XSS defence. >>> >>> >>> Yes, in the cookie world this is known as =E2=80=9CSession Riding=E2=80= =9D. Having the >>> worker for token isolation would make it possible to enforce a >>> coarse-grained policy on outgoing requests to prevent total abuse of th= e AT. >>> >>> My main concern here is the effort of doing DPoP in a browser versus th= e >>> 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: iframe sec-fetch-mode: navigate sec-fetch-site: >>> cross-site sec-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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> > *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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > -- > Jim Manico > Manicode Securityhttps://www.manicode.com > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000d3b78a05b6391d3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that puts Jim in the XSS Nihilism camp :)=C2= =A0

Implicit type flows are being deprecated/disco= uraged. But keeping tokens out of browsers doesn't seem likely. There i= s some menton of CSP in https://tools.ietf.org/html/draft-i= etf-oauth-browser-based-apps-07#section-9.7

On Wed, Dec 9, 20= 20 at 4:10 PM Jim Manico <jim@manicode.com> wrote:
=20 =20 =20

The basic theme from the web attacker community is:

1) XSS is a game over event to web clients. XSS can steal or abuse (request forgery) tokens, and more.

2) Even if you prevent stolen tokens from being used outside of a web client, XSS still allows the attacker to force a user to make any request in a fraudulent way, abusing browser based tokens as a form of request forgery.

3) There are advanced measures to stop a token from being stolen from a web client, like a HTTPonly cookies and to a lesser degree, JS Closures and Webworkers.

4) However, these measures to protect cookies are mostly moot. Attackers can just force clients to make fraudulent requests.

5) Many recommend the BFF pattern to hide tokens on the back end, but still, request forgery via XSS allows all kinds of abuse.

XSS is game over no matter how you slice it.

Crypto solutions do not help. Perhaps the world of OAuth can start suggesting that web clients use CSP 3.0 in specific ways, if you still plan to support Implicit type flows or tokens in browsers?

Respectfully,

- Jim


On 12/9/20 12:57 PM, Brian Campbell wrote:
=20
Thanks Philippe, I very much concur with your line of reasoning and the important considerations. The scenario I was thinking of is: browser based client where XSS is used to exfiltrate the refresh token along with pre-computed proofs that would allow for the RT to be exchanged for new access tokens and also pre-computed proofs that would work with those access tokens for resource access. With the pre-computed proofs that would allow prolonged (as long as the RT is valid) access to protected resources even when the victim is offline. Is that a concrete attack scenario? I mean, kind of. It's pretty convoluted/complex. An= d while an access token hash would reign it in somewhat (ATs obtained from the stolen RT wouldn't be usable) it's hard= to say if the cost is worth the benefit.



On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:
Yeah, browser-based apps are pure fun, aren=E2=80=99t they? :)

The reason I covered a couple of (pessimistic) XSS scenarios is that the discussion started with an assumption that the attacker already successfully exploited an XSS vulnerability. I pointed out how, at that point, finetuning DPoP proof contents will have little to no effect to stop an attack. I believe it is important to make this very clear, to avoid people turning to DPoP as a security mechanism for browser-based applications.


Specifically to your question on including the hash in the proof, I think these considerations are important:

1. Does the inclusion of the AT hash stop a concrete attack scenario?
2. Is the =E2=80=9Ccost=E2=80=9D (implementation, getting = it right, =E2=80=A6) worth the benefits?


Here=E2=80=99s my view on these considerations (spec= ifically for browser-based apps, not for other types of applications):

1. The proof precomputation attack is already quite complex, and short access token lifetimes already reduce the window of attack. If the attacker can steal a future AT, they could also precompute new proofs then.=C2=A0
2. For browser-based apps, it seems that doing this complicates the implementation, without adding much benefit. Of course, libraries could handle this, which significantly reduces the cost.=C2=A0


Note that these comments are specifically to complicating the spec and implementation. DPoP=E2=80=99s capabilities of using sender-constrained access tokens are still useful to counter various other scenarios (e.g., middleboxes or APIs abusing access tokens). If other applications would significantly benefit from having the hash in the proof, I=E2=80=99m all for it.

On a final note, I would be happy to help clear up the details on web-based threats and defenses if necessary.

=E2=80=94
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/


On 8 Dec 2020, at 22:47, Brian Campbell <bcampbell@pingide= ntity.com> wrote:

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 =3D 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 recentl= y 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 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.=C2=A0 Acknowledging that &quo= t;XSS =3D 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@pragmat= icwebsecurity.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 =E2=80=9C/authorize?response_t= ype=3Dcode&client_id=3D...&redirect_uri=3Dhttps%3A%2F%example.com&state=3D...&co= de_challenge=3D7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challen= ge_method=3DS256&prompt=3Dnone&response_mode=3Dweb_message=E2= =80=9D
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 =E2=80=9Cresponse_mode=3Dw= eb_message=E2=80=9D. 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 =E2=80=9C/authorize?= response_type=3Dcode&client_id=3D...&redirect_uri=3Dhttps%3A%2F%example.com&state=3D= ...&code_challenge=3D7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&co= de_challenge_method=3DS256=E2=80=9D
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=E2=80=99t think it affects= the scenario.=C2=A0


IMO, the online attack scenario (i.e., proxying malicious requests through the victim=E2=80=99s browser) is quite appealing to an attacker, despite the apparent inconvenience:

=C2=A0- the victim=E2=80=99s bro= wser may be inside a corporate firewall or VPN, allowing the attacker to effectively bypass these restrictions
=C2=A0- the attacker=E2=80=99s t= raffic is mixed in with the user=E2=80=99s ow= n 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 =E2=80=9CSession Riding=E2=80=9D= . 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.=C2=A0



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, =C2=A0an OAuth 2.0 flow i= n an iframe in Brave/Chrome carries these headers:
sec-fetch-dest: iframe
sec-fetch-mode: navigate
sec-fetch-site: cross-site
sec-fetch-user: ?1


Philippe


CONFIDENTIALITY NOTICE: Thi= s 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.=C2=A0 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.


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.=C2=A0 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. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

--=20
Jim Manico
Manicode Security
https://www.manicode=
.com

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000d3b78a05b6391d3f--