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)
owebmaster 1 days ago [-]
[flagged]
dang 17 hours ago [-]
You can't attack another user like this here, so please don't.
It's particularly bad when someone shows up to discuss their work and commenters take the opportunity to attack them. That's a mob dynamic, and we don't want those here.
React was ruined from the moment they abandoned class components and introduced hooks. Vercel is just continuing the trend of hype against common sense.
littlecranky67 22 hours ago [-]
You are probably a Javascript dev, not doing typescript? Classes were horrible to type for, especially when you tried higher-order components. Hooks removed so much clutter and friction and allows pretty well-typed components and higher order functions (i.e. hooks that return components).
Sankozi 20 hours ago [-]
Hooks made simple things simpler, but hard things harder, code with lots of boilerplate was replaced with code with leaky abstractions full of various workarounds - I don't think this is a good trade.
While I hate class component lifecycle methods they are much better than complex hook setups when solving more advanced problems.
b4ckup 18 hours ago [-]
Could you elaborate why you dislike lifecycle methods? I read this take a lot and I use mainly angular but did some smaller projects with react class components and with function components. I also think function components are very counter intuitive but I also never had anything against lifecycle methods.
Sankozi 4 hours ago [-]
They often require quite complex ifology for simple use cases. Also didmount and diduptade often needs to be overriden together only to have almost the same implementation. They also have some gotchas regarding state updating inside them.
halflife 20 hours ago [-]
Just having an interval inside a component used to be trivial, but with hooks becomes tedious. Only the barebones simple ultra basic stuff became simple. Everything else? Harder.
halflife 20 hours ago [-]
I am all around developer, working with typescript from at least 2015.
I’m not exactly sure what complication you mean. Lifecycle method sucks, yeah, but you replaced them with lifecycle hooks. So the same mental overhead but now in a pseudo stateless functions, with state full escape hatches.
epolanski 20 hours ago [-]
Yes, they were uglier but they had advantages that got lost such as an easy to control rendering life cycle.
Just opening dev tools on MIT-written big tech corps and startups confirms nobody is able to write good websites or applications that arent filled with performance and memory leaks.
ervine 23 hours ago [-]
I just don't understand this take, every time I hear it I wonder if people just haven't spent the time to adjust their mental model.
Hooks are IMO the best thing that happened to react.
pjmlp 22 hours ago [-]
I have spent more time than I wished for on React debugging tools, and useXXXX spaghetti calls.
ervine 21 hours ago [-]
You can write spaghetti with class components, too. Doesn't sound like a hooks issue to me.
halflife 19 hours ago [-]
Of course, the only question is in what way the programming language pushes you. You can TS code where every variable is assigned “any” type, that would void all type safety. Is it possible? Yes. But someone needs to bend the languages will to do that.
Classes have inherent state, and methods which encapsulate logic. That pushed you to create separate logic bundles.
Functions are callable scripts. There are no rules. I’ve seen too many components that invoke tens of hooks, and hundreds of lines of state management. Most classes I’ve seen never reached that. Were there classes that were too big? Of course, but at least there was logic separation with methods.
bobthepanda 19 hours ago [-]
The great sin of the migration to hooks was that the docs were so poorly written that everyone got into bad habits.
You can have self documenting state like class components in the form of reducers which are just state machines. But it is much later in the documentation.
pjmlp 21 hours ago [-]
I certainly can, but somehow it cooler to write lambdas upon lambdas, and other Haskellisms when using hooks.
ervine 20 hours ago [-]
I think we're just gonna agree to disagree. Cheers.
halflife 20 hours ago [-]
I’ve done plenty of hooks. Also class components. Also angular.
You are writing code for an object that is inherently stateful, in a stateless design pattern. Instead of embracing state, you crate escape hatches and plugins to tap into your state, and then more escape hatches inside those escape hatches to tap out.
It’s react rendering model leaking into your code. Let’s imagine react changes the rendering paradigm, and components are rendered once with only state updates. Almost all of your hooks become useless. The fact that you need to think about react internal every time you create a component is such a bad API choice that I’m amazed it still exists, and being expanded.
ervine 20 hours ago [-]
So your argument is that instead of explicit class component methods, hooks are implicit based on understanding the react rendering model?
I guess so - but react could also change (and I think did at some point) how their class methods work, how often they're triggered, and when.
I don't understand the stateless comment - hooks are as stateful as you make them, using useState or useContext or any of the other ways of maintaining data between renders.
halflife 19 hours ago [-]
Classes are inherently stateful. A class instance is a long lived object. Functions are not, a functions internal state is thrown the moment the function returns. What react ask you to do is to attach to external state inside the function, in other words, an un pure function, forego idempotency.
In class based components, you didn’t care how react works under the hood, except for the render method which is called by react. So the surface of code controlled by react was only what you included inside that method. In function components, the entire function is owned by the renderer, so you need to deeply understand how it works.
ervine 18 hours ago [-]
I guess I think it's table stakes to need to deeply understand how the framework you're using works. Lifecycle methods vs. hooks, you still gotta know what's doing what and why.
halflife 18 hours ago [-]
Of course, but that really depends on the level of expertise and the type of programmer you are, and to some extent, the attitude of the organization your in to code and refactoring.
When everyone around writes shit code, you don’t care. In hooks, it becomes much more critical.
ervine 17 hours ago [-]
No, writing shit in react is gonna be a nightmare regardless of paradigm. HoC, Class Components, render props, whatever - if you don't know what you're doing and react internals are magic to you, it's game over. Anyway, we can agree to disagree on hooks vs. classes. Cheers.
halflife 16 hours ago [-]
Agreed. In the end, I always say that every line of code has deadline in which it will be removed.
pjmlp 22 hours ago [-]
Spot on, incredible how OOP hate can mess up a framework.
Vercel, the only thing they have going for the app model mess, are the partnerships with SaaS vendors that make them the must go tooling.
However this will eventually come to an end.
ervine 21 hours ago [-]
It wasn't OOP hate, it was hatred of splitting functionality across a number of methods rather than putting it in a single (reusable, sharable!) hook and having your component consume it.
pjmlp 21 hours ago [-]
Yeah, because now is so much better....
I only touch React now, because of SaaS partnerships with Vercel.
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.
pjmlp 22 hours ago [-]
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.
mejutoco 17 hours ago [-]
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.
Vinnl 21 hours ago [-]
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.)
andrewingram 21 hours ago [-]
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.
switz 18 hours ago [-]
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.
nkrisc 22 hours ago [-]
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.
keyle 1 days ago [-]
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..."
sam1r 1 days ago [-]
>> 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.
phyzome 1 days ago [-]
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).
mnahkies 1 days ago [-]
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.
simonreiff 1 days ago [-]
What a great write-up. Thanks for sharing how you found this fascinating vulnerability and exploit.
vessenes 22 hours ago [-]
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.
tosti 21 hours ago [-]
The first exploit looks somewhat like an elaborate json version of the bf language.
mexicocitinluez 1 days ago [-]
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.
BlackEspresso 21 hours ago [-]
Really nice writeup. Would be intresting If an ai can find such vulns, too.
ryanschaefer 20 hours ago [-]
> 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.
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.
halflife 1 days ago [-]
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.
owebmaster 23 hours ago [-]
> And for what? To lock developers further into the react ecosystem.
It was a clear bait and switch scam, that is still going on.
Rendered at 11:45:57 GMT+0000 (Coordinated Universal Time) with Vercel.
It's particularly bad when someone shows up to discuss their work and commenters take the opportunity to attack them. That's a mob dynamic, and we don't want those here.
It also strictly worsens the site because it gives people a disincentive to contribute in precisely the areas they know the most about. I've been trying to explain this for years: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
While I hate class component lifecycle methods they are much better than complex hook setups when solving more advanced problems.
I’m not exactly sure what complication you mean. Lifecycle method sucks, yeah, but you replaced them with lifecycle hooks. So the same mental overhead but now in a pseudo stateless functions, with state full escape hatches.
Just opening dev tools on MIT-written big tech corps and startups confirms nobody is able to write good websites or applications that arent filled with performance and memory leaks.
Hooks are IMO the best thing that happened to react.
Classes have inherent state, and methods which encapsulate logic. That pushed you to create separate logic bundles.
Functions are callable scripts. There are no rules. I’ve seen too many components that invoke tens of hooks, and hundreds of lines of state management. Most classes I’ve seen never reached that. Were there classes that were too big? Of course, but at least there was logic separation with methods.
You can have self documenting state like class components in the form of reducers which are just state machines. But it is much later in the documentation.
You are writing code for an object that is inherently stateful, in a stateless design pattern. Instead of embracing state, you crate escape hatches and plugins to tap into your state, and then more escape hatches inside those escape hatches to tap out.
It’s react rendering model leaking into your code. Let’s imagine react changes the rendering paradigm, and components are rendered once with only state updates. Almost all of your hooks become useless. The fact that you need to think about react internal every time you create a component is such a bad API choice that I’m amazed it still exists, and being expanded.
I guess so - but react could also change (and I think did at some point) how their class methods work, how often they're triggered, and when.
I don't understand the stateless comment - hooks are as stateful as you make them, using useState or useContext or any of the other ways of maintaining data between renders.
In class based components, you didn’t care how react works under the hood, except for the render method which is called by react. So the surface of code controlled by react was only what you included inside that method. In function components, the entire function is owned by the renderer, so you need to deeply understand how it works.
When everyone around writes shit code, you don’t care. In hooks, it becomes much more critical.
Vercel, the only thing they have going for the app model mess, are the partnerships with SaaS vendors that make them the must go tooling.
However this will eventually come to an end.
I only touch React now, because of SaaS partnerships with Vercel.
Otherwise I pretend it doesn't even exist.
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.
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 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.)
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.
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..."
Incredible. Realize what you have done from start to finish (with confirmation) in < 24 hours.
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).
It was really helpful that they had coordinated with WAF providers like cloud flare ahead of disclosure to put rules in place though.
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.
Really cool article btw.
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.
- 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.
It was a clear bait and switch scam, that is still going on.