> 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]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
