In the KLAYswap attack, the attacker utilized essentially what amounts to a stolen TLS certificate and fabricated BGP routes, is something that you believe OAuth should explicitly attempt to protect against?
On Sun, Nov 9, 2025 at 8:23 PM Jeffrey Walton <[email protected]> wrote: > 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]
