No, it's the opposite. If you set the cookies which needs to be recieved at the redirect URI with SameSite=Lax/Strict the browser will not send them in a POST request from another site, even if t's a top-level navigation.
So if we do that, then we cannot receive any "pre-auth" cookies on the redirect URI endpoint in case of form post.
--
Best regards,
Andrey Kuznetsov
Software Architect
Identity & Access Management
Yandex Cloud
----------------
Кому: Andrey Kuznetsov ([email protected]);
Копия: [email protected], oauth ([email protected]);
Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in OAuth/OIDC Security Best Practices;
10.11.2025, 16:46, "Warren Parad" <[email protected]>:
,Just to clarify, it's seems XSS is the fundamental attack vector that is unique to the browser, the other ones aren't unique and would affect server-spide credentialed clients as well, so focusing on XSS and iframe make sense.So I want to ask, what if all "pre-auth cookies" are using SameSite=Strict or Lax, are you suggesting that would prevent the attack being suggested?
On Mon, Nov 10, 2025, 08:53 Andrey Kuznetsov <[email protected]> wrote:The thread has taken several directions, so I’ll respond here to the latest message to keep things together.
To wrap things up:
1. I considered the attacker with a particular model. I didn't consider cases when the attacker achieves RCE on the backend, because it's a completely different threat model, i agree. The attacker is considered to be an external entity (a web attacker) who is able to inject _javascript_ code into any page of the legitimate application that has an origin matching the origin of the redirect URI. At the same time, communication channels are protected by TLS and the attacker has no access to unencrypted traffic or physical access to the user’s devices. The attacker also lacks other special traits.
2. The statement that in this model OAuth does not have fundamental protection measures is correct. I agree that any additional protection measures such as PAR/JAR/JARM don't prevent the attack as well. I suppose, Jonas and Warren already agreed on that. I tried to examine it in more detail here (#Protection measures).
3. So that I suggest that methods that make one of attack steps impossible can be addressed as a primary protection measure. I proposed using the form post response mode as a primary defence mechanism with possibility for additional protection measures which can play a role in defence in depth:- Protection against malicious _javascript_ injection (very obvious)- Protection against iframe exploitation- Restrictions to prevent the authorization process from being completely transparent and invisible to the user
- Restriction on using the web message response mode
- Binding the authorization code to IP/fingerprint
- Transferring redirect URI page to a different origin- Audit of the authorization server’s capabilities from the perspective of breaking the OAuth flow
They all have their pros and cons.4. So here, to rephrase my initial thesis i would like to say that usage of form post response mode completely prevents the attacker with the described capabilities (which, again, are not so unique) from stealing the authorization response via the ways discussed previously. That's the key idea. But it's possible only if the authorization server is able to limit the available response modes at some level.Additional attention should be paid to redirect URI values validation in this case to prevent XSS on the side of authorization server (imagine something like _javascript_:alert(1) as a redirect URI).
On the other hand, we have a special aspect here: any pre-auth cookies must have SameSite=None. Is this a significant drawback? It depends. Its impact will depend on specific deployments.Besides, form post response mode seems to be superior to query/fragment/web message response modes.Also it's interesting enough that after all that time we're coming back to the same exact mechanism that has been used in SAML POST Binding.Therefore, my suggestion is that we can record the option of using form post response mode. Either by noting its higher security compared to the default query mode, or at least by stating that it mitigates the Browser Swapping attack and the Acquisition and Extraction of New Tokens attack (which is quite similar from the description provided).----------------Кому: [email protected] ([email protected]);Копия: [email protected], Warren Parad (wparad=[email protected]);Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in OAuth/OIDC Security Best Practices;10.11.2025, 00:06, "Primbs, Jonas" <[email protected]>:Hi Jeff,
I’m not sure whether we should also address supply chain attacks in OAuth, because this would create many (partially unsolvable) issues.
However, it is worth noting that malicious _javascript_ could access the authorization code when it is transmitted as a query or fragment parameter, whereas form_post would prevent that on the client side.
So, thank you very much for that hint!
Greetings,
Jonas
Am 09.11.2025 um 14:22 schrieb Jeffrey Walton <[email protected]>:,
On Sun, Nov 9, 2025 at 12:04 PM Warren Parad
<[email protected]> wrote:
So the problem with your examples, and you haven't included the attack surface that allowed for that to happen. (With the exception of XSS, which can only be executed through an interaction from the user's user agent. But to be specific, take the "compromised third-party JS library" example. You've made it specific to the browser with "the addition of a script tag", which is good, but you've left out how that happens. But how did it get there exactly? It's hard to know what the right solution to the problem is if we don't consider the attack vector that caused it. If we don't discuss the attack vector, we can't be sure the solution will actually solve the problem. It isn't helpful to discuss hypotheticals that may or may not happen, we need to do the threat modelling analysis.
If you want an example of injecting _javascript_ code in a client --
without a 0-day and with TLS protections -- then see an analysis of
the KLAYswap attack,
<https://blog.citp.princeton.edu/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/>.
Less exotic examples include compromised libraries coming from places
like Maven or NPM. The problem is so prolific that the company at
$dayjob has to subscribe to a composition analysis and scanning
service to ensure compromised library code is not used for development
or make it into production.
On the opposite end of the spectrum, your example of "Or if you build a SPA and one of the dependencies contains malicious code" is completely flawed though. Because, again, how did the dependency contain malicious code? But now this isn't a problem that is limited just to SPAs. Which means we need a solution that protects not just SPAs. If we assume that a library can contain malicious code, when are the dependencies for the browser any different from dependencies for a credentialed client? In my perspective, they aren't. Whichever means caused the dependency to include malicious code for a browser environment, would also include vulnerabilities for all other clients, in a way that no solutions exist. It isn't useful, helpful, or relevant to discuss vulnerabilities in libraries, because "if vulnerabilities in libraries can exist, then they for sure exist for server-side environments" making any solution that does not address server-side environments worthless.
Jeff
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]--С уважением,Андрей КузнецовАрхитектор, YC IAM & Resource Management_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
