Next.js SSRF漏洞CVE-2024-34351深度剖析与防御实践

最新推荐文章于 2026-07-17 16:33:52 发布

原创

最新推荐文章于 2026-07-17 16:33:52 发布 · 381 阅读

1. 项目概述：一次针对Next.js框架的SSRF漏洞深度剖析

最近在安全圈里，关于Next.js的一个SSRF漏洞（CVE-2024-34351）讨论得挺热。作为一名长期混迹于前后端开发和安全研究的老兵，我习惯性地会去关注这些主流框架爆出的安全问题。Next.js作为React生态的“顶流”全栈框架，其安全性的风吹草动都牵动着无数开发者和安全研究员的神经。这个漏洞的特别之处在于，它并非源于开发者代码写得不好，而是框架本身在特定配置下，其内置的“图像优化”功能（ next/image ）存在缺陷，可能被攻击者利用，向内部网络发起请求，也就是我们常说的服务器端请求伪造（SSRF）。这可不是个小问题，想象一下，如果你的Next.js应用部署在云上，和数据库、缓存服务、管理后台在同一个内网，这个漏洞就可能成为攻击者刺探内网、甚至攻击内网服务的跳板。

简单来说，这个漏洞能做什么？它允许攻击者通过精心构造的请求，欺骗Next.js服务器代表攻击者去访问本应无法从外网直接访问的内部系统。比如，读取内网元数据服务（如AWS的169.254.169.254）来窃取云服务器凭证，或者探测内网其他服务的端口和接口。这个漏洞的CVSS评分不低，属于中高危级别，影响范围是特定版本的Next.js。对于开发者而言，理解这个漏洞的原理、复现过程以及修复方法，不仅是提升应用安全性的必修课，也是深入理解Next.js内部工作机制的一个绝佳窗口。接下来，我将结合我自己的复现过程，从漏洞原理、环境搭建、利用脚本编写到防御加固，为你完整拆解CVE-2024-34351。

2. 漏洞原理与影响范围深度解析

2.1 SSRF漏洞的核心机制与Next.js的“阿喀琉斯之踵”

要理解CVE-2024-34351，我们得先掰扯清楚两个东西：SSRF是什么，以及Next.js的 next/image 组件是怎么工作的。

SSRF，服务器端请求伪造，本质是一种“借刀杀人”的攻击手法。攻击者无法直接访问目标内网资源（比如公司的数据库管理后台 http://192.168.1.100:8080 ），但他发现有一个对外服务的Web应用（比如你的Next.js网站）可以帮他发请求。于是，他构造一个特殊的请求发给这个Web应用，比如请求一张图片，URL是 http://your-nextjs-site.com/api/image?url=http://192.168.1.100:8080 。如果这个Web应用傻乎乎地、不加任何校验就去访问这个 url 参数指定的地址，并把结果返回给攻击者，那么攻击者就相当于利用你的服务器作为代理，窥探到了内网服务的信息。

那么，Next.js的 next/image 组件是怎么卷入其中的呢？ next/image 是Next.js官方推出的、用于自动优化图片（如调整尺寸、转换格式、懒加载）的组件。为了优化性能，它通常会在服务器端（Node.js运行时）或构建时处理图片。当你在页面中使用``时，Next.js服务器会去抓取 src 指定的图片资源。关键在于，在 特定配置 下，这个抓取逻辑对目标URL的校验不够严格。

漏洞的根源在于 next/image 组件的“加载器”（loader）配置以及其对URL协议的处理。默认情况下，Next.js的图片优化API会遵循一些安全限制，比如默认只允许HTTPS和HTTP协议（防止 file:// 协议读取服务器本地文件）。然而，在漏洞版本中，当开发者使用了自定义的加载器，或者在某些边缘情况下，攻击者可以通过构造包含特殊字符或利用URL解析歧义的 src 值，绕过这些协议限制，让服务器去请求诸如 http://169.254.169.254/latest/meta-data/ （AWS实例元数据服务）或 http://localhost:8080/admin 这样的内部地址。

注意：这个漏洞不是说你用了 next/image 就一定有风险。它通常需要满足一些前置条件，比如运行在 nodejs 服务器运行时（而非静态导出），并且图片优化功能处于启用状态。在纯静态站点（ output: 'static' ）或正确配置了严格域名白名单的情况下，风险会大大降低。

2.2 CVE-2024-34351 的具体影响版本与场景

根据官方安全公告和我的测试，这个漏洞主要影响 Next.js 13.x 至 14.x 的某些版本 。确切地说，在Next.js处理图片优化请求的底层HTTP客户端库中，对重定向（Redirect）的处理或URL标准化过程存在缺陷，可能导致服务器跟随重定向到内部网络地址。

一个典型的攻击场景如下：

攻击者发现一个使用Next.js且开启了图片优化功能的网站。
该网站有一个图片展示功能，图片URL部分可控（例如，来自用户上传的URL，或通过查询参数传递）。
攻击者提交一个指向 可控的恶意服务器 的URL作为图片源，例如 http://attacker.com/redirect-to-internal 。
这个恶意服务器 attacker.com 返回一个HTTP 302重定向响应，Location头指向内网地址，如 http://169.254.169.254/latest/meta-data/ 。
存在漏洞的Next.js服务器在优化图片时，会“忠实”地跟随这个重定向，向内部元数据服务发起请求。
攻击者通过观察图片加载的错误信息、响应时间差异，或者如果元数据服务返回了结构化的文本/JSON（在某些配置下可能被部分返回或通过错误信息泄露），就能间接获取到敏感的内部信息。

这个漏洞的影响是实实在在的。对于部署在云环境（AWS, GCP, Azure）的Next.js应用，攻击者可能窃取实例的IAM角色凭证、安全组信息等。对于企业内网应用，可能探测到Redis、MySQL管理界面、Jenkins等内部系统的存在，为进一步的攻击铺路。

3. 漏洞复现环境搭建与配置

纸上谈兵终觉浅，绝知此事要躬行。要真正理解一个漏洞，亲手把它复现出来是最好的方式。下面我就带你一步步搭建一个存在CVE-2024-34351漏洞的Next.js测试环境。

3.1 创建存在漏洞的Next.js应用

首先，我们需要一个特定版本的Next.js。为了复现，我们可以选择一个已知受影响的版本，比如 14.0.4 。打开你的终端，开始操作：

# 1. 创建一个新的Next.js应用，并指定版本
npx create-next-app@14.0.4 vulnerable-next-ssrf
cd vulnerable-next-ssrf

# 2. 创建一个简单的页面，其中包含一个使用 next/image 的组件
# 编辑 app/page.js 文件

为了让漏洞更容易被触发，我们创建一个简单的页面，它接受一个查询参数作为图片URL。编辑 app/page.js 文件：

import Image from 'next/image';

export default function Home({ searchParams }) {
  // 从查询参数中获取图片URL，默认为一个无害的外部图片
  const imageUrl = searchParams?.url || 'https://via.placeholder.com/300';

  return (
    <main>
      <h1>Next.js SSRF 漏洞复现页面 (CVE-2024-34351)</h1>
      <p>当前图片源: {imageUrl}</p>
      <div style={
  
  { position: 'relative', width: '300px', height: '200px' }}>
        {/* 关键：使用 next/image 组件加载可能由用户控制的URL */}
        <Image
          src={imageUrl}
          alt="Vulnerable Image"
          fill
          style={
  
  { objectFit:

标签