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

21–30 of 38 posts

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

#21

Post by simonw »

johnnyAghands wrote: post #13

Can someone tl;dr: why there is even logic to bypass middleware in the first-place, I feel like I'm missing something obvious here...

It's quite common for server-side web frameworks to send a single request through their stack multiple times / especially when there is any form of "middleware" concept involved.

Often there's a need to skip some middleware on the second or third time through.

I've built systems in the past that do all sorts of re-dispatching.

One example: in development my API might live at /api/... but in production I might use api.my.site - with middleware that detects that host, rewrites the incoming request to add that /api/ prefix and then runs it though the stack again.

Authentication is a very common way this pattern is applied - check cookies / authorization headers / whatever, then add the authenticate user to the request somehow and re-dispatch the request through the stack so other layers can see who the user is.

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

#22

Post by simonw »

johnnyAghands wrote: post #12
edoceo wrote: post #4

Earlier quoted context omitted.

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 :/

Companies that get large enough to have a dedicated security team can often reverse this trend.

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

#23

Post by ljm »

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 know how to put this any other way but my experience with NextJS or just JS-first full stack is that they are still first and foremost a tech stack for frontend devs and the backend piece in that context is an afterthought.

I’ve worked on a few in my time and ‘API routes’ were rarely, if ever, authenticated, and there wouldn’t be a consistent strategy for data access. If anything, everything was built in the context of satisfying a react hook and getting on with the UI.

But I don’t squarely blame developers for it, it’s more like an inverted full stack where the browser is first class and the serverless edge SSR ISG SSG app router component craziness does not help you build out a stable API. Does sell a hell of a lot of SaaS though.

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

#24

Post by nine_k »

kfarr wrote: post #2

Timeline is interesting Timeline: 02/27/2025: vulnerability reported to the maintainers (specifying that only versions between 12.0.0 and 12.0.7 were vulnerable, which was our understanding at the time) 03/01/2025: second email sent explaining that all versions were ultimately vulnerable, including the latest stable releases 03/05/2025: initial response received from the Vercel team explaining that versions 12.x were…

OK, tangentially: let's assume that Next is poorly maintained; what are some good alternatives? Of course everything that Next does can be assembled by hand from various smaller modules on top of Express, or similar. What are some more cohesive sets?

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

#26

Post by flufluflufluffy »

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…

> “Is this form of checking paths in middleware officially from NextJS or did people just get lazy?”

This is a common way to implement auth in many frameworks, not just JS ones. Off the top of my head I know that Laravel (PHP) does it this way. I guess you could call it “being lazy” but most people would refer to it using the age-old software engineering terms “don’t repeat yourself” and “separation of concerns.”

The authentication middleware can choose to redirect or not based on many things: did the user provide the correct credentials, does the user have the necessary permissions to access the requested resource, etc… And you can put all the logic for determining those many things in a single place, so that it can easily be updated. Individual routes can remain as they are, and you don’t have to worry about forgetting to implement some part of the auth checking logic on one of them.

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

#27

Post by the_mitsuhiko »

simonw wrote: post #21
johnnyAghands wrote: post #13

Can someone tl;dr: why there is even logic to bypass middleware in the first-place, I feel like I'm missing something obvious here...

It's quite common for server-side web frameworks to send a single request through their stack multiple times / especially when there is any form of "middleware" concept involved. Often there's a need to skip some middleware on the second or third time through. I've built systems in the past that do all sorts of re-dispatching. One example: in development my API might live at /api/... but in production I might use api…

While you are generally right here I wonder how common this is with middlewares. Many have order dependencies and there are normally no loops involved. I don’t think I have come across this for middlewares at least. Kinda curious about the particular motivation here.

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

#28

Post by simonw »

the_mitsuhiko wrote: post #27
simonw wrote: post #21

Earlier quoted context omitted.

It's quite common for server-side web frameworks to send a single request through their stack multiple times / especially when there is any form of "middleware" concept involved. Often there's a need to skip some middleware on the second or third time through. I've built systems in the past that do all sorts of re-dispatching. One example: in development my API might live at /api/... but in production I might use api…

While you are generally right here I wonder how common this is with middlewares. Many have order dependencies and there are normally no loops involved. I don’t think I have come across this for middlewares at least. Kinda curious about the particular motivation here.

Yeah I've been contemplating this with my own Datasette project recently: it doesn't have an official mechanism for "redispatch this request from the root again" but I've been tempted to add one.

My GraphQL plugin for example works by firing off internal requests against Datasette's REST API and I ended up needing some gnarly hacks to get authentication to work with that.

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

#29

Post by nine_k »

What surprises me here is that the client side of the request / response is not considered a cunning, bitter enemy, as it should be. Why is x-middleware-subrequest even accepted in production? Why is x-middleware-rewrite even returned? They are instrumental to the attack, and the client has no business accessing them, ever, in my book.

If these headers are only expected to be available within a trusted zone, and some fronting HTTP server should strip them from incoming requests and outgoing responses, why are they named like regular HTTP headers, and not in some scary, easy-to-filter-way, like x-INTERNAL-ONLY-middleware-something?

To my mind, the server should accept the bare minimum of headers needed to serve the request, and issue the minimum amount of headers to provide a well-formed response, while being completely opaque to the client. Any nifty diagnostics like x-middleware-rewrire belong to the logs; correlate by request ID. Any nifty internal processing tweaks in plain text, like x-middleware-subrequest, are, to my mind, bad architecture. If you need to pass such info between HTTP endpoints internally, use something like a JWT.

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

#30

Post by johnnyAghands »

the_mitsuhiko wrote: post #27
simonw wrote: post #21

Earlier quoted context omitted.

It's quite common for server-side web frameworks to send a single request through their stack multiple times / especially when there is any form of "middleware" concept involved. Often there's a need to skip some middleware on the second or third time through. I've built systems in the past that do all sorts of re-dispatching. One example: in development my API might live at /api/... but in production I might use api…

While you are generally right here I wonder how common this is with middlewares. Many have order dependencies and there are normally no loops involved. I don’t think I have come across this for middlewares at least. Kinda curious about the particular motivation here.

Yeah that was my understanding as well —- but I’m not a framework author so wasn’t sure if this was a common practice.

Trade-offs aside, I personally find the idea of re-running the request through the stack a bit hacky.

Post reply on HN