Comment by WorldMaker | Hacker News Reader

Comment by WorldMaker | Hacker News Reader

Parent Full thread

Frontend security issues do exist and can be big problems. Especially in SPA designs where the frontend runs a massive in-memory database of an entire application state. (As many of them do, especially if you are using things like frontend routing and ad hoc backend DB querying as both example libraries are about.)

.NET has a security support policy that LTS versions (currently even version numbers) are supported for a couple of years and non-LTS versions (currently odd version numbers) for a year after they've been released. A lot of frontend packages don't have the maintenance budget to offer support plans on anything but the most recent major version (in part because many of them are open source and low contributor count; their own problems for the ecosystem).

Don't discount security/support maintenance concerns in the frontend. Also, yes, it is a problem that many frontend packages in the ecosystem don't have maintenance policies as strong as the best backends.

The packages referenced in this article do not have known security vulnerabilities in the latest minor/patch versions of their previous majors. So the author is still complaining about an unnecessary update.

> Frontend security issues do exist and can be big problems.

Citation needed.

> Especially in SPA designs where the frontend runs a massive in-memory database of an entire application state

How is that more relevant for security issues? Common Frontend Security issues are traditionally xss, csrf, token/session theft etc. Lot of those attack vectors have been severely weakened with modern browser security settings (Content-Security-Policy, HttpOnly cookies, SameSite=strict etc.). Eager to hear how a view router (wouter) or a server-state-management system (react-query) in the FE are likely to have security wholes in that field.

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.

> 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.

> 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.

> 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.

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.

On such popular and packages, one should reasonably expect security holes to be found and made public with relatively little delay. At that point, upgrading becomes relevant.

Reply on news.ycombinator.com