The React2Shell Story | Hacker News Reader

The React2Shell Story

lachlan.nz

225 pointsmufeedvh47 comments

R2S was a painful one, but Lachlan was a dream of a security researcher to partner with. Not just from a responsible disclosure POV, but things like hopping on multiple calls with Meta and our team to help us validate remediations. Thank you Lachlan for helping make the internet safer (and great job on figuring out this 'labyrinth' of a vulnerability)

A great read. Sylvie's writeup is good too: https://sylvie.fyi/posts/react2shell/

I'm still yet to be convinced React Server Components are anything but a disaster to the developer experience. Mixing backend and frontend without a clear boundary is terrible for any codebase beyond a handful of contributors.

But it is so cool!

I really don't understand why people complain about Spring or ASP.NET annotations, and then go running to Next.js with its useXXX and import magic.

Spring is a very good analogy to what useX hooks were to react. Thank you for this.

A different dsl inside Java or js implemented with duct tape in a dynamic way. React was screaming for a real typed functional language like elm imo, instead of a kludge of abstractions enforced by linters and weekly-changing best practices. React should have been "finished" like jquery. It is possible to develop something solid in it of course, but elegant it is not. Full of leaky abstractions.

The prime motivator for it is a certain user experience. I'm not sure they've found the best developer experience for providing that user experience, but I'm also not sure that a better DX is possible - the whole concept has quite a bit of inherent complexity, I'm afraid.

(The conclusion could, of course, also be that it's just not feasible to create that kind of user experience. Luckily, traditional patterns still work just as well.)

If you look at the origins, the primary motivation was finding a way to get a good data loading developer experience without having to adopt Relay and GraphQL.

I personally don't agree, and my experience is that RSCs embrace the inherent complexity of building websites. All websites span the server and the client to some extent. Giving you the tools to wield those boundaries is actually a bid for developer autonomy and flexible control over user experience.

It is complex because the domain is complex. Though it requires a deep understanding of the web as a platform, most high-level websites could net-benefit from the ideas behind RSCs. I don't find it to be quite as much of a footgun as most people would suggest, but if you don't understand both server and client in a deep manner it is, of course, confusing.

Happy to dig in deeper for anyone who wants to have an honest discussion about the benefits and drawbacks without dropping into FUD. Even if you decide it's not for you, all web developers could glean something from their model.

It's also always worth noting that RSCs don't require a server, and still bring value without one.

Nice read!

I love the "we are so back" vs. "it's so over" graph. Defines so much of this type of work. "Wow? ... nah... WOW?! ... nah..."

I wish this site respected prefers-reduced-motion. The dots on the background give me motion sickness while trying to read. Thank goodness for Firefox reader mode.

>> Amazingly, despite being a weekend, the Meta team triaged, reproduced, and confirmed my submission in around 17 hours.

Incredible. Realize what you have done from start to finish (with confirmation) in < 24 hours.

Side note: A few weeks ago I started to see floaters in my eyes and the background for your site is making my brain go haywire. Also a tad bit distracting while trying to read the article.

Really cool article btw.

Haha, nice.

One correction: The link in "To be honest, I'm not even sure if I understand it, but it's on my GitHub." goes to the wrong file (01 instead of 00).

I was really surprised when this hit, and I discovered the protocol was essentially undocumented / unspecified. I was trying to find indicators of compromise and that was made more difficult by the lack of documentation.

It was really helpful that they had coordinated with WAF providers like cloud flare ahead of disclosure to put rules in place though.

What a great write-up. Thanks for sharing how you found this fascinating vulnerability and exploit.

Boy I loved this write up, and really loved Sylvie’s, which gives a peek into the economic side of this white hat hacking — prepping, safety, wondering who you trust, preparing to claim as many bug bounties as possible.

I was struck by the very sensible economic filter: “who is vulnerable that has a bug bounty program?” Incredibly good reminder that you should have a bug bounty program; otherwise, nobody might call you. Until, you know, you’ve been compromised.

The first exploit looks somewhat like an elaborate json version of the bf language.

Really nice writeup. Would be intresting If an ai can find such vulns, too.

> But that afternoon, fueled by curiosity and frustration, I felt a switch flip in my brain, and I dived head-first into a rabbit hole with no turning back.

https://xkcd.com/356/

It happens to all of us. However, I think it’s much easier nowadays with LLMs for something productive like this to come out of it. I can notice something wrong and triage or even fix it before the point where I’d normally start to feel the subconscious pull of opportunity cost telling me to stop.

Whoda thunkit that

- blurring the lines between client code and server code

- creating a brand new protocol for communication between trusted and untrusted actors

- and with all of that allow the protocol to serialize code and not just primitives

Would be a tremendously stupid idea. And for what? To lock developers further into the react ecosystem. What a shitshow react continues to be.

> And for what? To lock developers further into the react ecosystem.

It was a clear bait and switch scam, that is still going on.

Reply on news.ycombinator.com