Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js and the corrupt middleware: the authorizing artifact

zhero-web-sec.github.io

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Next.js and the corrupt middleware: the authorizing artifact

#11

Post by czk »

ldjkfkdsjnv wrote: post #7

The culture of security within FAANG could not be more opposite than the way that vercel handled this. In big tech, this would have been looked at in 48 hours, and across thousands of systems all oncalls would have been paged to do an emergency deploy. Probably within 5 days, almost the whole company would have deployed the patch. Vercel to me seems like it is run by hype men, and the CEO is certainly technical, but…

Also worth noting that this commit in Dec 2024 previously added a bunch of internal headers (aside from this one) to a restricted external access list (one of them was vulnerable to SSRF) and there was never a CVE for it.

https://github.com/vercel/next.js/pull/73482/files

Source: https://news.ycombinator.com/item?id=43449986

Re: Next.js and the corrupt middleware: the authorizing artifact

#12

Post by johnnyAghands »

edoceo wrote: post #4
johnnyAghands wrote: post #3

Earlier quoted context omitted.

What is intersting?

The lag & missing key details

Ah ok, yeah.. unfortnutely this type of lag/mismgmt is pretty common once a company gets big enough. Often times the right people don't get involved on first-pass... even at tech-first companies like this -- though at that point perhaps you're no longer tech-first :/

Re: Next.js and the corrupt middleware: the authorizing artifact

#15

Post by tengbretson »

ldjkfkdsjnv wrote: post #7

The culture of security within FAANG could not be more opposite than the way that vercel handled this. In big tech, this would have been looked at in 48 hours, and across thousands of systems all oncalls would have been paged to do an emergency deploy. Probably within 5 days, almost the whole company would have deployed the patch. Vercel to me seems like it is run by hype men, and the CEO is certainly technical, but…

Maybe they based their on-call protocol on what people say they want in hn threads.

Re: Next.js and the corrupt middleware: the authorizing artifact

#17

Post by simonw »

rohan_ wrote: post #14

Most don't understand this issue: Auth middleware is used for _routing_ (e.g. if you're not signed-in, you'll be redirected to the sign-in page). This just means a 500 is thrown due to the auth() call returning null on the server.

That depends entirely on how you implemented your middleware.

This vulnerability also isn't explicitly about auth: it's about attackers being able to send a colon separated list of middleware to skip. That could affect applications in all kinds of unexpected ways depending on what they are using middleware for and how they designed their application.

Re: Next.js and the corrupt middleware: the authorizing artifact

#18

Post by hombre_fatal »

iterateoften wrote: post #5

Maybe im misunderstanding how people are building endpoints these days, but every post about this I see how it can bypass auth. Wouldn’t this bypass auth only for sites where auth is true/false? I’ve never worked on a site were auth is a boolean. Auth is always a relative. The middleware is only there to identify the user. Then when querying for objects, you query objects related to that user. Or if you are serving a…

I don’t think it really matters. All you have to do is write middleware or handlers that assume upstream middleware have run, and then that’s vulnerable to this attack.

For example it’s common to write middleware on /admin so that all of your /admin/* handlers don’t have to repeat the same authz logic. And the platform breaking invariants that you should be able to depend on is why it’s a security bug.

Re: Next.js and the corrupt middleware: the authorizing artifact

#20

Post by Etheryte »

iterateoften wrote: post #5

Maybe im misunderstanding how people are building endpoints these days, but every post about this I see how it can bypass auth. Wouldn’t this bypass auth only for sites where auth is true/false? I’ve never worked on a site were auth is a boolean. Auth is always a relative. The middleware is only there to identify the user. Then when querying for objects, you query objects related to that user. Or if you are serving a…

This attack isn't only about auth, auth is just the most drastic obvious example. Middleware is often used for a wide range of sanity checks. You could bypass, say, limit checks and ask the server to return an infinite number of items per page, quickly overloading the server and resulting in DoS.
Post reply on HN