3 ms·

Two big easy and obvious ones missing from your list: - Query injection (always a threat to any query library) - RegEx DDoS (always a threat to routers becaus

Two big easy and obvious ones missing from your list: - Query injection (always a threat to any query library) - RegEx DDoS (always a threat to routers because all most routers are is a miserable pile of RegExes and because route writers don't like RegExes directly, often include DSL compilers to RegExes, which can lead to their own exploits) JS is a Turing complete language and though it is often run in a sometimes strict sandbox mathematicians have now proven there's a "0-Day" sandbox break in the Universal Turing Machine and that it is likely a corollary/relative of the Halting Problem. Sure, modern browsers absolutely have a ton of security settings and improve every day on that, but browsers aren't perfect (mathematically can't be perfect, according to our best understanding). JS is still a complete programming language with everything that implies about exploits and bugs and timing attacks and disclosure leaks. "severely weakened" is not "the threat doesn't exist" and certainly not "the threat isn't worth worrying about, it is fine to leave bugs unpatched". It certainly means you can take a measured approach to how you prioritize unpatched bugs, but a general malaise sense of lack of priority in frontend issues is what contributes to why frontend libraries don't have the same backwards compatibility rules or long-term security maintenance habits as many backend systems. As an industry we are really bad about looking down on frontend as a second-class environment when it is one of the largest percentages of all program code running on the average user's machines this decade. I could keep listing CVEs for days, and then still have weeks of lecture topics about how npm has one of the biggest ecosystems for supply chain attacks right now (and those are an active and ongoing threat). I understand the lack of perceived priority and I appreciate that not everyone has the same level of "full stack paranoia" that I do.

littlecranky67 2y ago
> RegEx DDoS you don't seem to have any understanding what SPAs are. There is no server-side code in your SPA, all code is run on the users browser. If you do any sort of DoS, you will bring down the users browser, not the server hosting the SPA. How is that a feasible attack vector? > Query Injection Again, not SPA relevant. What is injected? How do you even inject that code into the browser of a user, if you do not have access to the server-side end of the application? XSS, as I said, is mostly mitigated in SPAs that use CSP.
- WorldMaker 2y ago
  > you don't seem to have any understanding what SPAs are. There is no server-side code in your SPA, all code is run on the users browser. If you do any sort of DoS, you will bring down the users browser, not the server hosting the SPA. How is that a feasible attack vector? You don't think it is a problem if user's browsers lock up or crash? You don't think it reflects poorly on a business if their app/SPA is the one that caused it? (Even though it wasn't their bug?) The first D in DDoS is distributed and sure the most common meaning of that is taking down a remote server with lots of broken clients. This form in SPAs is also distributed in the additional way that it can vector to take down many clients. > Again, not SPA relevant. What is injected? How do you even inject that code into the browser of a user, if you do not have access to the server-side end of the application? XSS, as I said, is mostly mitigated in SPAs that use CSP. Query Injection attacks like SQL Injection attacks are about putting attacker-specified changes into whatever Query Language is being used. Many SPAs move their generation of queries and the Query Languages they use into the SPA. That's the entire point of libraries like react-query, moving query generation into DSLs close to the UI and directly inside the SPA. No CSP is going to ever stop a SPA from sending bad queries to open query services. Sure XSS is mostly mitigated, but XSS is not the only way to inject a query. The SPA is in the hands of the users. If your attackers are users (or pretending to be) they don't need XSS, they just need access to the application and its query DSLs. Bugs in those query DSLs are security bugs. Classic Client/Server architecture 101: the client is in the hands of the enemy.
littlecranky67 2y ago
> how npm has one of the biggest ecosystems for supply chain attacks right now And all of them are only relevant for server-side nodejs applications, not SPAs as the user original poster was referring to (React CSR). Your points are all moot and irrelevant to the actual topic discussed.
- WorldMaker 2y ago
  Several of them have been massive disclosure leaks in SPAs. All of the ones targeted at Crypto Wallets, for instance, were supply chain attacks in Electron code and/or SPA code.

littlecranky67 2y ago

> RegEx DDoS you don't seem to have any understanding what SPAs are. There is no server-side code in your SPA, all code is run on the users browser. If you do any sort of DoS, you will bring down the users browser, not the server hosting the SPA. How is that a feasible attack vector? > Query Injection Again, not SPA relevant. What is injected? How do you even inject that code into the browser of a user, if you do not have access to the server-side end of the application? XSS, as I said, is mostly mitigated in SPAs that use CSP.

WorldMaker 2y ago
> you don't seem to have any understanding what SPAs are. There is no server-side code in your SPA, all code is run on the users browser. If you do any sort of DoS, you will bring down the users browser, not the server hosting the SPA. How is that a feasible attack vector? You don't think it is a problem if user's browsers lock up or crash? You don't think it reflects poorly on a business if their app/SPA is the one that caused it? (Even though it wasn't their bug?) The first D in DDoS is distributed and sure the most common meaning of that is taking down a remote server with lots of broken clients. This form in SPAs is also distributed in the additional way that it can vector to take down many clients. > Again, not SPA relevant. What is injected? How do you even inject that code into the browser of a user, if you do not have access to the server-side end of the application? XSS, as I said, is mostly mitigated in SPAs that use CSP. Query Injection attacks like SQL Injection attacks are about putting attacker-specified changes into whatever Query Language is being used. Many SPAs move their generation of queries and the Query Languages they use into the SPA. That's the entire point of libraries like react-query, moving query generation into DSLs close to the UI and directly inside the SPA. No CSP is going to ever stop a SPA from sending bad queries to open query services. Sure XSS is mostly mitigated, but XSS is not the only way to inject a query. The SPA is in the hands of the users. If your attackers are users (or pretending to be) they don't need XSS, they just need access to the application and its query DSLs. Bugs in those query DSLs are security bugs. Classic Client/Server architecture 101: the client is in the hands of the enemy.

littlecranky67 2y ago

> how npm has one of the biggest ecosystems for supply chain attacks right now And all of them are only relevant for server-side nodejs applications, not SPAs as the user original poster was referring to (React CSR). Your points are all moot and irrelevant to the actual topic discussed.

WorldMaker 2y ago
Several of them have been massive disclosure leaks in SPAs. All of the ones targeted at Crypto Wallets, for instance, were supply chain attacks in Electron code and/or SPA code.