dammit
Denial of service and source code exposure in React Server Components
11–20 of 232 posts
Re: Denial of service and source code exposure in React Server Components
#12I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."
Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed.
Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.
Re: Denial of service and source code exposure in React Server Components
#13It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities."
Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
Re: Denial of service and source code exposure in React Server Components
#14After Log4Shell, additional CVEs were reported as well.
It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.
Re: Denial of service and source code exposure in React Server Components
#15So we have a new React CVE and tomorrow is Friday, so please be prepared for a new outage brought to you by the super-engineers at Cloudflare.
Re: Denial of service and source code exposure in React Server Components
#16React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server.
It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we've recently seen, is a risky spot in terms of potential security vulnerabilities.
Re: Denial of service and source code exposure in React Server Components
#17I wonder what does these vulnerabilities mean for Facebook. As per my knowledge, Facebook's the biggest web app written in React.
Re: Denial of service and source code exposure in React Server Components
#18It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
What’s concerning about it? The first thing I thought when I read the headline was “wow, another react CVE?” It’s not a justification, it’s an explanation to the most obvious immediate question.
Re: Denial of service and source code exposure in React Server Components
#19It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
Welcome to the React, Next, Vercel ecosystem. Our tech may be shite but we look fancy.
Re: Denial of service and source code exposure in React Server Components
#20I wonder what does these vulnerabilities mean for Facebook. As per my knowledge, Facebook's the biggest web app written in React.
Does Facebook actually use RSC? I thought it was mainly pushed by the Nextjs/Vercel side of the React team.