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

221–230 of 276 posts

Re: RCE Vulnerability in React and Next.js

#221

Post by jeroenhd »

j45 wrote: post #37
AgentK20 wrote: post #2

CVE 10.0 is bonkers for a project this widely used

The subjects of theses types of posts should report the CVSS severity as 10.0 so the PR speak can't simply deflect to what needs to be done.

Unfortunately, CVSS scores are gamified hard. Companies pay more money in bug bounty programs, so there's an incentive for bug bounty hunters to talk up the impact of their discovery. Especially the CVSS v3 calculation can produce some unexpected super high or super low scores.

While scores are a good way to bring this stuff to people's attention, I wouldn't use them to enforce business processes. There's a good chance your code isn't even affected by this CVE even if your security scanners all go full red alert on this bug.

Re: RCE Vulnerability in React and Next.js

#222

Post by __jonas »

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

No, unless you run the React Server Component runtime on your server, which you wouldn't do with a SPA, you would just serve a static bundle.

Re: RCE Vulnerability in React and Next.js

#223

Post by mexicocitinluez »

halflife wrote: post #71
danabramov wrote: post #63

Earlier quoted context omitted.

Server Components is not really related to SSR. I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a (ser…

Thanks for the comment Dan, I always appreciate you commenting and explaining in civility, and I’m sorry if I came a bit harsh. I understand the logic, but there are several issues I can think of. 1 - as I said, SSR and API layers are good enough, so investing heavily in RSC when the hooks development experience is still so lacking seems weird to me. React always hailed itself as the “just JS framework”, but you can’…

> React always hailed itself as the “just JS framework”,

I've literally never heard someone say "React is just a JS framework". They've said React uses JSX over templates. And that React has introduced functional components. But never heard someone say what you're claiming.

> but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.

This is wild. Yes you can. You can write regular JS in components. I can go build a component right now that uses JS (either with or without hooks). You're conflating the rules of hooks with the ability to use Javascript. Yes, there are rules. No, that doesn't mean you can no longer can write JS.

> i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed

Tradeoffs. Now each update needs to be rebuilt and redeployed. I don't have that problem in React.

> better templating ability for control flows

Better templating? React uses JSX. Are you saying there exists a better way to control flows than if/else?

> signals, for proper reactive state

This has been debated ad-nauseum in the React community and everything has a trade-off. I wish people would stop saying this as if it's categorically correct. React is UI is a function of state. Singlars would totally break the current mental model of React. Data flows down. This change would come with tradeoffs.

Re: RCE Vulnerability in React and Next.js

#224

Post by mexicocitinluez »

mvdtnz wrote: post #67
javaking wrote: post #32

I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb

There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs. This kind of thing is the predictable result.

> There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs.

First, "same code on the client and the serve" is wrong. Since when do RSC's run on both the client and the server?

Also, you honestly believe that wanting to use the same language across paradigms is a "coding bootcamp" thing lol? That something like Blazor was born out of a coding bootcamp?

Have you ever built a web app? Both front and back end? Have you ever had to deal with the tension of duplicating code? Models, validation, ideas?

If you answered yes to those questions but still don't see how de-duplicating code like that can be important, than I'm 100% positive you're still in the boot camp.

Re: RCE Vulnerability in React and Next.js

#225

Post by jeroenhd »

Levitating wrote: post #154
venturecruelty wrote: post #123

Earlier quoted context omitted.

Yes. Web applications were impossible before these libraries.

If you truly believe that than we must really be moving backwards

I think they have a point, before cgi-bin it was almost impossible to have a real web application. It took a decade for server-side rendering to fall out of favour. Flash websites and Gmail starting to become seriously interactive in the mid 2000s were the start of frontend-first web applications, but even those relied on the backend to provide them with an initial data set to make performance usable.

Re: RCE Vulnerability in React and Next.js

#227

Post by rglover »

jacquesm wrote: post #122
ivanjermakov wrote: post #104

Earlier quoted context omitted.

Inevitable when the line between the client and the server is blurred this much. RCE in a UI library is not a phrase you hear often.

Maybe one day we'll look back at JavaScript and conclude it was a gigantic mistake ship unaudited executable code to a few billion people every day.

JavaScript is fine, it's what and how people build with it that's the problem. It was never meant to be a systems language but we're desperate to make it one.

Re: RCE Vulnerability in React and Next.js

#228

Post by jacquesm »

rglover wrote: post #227
jacquesm wrote: post #122

Earlier quoted context omitted.

Maybe one day we'll look back at JavaScript and conclude it was a gigantic mistake ship unaudited executable code to a few billion people every day.

JavaScript is fine, it's what and how people build with it that's the problem. It was never meant to be a systems language but we're desperate to make it one.

In light of this discussion:

https://news.ycombinator.com/item?id=46141771

that is an interesting observation.

Re: RCE Vulnerability in React and Next.js

#229

Post by halflife »

mexicocitinluez wrote: post #223
halflife wrote: post #71

Earlier quoted context omitted.

Thanks for the comment Dan, I always appreciate you commenting and explaining in civility, and I’m sorry if I came a bit harsh. I understand the logic, but there are several issues I can think of. 1 - as I said, SSR and API layers are good enough, so investing heavily in RSC when the hooks development experience is still so lacking seems weird to me. React always hailed itself as the “just JS framework”, but you can’…

> React always hailed itself as the “just JS framework”, I've literally never heard someone say "React is just a JS framework". They've said React uses JSX over templates. And that React has introduced functional components. But never heard someone say what you're claiming. > but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing…

I’ve heard, especially during the first few years when react was introduced, that you don’t need templating, compiler, or anything special to write react, “it’s just JS”.

Of course you CAN write anything you want inside a component, but then it breaks, or has awful performance. To write components the proper way you can’t use any control flows with state management, you need to keep remembering which are the correct dependencies to recreate state, it makes components 20% BL and 80% react logic.

You can’t use if-else in JSX, since only expressions are allowed. So you need to create nested ternaries, which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.

And regarding signals, preact is using it and it doesn’t seem to break anything there.

Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.

Re: RCE Vulnerability in React and Next.js

#230

Post by nedt »

selfmodruntime wrote: post #178
zackmorris wrote: post #80

Earlier quoted context omitted.

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…

> do we really need this when Javascript has template literals now yea? JSX is much more than templating.

But then there are packages like htm that are doing basically the same thing with just tagged templates.
Post reply on HN