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]
