在Next.js目标中寻找SSRF漏洞

Next.js：现代Web应用程序框架

Next.js是一个强大的基于React的开源框架，使开发人员能够构建快速、交互式且对SEO友好的Web应用程序。通过NPM每周有近1300万次下载，加上框架本身性质复杂，使其成为不友好入侵者的主要目标。

在本文中，我们将深入探讨广泛使用Next.js的目标中最常见的服务器端请求伪造漏洞。

让我们开始吧！

Next.js Image组件中的SSRF

图像优化在Web应用程序开发中是必须的。在网站任何地方加载大型未优化的图像资产通常会带来负面的SEO影响。这就是为什么Next.js推荐使用Next.js Image组件，这是一个在服务器端完成所有优化和缓存工作的服务器端组件。

为了使此组件工作，所有优化和图像处理必须在服务器端完成。当您在Next.js项目中包含Image组件时（通常默认情况下会这样做），您会暴露一个位于/_next/image的额外API端点。下次包含图像时，该图像的位置将被转发到API端点，执行所有优化工作，最后返回优化后的图像：

正如您在上图中所看到的，url参数看起来是测试服务器端请求伪造漏洞的完美位置。特别是因为Next.js支持通配符范围配置选项：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: '**',
      },
      {
        protocol: 'http',
        hostname: '**',
      }
    ],
  },
}

module.exports = nextConfig

开发人员这样做是为了允许从任何主机加载图像，却在不知不觉中引入了新的攻击向量。由于此安全配置错误允许我们代表易受攻击的服务器发出HTTP请求，这就构成了典型的（盲）服务器端请求伪造漏洞。

即使没有指定通配符，您仍应尝试探测潜在的白名单主机（如CDN），因为负责拉取图像初始版本的底层Image组件默认遵循重定向。实际上，简单的开放URL重定向漏洞可能为到达任何任意主机开辟途径。

Next.js中间件中的SSRF（CVE-2025-57822）

Next.js中间件允许开发人员在响应返回给客户端之前运行代码。这在基于应用程序逻辑实现服务器端重定向、身份验证和授权检查时非常有用。然而，在某些情况下，开发人员可能无意中将未经清理的用户输入传递给中间件方法进行评估，从而引入服务器端请求伪造漏洞。

为了进一步理解根本问题并解释为什么这也是一个常见问题，我们必须查看一个简单的易受攻击实现示例。以下是我们之前举办的Intigriti CTF挑战中的一个易受攻击的中间件实现示例，该实现跟踪UTM参数：

当您仔细观察时，开发人员似乎将整个对象（包括未经清理的请求头）传递给了next()方法。这将使next()方法在返回响应之前评估所有头部，包括检查可能的由Location头部发起的内部重定向。例如，如果我们向易受攻击的应用程序发出带有任意Location头部的请求，实际上我们将使Next.js加载我们在Location头部中指定的请求资源。

这个未记录的漏洞在被供应商确认并分配CVE-2025-57822之前被忽视了多年。感谢安全研究员Dominik Prodinger的研究，我们了解到互联网上已识别出5,000多个可能受影响的主机。在测试Next.js应用程序时，建议包含对此特定CVE的检查。

通过Next.js Server Actions的SSRF（CVE-2024-34351）

Next.js Server Actions允许开发人员定义在服务器端运行的异步函数，可以直接从React组件调用，从而实现无缝的服务器端数据获取、变更和表单处理，无需自定义API路由或额外的后端样板代码。

最初由Assetnote的研究人员发现，Server Actions的不正确实现可能导致服务器端请求伪造。要使您的目标易受攻击，必须满足以下条件：

• Next.js（版本14.1.1或更低）必须在自托管环境中运行
• 您的Next.js目标需要使用Server Actions
• Server Action必须执行到相对路径的重定向

最后一个要求至关重要，因为Next.js v14.1.1及更早版本使用特定的验证过程将响应流式传输回客户端。框架首先向传入请求的host头部指定的主机发送HEAD请求，验证响应的content-type，然后继续进行GET请求以检索实际内容：

利用阶段需要配置一个自定义的OAST服务器，该服务器使用适当的content-type头部进行响应以绕过初始验证检查。

1. 第一个请求将触发易受攻击的Next.js Server Action组件向我们的OAST服务器发起HEAD HTTP请求（在Host头部中指定）
2. 当服务器随后收到GET请求时，我们使用包含目标资源（如AWS元数据端点URI）的302 HTTP重定向进行响应
3. 我们的OAST服务器配置为使用支持的content-type响应头部进行响应，这反过来会发起GET请求。当我们收到GET请求时，我们使用302状态代码进行响应

结论

Next.js是一个复杂的Web应用程序开发框架，简单的错误通常会引入安全缺陷，包括SSRF漏洞。在本文中，我们记录了Next.js目标中的几种服务器端请求伪造（SSRF）漏洞。

那么，您刚刚学到了有关在Next.js目标中利用SSRF漏洞的新知识……现在是时候将您的技能付诸实践了！浏览我们在Intigriti上的70多个公共漏洞赏金计划，谁知道呢，也许您就是下一个今天在我们这里获得赏金的人！