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) > <https://medium.com/@anador/attacks-via-a-new-oauth-flow-authorization-code-injection-and-whether-httponly-pkce-and-bff-3db1624b4fa7#f009> > . > > 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. > 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. > Additional attention should be paid to redirect URI values validation in > this case to prevent XSS on the side of authorization server (imagine > <https://security.lauritz-holtmann.de/post/sso-security-redirect-uri-iii/>something > like javascript:alert(1) as a redirect URI). > 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 > <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-acquisition-and-extraction-> > attack (which is quite similar from the description provided). > > > ---------------- > Кому: [email protected] ([email protected]); > Копия: [email protected], Warren Parad ([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 > TG: @andreukuznetsov_work <https://t.me/andreukuznetsov_work> > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
