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