Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RCE Vulnerability in React and Next.js

github.com

Post reply on HN
Print view View original

81–90 of 276 posts

Re: RCE Vulnerability in React and Next.js

#81

Post by swyx »

root_axis wrote: post #59
ascorbic wrote: post #28

Earlier quoted context omitted.

That number is misleadingly low, because it doesn't include Next.js which bundles the dependency. Almost all usage in the wild will be Next.js, plus a few using the experimental React Router support.

As far as I'm aware, transitive dependencies are counted in this number. So when you npm install next.js, the download count for everything in its dependency tree gets incremented. Beyond that, I think there is good reason to believe that the number is inflated due to automated downloads from things like CI pipelines, where hundreds or thousands of downloads might only represent a single instance in the wild.

why is it not normal for CI pipelines to cache these things? its a huge waste of compute and network.

Re: RCE Vulnerability in React and Next.js

#82

Post by quentindanjou »

punkbit wrote: post #65

Do you really need React Server Conponents or even Server Side Rendering?

It's very use-case dependent.

SSR can be a game-changer in domains like e-commerce. But completely useless for some other use case.

RSC advantages are a bit more complex to explain, because even a simple portfolio website would benefit from it. Contrary to the common belief created by long-term ReactJS dev, RSC simplifies a lot of the logic. Adapting existing code to RSC can be quite a mess and RSC is a big change of mindset for anybody used to ReactJS.

Re: RCE Vulnerability in React and Next.js

#83

Post by cluckindan »

sophiebits wrote: post #52
coffeecoders wrote: post #35

This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…

The endpoint is not whatever the client asks for. It's marked specifically as exposed to the user with "use server". Of course the people who designed this recognize that this is designing an RPC system. A similar bug could be introduced in the implementation of other RPC systems too. It's not entirely specific to this design. (I contribute to React but not really on RSC.)

”use server” is not required for this vulnerability to be exploitable.

Re: RCE Vulnerability in React and Next.js

#84

Post by azangru »

halflife wrote: post #61
paulhebert wrote: post #56

Earlier quoted context omitted.

I wish React wasn’t the “default” framework. I agree that the developer experience provided by the compiler model used in Svelte and React is much nicer to work with

IMO angular provides such a great experience developing. They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated. And what they DO add? Only things that improve dev exp

> They had minimal API changes in the last 10 years

The 1 to 2 transition was one hell of a burn though; people are probably still smarting...

Re: RCE Vulnerability in React and Next.js

#85

Post by baobun »

zackmorris wrote: post #80
halflife wrote: post #54

Why does the react development team keeps investing their time on confusing features that only reinvent the wheel and cause more problems than solve? What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering? Why won’t they invest more on solving the developer experience that took a nosedive when hooks were introduced? They finally added a compile…

I couldn't agree more. I'll probably switch from React to something like ArrowJS in my personal work: https://www.arrow-js.com/docs/ It makes it easy to have a central JSON-like state object representing what's on the page, then have components watch that for changes and re-render. That avoids the opaqueness of Redux and promise chains, which can be difficult to examine and debug (unless we add browser extensions for…

> I also had the same experience with the magic convention over configuration in Ruby.

I'm not sure what this is a reference to? Is it actually about Rails?

Re: RCE Vulnerability in React and Next.js

#86

Post by cluckindan »

halflife wrote: post #58
paularmstrong wrote: post #55

Earlier quoted context omitted.

> What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering? RSC is their solution to not being able to figure out how to make SSR faster and an attempt to reduce client-side bloat (which also failed)

Maybe if they compiled away their runtime like svelte and somewhat like angular, then running SSR would be faster.

SSR with CSR is a worst-of-both-worlds approach. It leads to brittle ”isomorphic” behaviors when the same code needs to handle both SSR and CSR, inevitable client-side ”hydration” mismatches and various other issues. The same code needs to fetch eagerly but minimally, but also use and update the server-provided data on the client-side.

Ultimately that so-called ”isomorphism” causes more numerous and difficult problems than it solves.

Re: RCE Vulnerability in React and Next.js

#87

Post by brown9-2 »

sophiebits wrote: post #52
coffeecoders wrote: post #35

This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…

The endpoint is not whatever the client asks for. It's marked specifically as exposed to the user with "use server". Of course the people who designed this recognize that this is designing an RPC system. A similar bug could be introduced in the implementation of other RPC systems too. It's not entirely specific to this design. (I contribute to React but not really on RSC.)

so any package could declare some modules as “use server” and they’d be callable, whether the RSC server owner wanted them to or not? That seems less than ideal.

Re: RCE Vulnerability in React and Next.js

#88

Post by halflife »

azangru wrote: post #84
halflife wrote: post #61

Earlier quoted context omitted.

IMO angular provides such a great experience developing. They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated. And what they DO add? Only things that improve dev exp

> They had minimal API changes in the last 10 years The 1 to 2 transition was one hell of a burn though; people are probably still smarting...

Well, the official statement is that 1 and 2 are 2 different frameworks. That’s why they were later named to angular JS and angular, to avoid confusion.

The migration path between angular 1 and 2 is the same as react and angular, it’s just glue holding 2 frameworks together

And that change happened 10 years ago

Re: RCE Vulnerability in React and Next.js

#89

Post by j45 »

coffeecoders wrote: post #41
j45 wrote: post #36

Earlier quoted context omitted.

For the layperson, does this mean this approach and everything that doesn't use it is not secure? Building a private, out of date repo doesn't seem great either.

Not quite. This isn’t saying React or Next.js are fundamentally insecure in general. The problem is this specific "call whatever server code the client asks" pattern. Traditional APIs with defined endpoints don’t have that issue.

I’m not asking if it’s fundamentally insecure.

Architecturally there appears to be an increasingly insecure attack surface appearing in JavaScript at large, based on the insecurities in mandatory dependencies.

If the foundation and dependencies of react has vulnerabilities, react will have security issues indirectly and directly.

This explicit issue seems to be a head scratcher. How could something so basic exist for so long?

Again I ask about react and next.js from their perspective or position of leadership in the JavaScript ecosystem. I don’t think this is a standard anyone wants.

Could there be code reviews created for LLMs to search for issues once discovered in code?

Re: RCE Vulnerability in React and Next.js

#90

Post by [deleted] »

dizlexic wrote: post #75
coffeecoders wrote: post #35

This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…

They were warned. I don't see how this can be characterized as anything but sloppy.

[deleted]
Post reply on HN