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

51–60 of 276 posts

Re: RCE Vulnerability in React and Next.js

#51

Post by TranquilMarmot »

leptons wrote: post #40
dzonga wrote: post #24

till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.

>now cz of the complexity I refuse to work with react. What do you like to work with now?

Right - you can NOT tell me that a sufficiently complex application using HTMX is easier to reason about than React. I've had to deal with a complex HTMX codebase and it is a nightmare.

Re: RCE Vulnerability in React and Next.js

#52

Post by sophiebits »

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

Re: RCE Vulnerability in React and Next.js

#53

Post by ptx »

switz wrote: post #38
dzonga wrote: post #24

till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.

They lend you optionality of when and where you want your code to run. Plus it enables you to define the server/client network boundary where you see fit and cross that boundary seamlessly. It's totally fine to say you don't understand why they have benefits, but it really irks me when people exclaim they have no value or exist just for complexity's sake. There's no system for web development that provides the develo…

But is it a good idea to make it seamless when every crossing of the boundary has significant implications for security and performance? Maybe the seam should be made as simple and clear as possible instead.

Re: RCE Vulnerability in React and Next.js

#54

Post by halflife »

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 compiler, but instead of going the svelte route of handling the entire state, it only adds memoization?

If I can send a direct message to the react team it would be to abandon all their current plans, and work on allowing users to write native JS control flows in their component logic.

sorry for the rant.

Re: RCE Vulnerability in React and Next.js

#55

Post by paularmstrong »

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…

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

Re: RCE Vulnerability in React and Next.js

#56

Post by paulhebert »

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

Re: RCE Vulnerability in React and Next.js

#57

Post by paulhebert »

ptx wrote: post #53
switz wrote: post #38

Earlier quoted context omitted.

They lend you optionality of when and where you want your code to run. Plus it enables you to define the server/client network boundary where you see fit and cross that boundary seamlessly. It's totally fine to say you don't understand why they have benefits, but it really irks me when people exclaim they have no value or exist just for complexity's sake. There's no system for web development that provides the develo…

But is it a good idea to make it seamless when every crossing of the boundary has significant implications for security and performance? Maybe the seam should be made as simple and clear as possible instead.

Yep! It’s really hard to reason in Next about when things happen on the server vs client. This makes it harder to make things secure.

You can create clean separation in your code to make this easier to understand but it’s not well enforced by default.

Re: RCE Vulnerability in React and Next.js

#58

Post by halflife »

paularmstrong wrote: post #55
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…

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

Re: RCE Vulnerability in React and Next.js

#59

Post by root_axis »

ascorbic wrote: post #28
nine_k wrote: post #22

Earlier quoted context omitted.

The packages affected, like [1], literally say: > Experimental React Flight bindings for DOM using Webpack. > Use it at your own risk. 311,955 weekly downloads though :-| [1]: https://www.npmjs.com/package/react-server-dom-webpack

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.

Re: RCE Vulnerability in React and Next.js

#60

Post by ethanwillis »

TranquilMarmot wrote: post #51
leptons wrote: post #40

Earlier quoted context omitted.

>now cz of the complexity I refuse to work with react. What do you like to work with now?

Right - you can NOT tell me that a sufficiently complex application using HTMX is easier to reason about than React. I've had to deal with a complex HTMX codebase and it is a nightmare.

Right - you can NOT tell me that a sufficiently simple application using React is easier to reason about than HTMX. I've had to deal with a simple React codebase and it is a nightmare.

They don't address the exact same markets.

Post reply on HN