[email protected] Em qui., 6 de nov. de 2025 às 18:38, <[email protected]> escreveu:
> Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > Today's Topics: > > 1. Re: Browser-Swapping (Primbs, Jonas) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 6 Nov 2025 16:21:08 +0000 > From: "Primbs, Jonas" <[email protected]> > Subject: [OAUTH-WG] Re: Browser-Swapping > To: Warren Parad <[email protected]> > Cc: Frederik Krogsdal Jacobsen <[email protected]>, oauth > <[email protected]> > Message-ID: <[email protected]> > Content-Type: multipart/signed; > boundary="Apple-Mail=_ACCF9F8C-A52E-484C-8BD8-401CE7857819"; > protocol="application/pkcs7-signature"; micalg=sha-256 > > > > > Am 06.11.2025 um 11:05 schrieb Warren Parad <[email protected]>: > > > > Jonas, > > > > We can ignore (1) because as you pointed out, the problem is not CSRF > it's the browser swapping, so let's focus on (2) > > > > The problem with (2) that I'm stuck on is your reasoning here: > > > > > The attacker then uses CSRF to inject the authorization request > (including the attacker’s code challenge) into the user’s session and lets > the user sign in to the authorization server. > > > > How exactly are you expecting that the attacker could inject in the CSRF > to inject the authorization request? If the attacker has to compromise the > application, the none of this matters as the attacker an directly > compromise the usage, and no protection would be sufficient. > > > > For clarification: We have to distinguish between the attacker > manipulating the flow in their own session (full control over frontend) and > the user’s session (few injection possibilities). > Therefore, the attack will be as follows to get the authorization URL and > inject it with CSRF into the user’s session: > > 1. The attacker initiates an authorization code flow in their client. > 2. The attacker intercepts the authorization URL when being sent to the > authorization server. Most of the time, this works by copying the URL > displayed on the AS’s login page. Sometimes it’s a bit more complicated > because the attacker must intercept URLs called in their browser. However, > the attacker has full control over their web browser, so this is easy. > 3. There are many ways to let the user call this URL, e.g., „Hey > administrator, could you please check my permissions here: [auth-url]“, or > leading the user to a malicious website which hides the auth URL behind a > link or forwards the attacker. Its even more evil when the attacker can > assume that the user already has an active session at the AS and the AS > does not require any user interaction for authorization, because than one > click to the link or an automatic redirection within the user’s session is > enough. > > > > At that point, we're back to my original points where there is no > solution to this problem without the browsers making fundamental changes. > > > > On Thu, Nov 6, 2025, 16:55 Philippe De Ryck < > [email protected] <mailto: > [email protected]>> wrote: > >> Maybe I am missing something here, but wouldn’t it be easier to > deprecate the state parameter as CSRF protection, as suggested by RFC 9700? > When using PKCE or a nonce, the client will attempt to exchange the > authorization code, resulting in a failure (as intended), which should/will > invalidate the authz code and stop the attack scenario. > >> > >> As far as I can tell, this scenario is not discussed anywhere in the > slides (the PKCE slides still involve state). > >> > >> Philippe > >> > >>> On 6 Nov 2025, at 16:35, Primbs, Jonas <[email protected] > <mailto:[email protected]>> wrote: > >>> > >>> Hi Frederik, > >>> > >>>> Am 06.11.2025 um 04:00 schrieb Frederik Krogsdal Jacobsen < > [email protected] <mailto:[email protected]>>: > >>>> > >>>> Hi Jonas, > >>>> > >>>> On Wed, 5 Nov 2025 at 16:25, Primbs, Jonas < > [email protected] <mailto:[email protected]>> > wrote: > >>>>> yes, calling the token request validly, thereby invalidating the > authorization code for future usage by the attacker, and throwing away the > token response could also be a solution. > >>>>> However, I am not sure what the implications could be with respect > to how authorization servers handle this (e.g., starting a session, which > confuses users when they look at the list of active sessions) or how > clients handle this (e.g., logging tokens in a potential crash dump). > >>>>> If authorization servers implement token revocation correctly, when > authorization codes are used twice, sending a second valid token request > with the same authorization code afterwards might ensure that the issued > tokens cannot be used anymore. > >>>> > >>>> Good point about the implications wrt. lists of active sessions etc. > For many cases this is a non-issue, but it might be confusing to some users. > >>>> I don't see how logging tokens as a concern is impacted by using the > code-exchange invalidation approach. If clients were doing this, they would > already be doing it now. > >>>> > >>>>> Again, this might fail if the client faces any issues. So I prefer a > standardized authorization code invalidation mechanism. > >>>>> One opportunity here, which is already standardized, is enforcing > PKCE and sending no code_verifier in the token request intentionally. > >>>> > >>>> Yes, I think this would work for any AS that supports PKCE. > >>>> > >>>>> If there already is a spec for that in CIBA, we should include or at > least reference this in the OAuth 2.1 spec. > >>>> > >>>> There is not. My intention was to say that a general invalidation > mechanism could also be useful for CIBA. > >>>> > >>> > >>> Do you think adding this to OAuth 2.1 and referencing this in CIBA is > the right place to go? > >>> > >>>> > >>>> In general, I don't think form_post is the way to go. At least I > don't have good experiences with it regarding user drop-off, and there are > also the concerns mentioned by others on thread. > >>> > >>> What about „client implementers SHOULD use form_post for server-side > clients“ and not deprecating response_mode=query? > >>> Because if developers have good reasons why they need > response_mode=query, they can still to do that, but they should know about > the implications of doing this. > >>> > >>>> > >>>> Cheers, > >>>> Frederik > >>> > >>> _______________________________________________ > >>> OAuth mailing list -- [email protected] <mailto:[email protected]> > >>> To unsubscribe send an email to [email protected] <mailto: > [email protected]> > >> _______________________________________________ > >> OAuth mailing list -- [email protected] <mailto:[email protected]> > >> To unsubscribe send an email to [email protected] <mailto: > [email protected]> > > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 11524 bytes > Desc: not available > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 6195 bytes > Desc: not available > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > ------------------------------ > > End of OAuth Digest, Vol 205, Issue 41 > ************************************** > -- Att, Anderson C. Pascini Tel: +55 (61) 86331999 Campanha por uma internet sem lixo eletrônico! Participe! É fácil. 01 - Ao enviar mensagens adicione os endereços (e-mails) usando o campo CCO/BCC (Cópia Oculta). 02 - Ao reencaminhar mensagens retire (exclua, delete, apague) o endereço de quem as enviou. "Dificulte a disseminação de vírus, spams, banners e toda a forma de lixo que circula pela net.!"
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
