TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Next.js and the corrupt middleware: the authorizing artifact

94 点作者 ash大约 2 个月前

9 条评论

kfarr大约 2 个月前
Timeline is interesting<p>Timeline:<p>02&#x2F;27&#x2F;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)<p>03&#x2F;01&#x2F;2025: second email sent explaining that all versions were ultimately vulnerable, including the latest stable releases<p>03&#x2F;05&#x2F;2025: initial response received from the Vercel team explaining that versions 12.x were no longer supported&#x2F;maintained (probably hadn’t read the second email&#x2F;security advisory template indicating that all were vulnerable)<p>03&#x2F;05&#x2F;2025: another email sent so that the team could quickly take a look at the second email&#x2F;security advisory template<p>03&#x2F;11&#x2F;2025: another email sent to find out whether or not the new information had been taken into account<p>03&#x2F;17&#x2F;2025: email received from the Vercel team confirming that the information had been taken into account<p>03&#x2F;18&#x2F;2025: email received from the Vercel team: the report had been accepted, and the patch was implemented. Version 15.2.3 was released a few hours later, containing the fix (+backports)<p>03&#x2F;21&#x2F;2025: publication of the security advisory
评论 #43453617 未加载
评论 #43453827 未加载
评论 #43453524 未加载
iterateoften大约 2 个月前
Maybe im misunderstanding how people are building endpoints these days, but every post about this I see how it can bypass auth.<p>Wouldn’t this bypass auth only for sites where auth is true&#x2F;false?<p>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.<p>Or if you are serving an admin page you check that the user is an admin.<p>I honestly find it more astounding that people put an admin security check to check the url of a page and redirect away in a middleware and no security on the views themselves.<p>Is this form of checking paths in middleware officially from NextJS or did people just get lazy? Seems like the worst way to build auth I could ever dream up across any framework or language.<p>If a middleware is bypassed all endpoints should return empty responses. In my nextjs apps the middleware is simply a convenience method for the user if they are logged out they get redirected to the login page. But all api endpoints check for the active user and serve objects relative to the user.
评论 #43453868 未加载
评论 #43453749 未加载
评论 #43453785 未加载
评论 #43453592 未加载
评论 #43453651 未加载
评论 #43453732 未加载
nine_k大约 2 个月前
What surprises me here is that the client side of the request &#x2F; 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.<p>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?<p>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.
simonw大约 2 个月前
The vulnerability can be understood through this code snippet:<p><pre><code> const subreq = params.request.headers[&#x27;x-middleware-subrequest&#x27;]; const subrequests = typeof subreq === &#x27;string&#x27; ? subreq.split(&#x27;:&#x27;) : []; &#x2F;&#x2F; ... for (const middleware of this.middleware || []) { &#x2F;&#x2F; ... if (subrequests.includes(middlewareInfo.name)) { result = { response: NextResponse.next(), waitUntil: Promise.resolve(), }; continue; } } </code></pre> Pass an x-middleware-subrequest HTTP header with a colon-separated list of middleware names to skip.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;vercel&#x2F;next.js&#x2F;blob&#x2F;v12.0.7&#x2F;packages&#x2F;next&#x2F;server&#x2F;next-server.ts#L686" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vercel&#x2F;next.js&#x2F;blob&#x2F;v12.0.7&#x2F;packages&#x2F;next...</a>
评论 #43466576 未加载
kawsper大约 2 个月前
Does anyone know which versions of Next.js that is supported?<p>I don&#x27;t seem to be able to find a promise from Vercel, but <a href="https:&#x2F;&#x2F;endoflife.date&#x2F;nextjs" rel="nofollow">https:&#x2F;&#x2F;endoflife.date&#x2F;nextjs</a> mentions that 15 and 14 gets security support.
ldjkfkdsjnv大约 2 个月前
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.<p>Vercel to me seems like it is run by hype men, and the CEO is certainly technical, but these people are not in the weeds in the way they come off.
评论 #43453662 未加载
评论 #43453697 未加载
soulchild77大约 2 个月前
This very recent PR updates the docs to basically remove all common (and previously recommended) middleware use-cases, rendering them almost completely useless:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;vercel&#x2F;next.js&#x2F;pull&#x2F;77438" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vercel&#x2F;next.js&#x2F;pull&#x2F;77438</a>
rohan_大约 2 个月前
Most don&#x27;t understand this issue:<p>Auth middleware is used for _routing_ (e.g. if you&#x27;re not signed-in, you&#x27;ll be redirected to the sign-in page).<p>This just means a 500 is thrown due to the auth() call returning null on the server.
评论 #43453724 未加载
johnnyAghands大约 2 个月前
Can someone tl;dr: why there is even logic to bypass middleware in the first-place, I feel like I&#x27;m missing something obvious here...
评论 #43453772 未加载
评论 #43453719 未加载