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

181–190 of 276 posts

Re: RCE Vulnerability in React and Next.js

#181

Post by isqueiros »

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…

> it’s trying to solve a problem category that traditionally requires explicitness, not magic.

i've been thinking basically this for so long, i'm kinda happy to be validated about this lol

Re: RCE Vulnerability in React and Next.js

#182

Post by benignslime »

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…

[dead]

Re: RCE Vulnerability in React and Next.js

#183

Post by ptx »

cluckindan wrote: post #33
ptx wrote: post #29

Earlier quoted context omitted.

It sounds related to me. The react.dev blog post [1] says that the vulnerability is > a flaw in how React decodes payloads sent to React Server Function endpoints and the react.dev docs for React Server Functions [2] say that > Server Components can define Server Functions with the "use server" directive [...] Client Components can import Server Functions from files that use the "use server" directive So it certainly…

No. You cannot find all vulnerable code by grepping for ”use server”, for instance.

I think the top-level comment was criticizing the entire feature (server functions) enabled by "use server". The vulnerability is in this feature, so (as I understand it) you're correct that grepping for "use server" won't find the vulnerable code, but if there was no such thing as "use server" the vulnerability wouldn't exist.

Re: RCE Vulnerability in React and Next.js

#184

Post by cluckindan »

sysguest wrote: post #179
cluckindan wrote: post #83

Earlier quoted context omitted.

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

wait I'm only using React for SPA (no server rendering) am I also vulnerable??????

Only if you are running a vulnerable version of Next.js server.

Re: RCE Vulnerability in React and Next.js

#185

Post by cluckindan »

brown9-2 wrote: post #87
sophiebits wrote: post #52

Earlier quoted context omitted.

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.

The vulnerability exists in the transport mechanism in affected versions. Default installs without custom code are also vulnerable even if they do not use any server components / server functions.

Re: RCE Vulnerability in React and Next.js

#186

Post by sysguest »

jacquesm wrote: post #118
tshaddox wrote: post #102

Earlier quoted context omitted.

To me it just looks like unacceptable carelessness, not an indictment of the alleged "lack of explicitness" versus something like gRPC. Explicit schemas aren't going to help you if you're so careless that, right at the last moment, you allow untrusted user input to reference anything whatsoever in the server's name space.

But once that particular design decision is made it is a question of time before that happens. The one enables the other. The fact that React embodies an RPC scheme in disguise is quite obvious if you look at the kind of functionality that is implemented, some of that simply can not be done any other way. But then you should own that decision and add all of the safeguards that such a mechanism requires, you can't bol…

this

I always felt server-action had too much "magic"

Re: RCE Vulnerability in React and Next.js

#187

Post by sysguest »

jacquesm wrote: post #120
rvnx wrote: post #96

Earlier quoted context omitted.

You can call anything, anytime, anywhere without restrictions or protection. Imagine these dozens of people, working at Meta. They sit at the table, they agree to call eval() and not think "what could go wrong"

Eval has been known to be super dangerous since before the internet grew up and went mainstream. It is so dangerous that to deploy stuff containing it should come with a large flashing warning whenever you run it.

hmm isn't eval is used in figurative-sense here eh?

maybe you should get some sleep

Re: RCE Vulnerability in React and Next.js

#188

Post by mxmzb »

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…

Nobody is using Redux any more, and it's even publically discouraged by the creator. It's a legacy system and including it in your problems list just makes me think you have no React experience and no idea what you are talking about (beyond technical yapping also Redux as a product still achieved what it tried to solve so your dx doesn't even matter).

Firebase in this context is just a database and how you poll data on client or server from it. Nonsensical reference again.

Post reply on HN