NextJS

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

Next.js 应用的一般架构

典型的文件结构

标准的 Next.js 项目遵循特定的文件和目录结构，以支持其像 routing、API endpoints 和静态资源管理等功能。下面是一个典型的布局：

my-nextjs-app/
├── node_modules/
├── public/
│   ├── images/
│   │   └── logo.png
│   └── favicon.ico
├── app/
│   ├── api/
│   │   └── hello/
│   │       └── route.ts
│   ├── layout.tsx
│   ├── page.tsx
│   ├── about/
│   │   └── page.tsx
│   ├── dashboard/
│   │   ├── layout.tsx
│   │   └── page.tsx
│   ├── components/
│   │   ├── Header.tsx
│   │   └── Footer.tsx
│   ├── styles/
│   │   ├── globals.css
│   │   └── Home.module.css
│   └── utils/
│       └── api.ts
├── .env.local
├── next.config.js
├── tsconfig.json
├── package.json
├── README.md
└── yarn.lock / package-lock.json

核心目录和文件

public/: 托管静态资源（如图片、字体等）。这里的文件可从根路径 (/) 访问。
app/: 应用的核心目录，包含 pages、layouts、components 和 API routes。采用 App Router 范式，支持高级路由功能及服务端/客户端组件的分离。
app/layout.tsx: 定义应用的根布局，包裹所有页面并提供一致的 UI 元素，如 headers、footers 和导航栏。
app/page.tsx: 作为根路由 / 的入口，渲染主页。
app/[route]/page.tsx: 处理静态与动态路由。app/ 中的每个文件夹代表路由段，文件夹内的 page.tsx 对应该路由的组件。
app/api/: 包含 API 路由，可用于创建处理 HTTP 请求的 serverless 函数。该目录取代了传统的 pages/api。
app/components/: 存放可复用的 React 组件，可在不同页面和布局间使用。
app/styles/: 包含全局 CSS 文件与用于组件作用域样式的 CSS Modules。
app/utils/: 包含工具函数、辅助模块及其他可在应用中共享的非 UI 逻辑。
.env.local: 存放本地开发环境的环境变量。这些变量不会提交到版本控制。
next.config.js: 用于自定义 Next.js 行为，包括 webpack 配置、环境变量和安全设置。
tsconfig.json: 配置项目的 TypeScript 设置，启用类型检查及其它 TypeScript 功能。
package.json: 管理项目依赖、脚本和元数据。
README.md: 提供项目文档与说明，包括安装步骤、使用指南及其他相关信息。
yarn.lock / package-lock.json: 将项目依赖锁定到特定版本，确保在不同环境中安装一致。

Next.js 的客户端

`app` 目录中的基于文件的路由

app 目录是最新 Next.js 版本中路由的基石。它利用文件系统来定义路由，使路由管理直观且易于扩展。

处理根路径 /

File Structure:

my-nextjs-app/
├── app/
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

关键文件：

app/page.tsx: 处理对根路径 / 的请求。
app/layout.tsx: 定义应用的布局，包裹所有页面。

实现：

tsxCopy code// app/page.tsx

export default function HomePage() {
return (
<div>
<h1>Welcome to the Home Page!</h1>
<p>This is the root route.</p>
</div>
);
}

解释：

路由定义： 位于 app 目录下的 page.tsx 文件对应于 / 路由。
渲染： 该组件渲染主页的内容。
布局集成： HomePage 组件被 layout.tsx 包裹，layout.tsx 可以包含页眉、页脚和其他公共元素。

处理其他静态路径

示例：/about 路由

文件结构：

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── about/
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

实现：

// app/about/page.tsx

export default function AboutPage() {
return (
<div>
<h1>About Us</h1>
<p>Learn more about our mission and values.</p>
</div>
)
}

解释:

路由定义: 位于 about 文件夹内的 page.tsx 文件对应 /about 路由。
渲染: 该组件渲染 about 页面的内容。

动态路由

动态路由允许处理具有可变段的路径，使应用能够基于诸如 ID、slug 等参数显示内容。

示例: /posts/[id] 路由

文件结构:

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── posts/
│   │   └── [id]/
│   │       └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

实现：

tsxCopy code// app/posts/[id]/page.tsx

import { useRouter } from 'next/navigation';

interface PostProps {
params: { id: string };
}

export default function PostPage({ params }: PostProps) {
const { id } = params;
// Fetch post data based on 'id'

return (
<div>
<h1>Post #{id}</h1>
<p>This is the content of post {id}.</p>
</div>
);
}

说明：

动态段： [id] 表示路由中的动态段，捕获 URL 中的 id 参数。
访问参数： params 对象包含动态参数，可在组件内访问。
路由匹配： 任何匹配 /posts/* 的路径，例如 /posts/1、/posts/abc 等，都会由该组件处理。

嵌套路由

Next.js 支持嵌套路由，允许使用与目录结构相对应的分层路由结构。

示例： /dashboard/settings/profile 路由

文件结构：

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── dashboard/
│   │   ├── settings/
│   │   │   └── profile/
│   │   │       └── page.tsx
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

实现：

tsxCopy code// app/dashboard/settings/profile/page.tsx

export default function ProfileSettingsPage() {
return (
<div>
<h1>Profile Settings</h1>
<p>Manage your profile information here.</p>
</div>
);
}

解释：

深度嵌套： page.tsx 文件位于 dashboard/settings/profile/ 内，对应 /dashboard/settings/profile 路由。
层级映射： 目录结构反映 URL 路径，提升可维护性和清晰度。

通配路由

通配路由用于处理多个嵌套段或未知路径，在路由处理上提供了灵活性。

示例： /* 路由

文件结构：

my-nextjs-app/
├── app/
│   ├── [...slug]/
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

实现:

// app/[...slug]/page.tsx

interface CatchAllProps {
params: { slug: string[] }
}

export default function CatchAllPage({ params }: CatchAllProps) {
const { slug } = params
const fullPath = `/${slug.join("/")}`

return (
<div>
<h1>Catch-All Route</h1>
<p>You have navigated to: {fullPath}</p>
</div>
)
}

说明：

Catch-All 段： [...slug] 将所有剩余的路径段作为数组捕获。
用法： 在处理动态路由场景（例如用户生成的路径、嵌套分类等）时非常有用。
路由匹配： 像 /anything/here、/foo/bar/baz 这样的路径会由该组件处理。

潜在的客户端漏洞

虽然 Next.js 提供了安全的基础，但不当的编码实践可能会引入漏洞。主要的客户端漏洞包括：

Cross-Site Scripting (XSS)

XSS 攻击发生在恶意脚本被注入到受信任的网站时。攻击者可以在用户的浏览器中执行这些脚本，窃取数据或代表用户执行操作。

易受攻击的代码示例：

// Dangerous: Injecting user input directly into HTML
function Comment({ userInput }) {
return <div dangerouslySetInnerHTML={{ __html: userInput }} />
}

为什么会有漏洞： 使用 dangerouslySetInnerHTML 处理不受信任的输入会允许攻击者注入恶意脚本。

Client-Side Template Injection

当模板对用户输入处理不当时会发生，允许攻击者注入并执行模板或表达式。

易受攻击的代码示例：

import React from "react"
import ejs from "ejs"

function RenderTemplate({ template, data }) {
const html = ejs.render(template, data)
return <div dangerouslySetInnerHTML={{ __html: html }} />
}

为何易受攻击： 如果 template 或 data 包含恶意内容，可能导致执行非预期的代码。

Client Path Traversal

这是一个漏洞，允许攻击者操纵客户端路径以执行非预期的操作，例如 Cross-Site Request Forgery (CSRF)。与 server-side path traversal（针对服务器文件系统）不同，CSPT 侧重于利用客户端机制将合法的 API 请求重路由到恶意端点。

Example of Vulnerable Code:

一个 Next.js 应用允许用户上传和下载文件。下载功能在客户端实现，用户可以指定要下载的文件路径。

// pages/download.js
import { useState } from "react"

export default function DownloadPage() {
const [filePath, setFilePath] = useState("")

const handleDownload = () => {
fetch(`/api/files/${filePath}`)
.then((response) => response.blob())
.then((blob) => {
const url = window.URL.createObjectURL(blob)
const a = document.createElement("a")
a.href = url
a.download = filePath
a.click()
})
}

return (
<div>
<h1>Download File</h1>
<input
type="text"
value={filePath}
onChange={(e) => setFilePath(e.target.value)}
placeholder="Enter file path"
/>
<button onClick={handleDownload}>Download</button>
</div>
)
}

攻击场景

攻击者目标: 通过操纵 filePath 执行 CSRF 攻击以删除关键文件（例如 admin/config.json）。
利用 CSPT:

恶意输入: 攻击者构造带有被操纵的 filePath 的 URL，例如 ../deleteFile/config.json。
结果的 API 调用: 客户端代码会向 /api/files/../deleteFile/config.json 发起请求。
服务器的处理: 如果服务器不验证 filePath，它会处理该请求，可能导致敏感文件被删除或泄露。

执行 CSRF:

精心构造的链接: 攻击者向受害者发送链接或嵌入恶意脚本，触发带有被操纵 filePath 的下载请求。
结果: 受害者在不知情的情况下执行该操作，导致未授权的文件访问或删除。

为什么会有漏洞

缺乏输入验证: 客户端允许任意 filePath 输入，从而启用 path traversal。
信任客户端输入: 服务器端 API 信任并处理未经过过滤的 filePath。
潜在的 API 操作: 如果 API 端点执行会改变状态的操作（例如删除、修改文件），则可能被 CSPT 利用。

Next.js 中的服务器端

服务器端渲染 (SSR)

页面在每次请求时由服务器渲染，确保用户收到完整渲染的 HTML。在这种情况下，你应该创建自定义服务器来处理请求。

使用场景：

频繁变化的动态内容。
SEO 优化，因为搜索引擎可以抓取完整渲染的页面。

实现：

// pages/index.js
export async function getServerSideProps(context) {
const res = await fetch("https://api.example.com/data")
const data = await res.json()
return { props: { data } }
}

function HomePage({ data }) {
return <div>{data.title}</div>
}

export default HomePage

静态站点生成 (SSG)

页面在构建时预渲染，从而实现更快的加载时间并减少服务器负载。

使用场景：

不经常变更的内容。
博客、文档、营销页面。

实现：

// pages/index.js
export async function getStaticProps() {
const res = await fetch("https://api.example.com/data")
const data = await res.json()
return { props: { data }, revalidate: 60 } // Revalidate every 60 seconds
}

function HomePage({ data }) {
return <div>{data.title}</div>
}

export default HomePage

Serverless 函数（API 路由）

Next.js 允许将 API 端点创建为 serverless 函数。这些函数按需运行，无需专用服务器。

Use Cases:

处理表单提交。
与数据库交互。
处理数据或与第三方 APIs 集成。

Implementation:

随着 Next.js 13 中引入 app 目录，路由和 API 处理变得更加灵活和强大。这种现代方法与基于文件的路由系统紧密对齐，但引入了增强功能，包括对服务器端与客户端组件的支持。

Basic Route Handler

File Structure:

my-nextjs-app/
├── app/
│   └── api/
│       └── hello/
│           └── route.js
├── package.json
└── ...

实现:

// app/api/hello/route.js

export async function POST(request) {
return new Response(JSON.stringify({ message: "Hello from App Router!" }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

// Client-side fetch to access the API endpoint
fetch("/api/submit", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ name: "John Doe" }),
})
.then((res) => res.json())
.then((data) => console.log(data))

解释：

Location： API routes are placed under the app/api/ directory.
File Naming： Each API endpoint resides in its own folder containing a route.js or route.ts file.
Exported Functions： Instead of a single default export, specific HTTP method functions (e.g., GET, POST) are exported.
Response Handling： Use the Response constructor to return responses, allowing more control over headers and status codes.

如何处理其他路径和方法：

处理特定的 HTTP 方法

Next.js 13+ allows you to define handlers for specific HTTP methods within the same route.js or route.ts file, promoting clearer and more organized code.

示例：

// app/api/users/[id]/route.js

export async function GET(request, { params }) {
const { id } = params
// Fetch user data based on 'id'
return new Response(JSON.stringify({ userId: id, name: "Jane Doe" }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

export async function PUT(request, { params }) {
const { id } = params
// Update user data based on 'id'
return new Response(JSON.stringify({ message: `User ${id} updated.` }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

export async function DELETE(request, { params }) {
const { id } = params
// Delete user based on 'id'
return new Response(JSON.stringify({ message: `User ${id} deleted.` }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

解释：

多个导出： 每个 HTTP 方法 (GET, PUT, DELETE) 都有自己的导出函数。
参数： 第二个参数通过 params 提供对路由参数的访问。
增强的响应： 更大程度地控制响应对象，能够精确管理响应头和状态码。

Catch-All 与嵌套路由

Next.js 13+ 支持高级路由特性，例如 catch-all 路由和嵌套 API 路由，允许构建更动态且可扩展的 API 结构。

Catch-All 路由示例：

// app/api/[...slug]/route.js

export async function GET(request, { params }) {
const { slug } = params
// Handle dynamic nested routes
return new Response(JSON.stringify({ slug }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

说明：

语法： [...] 表示一个 catch-all 段，捕获所有嵌套路径。
用法： 适用于需要处理不同路由深度或动态段的 APIs。

嵌套路由示例：

// app/api/posts/[postId]/comments/[commentId]/route.js

export async function GET(request, { params }) {
const { postId, commentId } = params
// Fetch specific comment for a post
return new Response(
JSON.stringify({ postId, commentId, comment: "Great post!" }),
{
status: 200,
headers: { "Content-Type": "application/json" },
}
)
}

Explanation:

Deep Nesting: 允许分层的 API 结构，反映资源间的关系。
Parameter Access: 通过 params 对象轻松访问多个路由参数。

在 Next.js 12 及更早版本中处理 API 路由

API Routes in the `pages` Directory (Next.js 12 and Earlier)

在 Next.js 13 引入 app 目录并增强路由功能之前，API 路由主要在 pages 目录中定义。这种方法在 Next.js 12 及更早版本中仍被广泛使用和支持。

基本 API 路由

文件结构：

goCopy codemy-nextjs-app/
├── pages/
│   └── api/
│       └── hello.js
├── package.json
└── ...

实现：

javascriptCopy code// pages/api/hello.js

export default function handler(req, res) {
res.status(200).json({ message: 'Hello, World!' });
}

解释：

Location: API 路由位于 pages/api/ 目录下。
Export: 使用 export default 定义处理函数。
Function Signature: 处理函数接收 req（HTTP 请求）和 res（HTTP 响应）对象。
Routing: 文件名（hello.js）映射到端点 /api/hello。

动态 API 路由

文件结构：

bashCopy codemy-nextjs-app/
├── pages/
│   └── api/
│       └── users/
│           └── [id].js
├── package.json
└── ...

实现:

javascriptCopy code// pages/api/users/[id].js

export default function handler(req, res) {
const {
query: { id },
method,
} = req;

switch (method) {
case 'GET':
// Fetch user data based on 'id'
res.status(200).json({ userId: id, name: 'John Doe' });
break;
case 'PUT':
// Update user data based on 'id'
res.status(200).json({ message: `User ${id} updated.` });
break;
case 'DELETE':
// Delete user based on 'id'
res.status(200).json({ message: `User ${id} deleted.` });
break;
default:
res.setHeader('Allow', ['GET', 'PUT', 'DELETE']);
res.status(405).end(`Method ${method} Not Allowed`);
}
}

解释：

动态段（Dynamic Segments）： 方括号 ([id].js) 表示动态路由段。
访问参数（Accessing Parameters）： 使用 req.query.id 来访问动态参数。
处理方法（Handling Methods）： 使用条件逻辑来处理不同的 HTTP 方法（GET, PUT, DELETE 等）。

处理不同的 HTTP 方法

虽然基本的 API 路由示例在单个函数内处理所有 HTTP 方法，但你可以将代码结构化为显式处理每个方法，以提高清晰度和可维护性。

示例：

javascriptCopy code// pages/api/posts.js

export default async function handler(req, res) {
const { method } = req;

switch (method) {
case 'GET':
// Handle GET request
res.status(200).json({ message: 'Fetching posts.' });
break;
case 'POST':
// Handle POST request
res.status(201).json({ message: 'Post created.' });
break;
default:
res.setHeader('Allow', ['GET', 'POST']);
res.status(405).end(`Method ${method} Not Allowed`);
}
}

最佳实践：

关注点分离： 明确分离不同 HTTP 方法的逻辑。
响应一致性： 确保响应结构一致，以便于客户端处理。
错误处理： 以优雅方式处理不支持的方法和意外错误。

CORS 配置

控制哪些来源可以访问你的 API 路由，从而缓解 Cross-Origin Resource Sharing (CORS) 漏洞。

错误配置示例：

// app/api/data/route.js

export async function GET(request) {
return new Response(JSON.stringify({ data: "Public Data" }), {
status: 200,
headers: {
"Access-Control-Allow-Origin": "*", // Allows any origin
"Access-Control-Allow-Methods": "GET, POST, PUT, DELETE",
},
})
}

注意，CORS 也可以在所有 API routes 中进行配置，在 middleware.ts 文件中：

// app/middleware.ts

import { NextResponse } from "next/server"
import type { NextRequest } from "next/server"

export function middleware(request: NextRequest) {
const allowedOrigins = [
"https://yourdomain.com",
"https://sub.yourdomain.com",
]
const origin = request.headers.get("Origin")

const response = NextResponse.next()

if (allowedOrigins.includes(origin || "")) {
response.headers.set("Access-Control-Allow-Origin", origin || "")
response.headers.set(
"Access-Control-Allow-Methods",
"GET, POST, PUT, DELETE, OPTIONS"
)
response.headers.set(
"Access-Control-Allow-Headers",
"Content-Type, Authorization"
)
// If credentials are needed:
// response.headers.set('Access-Control-Allow-Credentials', 'true');
}

// Handle preflight requests
if (request.method === "OPTIONS") {
return new Response(null, {
status: 204,
headers: response.headers,
})
}

return response
}

export const config = {
matcher: "/api/:path*", // Apply to all API routes
}

问题：

Access-Control-Allow-Origin: '*': 允许任何网站访问该 API，可能使恶意网站在没有限制的情况下与您的 API 交互。
允许过多的 HTTP 方法： 允许所有方法可能使攻击者执行不想要的操作。

攻击者如何利用：

攻击者可以构造恶意网站向您的 API 发起请求，可能滥用诸如数据检索、数据修改或代表已认证用户触发不期望操作等功能。

CORS - Misconfigurations & Bypass

服务器端代码在客户端暴露

很容易在客户端暴露并使用服务器端的代码；确保某个代码文件永远不会在客户端暴露的最佳方法，是在文件开头使用这个 import：

import "server-only"

关键文件及其角色

`middleware.ts` / `middleware.js`

Location: 项目根目录或位于 src/ 内。

Purpose: 在请求被处理之前在 server-side serverless function 中执行代码，允许进行诸如身份验证、重定向或修改响应等任务。

Execution Flow:

传入请求： 中间件拦截请求。
处理： 根据请求执行操作（例如，检查身份验证）。
响应修改： 可以更改响应或将控制权传递给下一个处理程序。

Example Use Cases:

重定向未认证的用户。
添加自定义头部。
记录请求。

Sample Configuration:

// middleware.ts
import { NextResponse } from "next/server"
import type { NextRequest } from "next/server"

export function middleware(req: NextRequest) {
const url = req.nextUrl.clone()
if (!req.cookies.has("token")) {
url.pathname = "/login"
return NextResponse.redirect(url)
}
return NextResponse.next()
}

export const config = {
matcher: ["/protected/:path*"],
}

`next.config.js`

位置: 项目根目录。

用途: 配置 Next.js 的行为，启用或禁用功能，定制 webpack 配置，设置环境变量，并配置若干安全功能。

关键安全配置：

安全头 (Security Headers)

安全头通过指示浏览器如何处理内容来增强应用的安全性。它们有助于缓解诸如 Cross-Site Scripting (XSS)、Clickjacking 和 MIME 类型嗅探等多种攻击：

Content Security Policy (CSP)
X-Frame-Options
X-Content-Type-Options
Strict-Transport-Security (HSTS)
Referrer Policy

示例：

// next.config.js

module.exports = {
async headers() {
return [
{
source: "/(.*)", // Apply to all routes
headers: [
{
key: "X-Frame-Options",
value: "DENY",
},
{
key: "Content-Security-Policy",
value:
"default-src *; script-src 'self' 'unsafe-inline' 'unsafe-eval';",
},
{
key: "X-Content-Type-Options",
value: "nosniff",
},
{
key: "Strict-Transport-Security",
value: "max-age=63072000; includeSubDomains; preload", // Enforces HTTPS
},
{
key: "Referrer-Policy",
value: "no-referrer", // Completely hides referrer
},
// Additional headers...
],
},
]
},
}

图像优化设置

Next.js 优化图像以提高性能，但配置错误可能导致安全漏洞，例如允许不受信任的来源注入恶意内容。

错误配置示例：

// next.config.js

module.exports = {
images: {
domains: ["*"], // Allows images from any domain
},
}

问题：

'*': 允许从任何外部来源加载图像，包括不受信任或恶意的域名。攻击者可以托管包含恶意载荷或误导用户内容的图像。
另一个问题是允许一个域名，任何人都可以上传图像（例如 raw.githubusercontent.com）

攻击者如何滥用：

通过注入来自恶意来源的图像，攻击者可以实施 phishing 攻击、显示误导性信息，或利用图像渲染库中的漏洞。

环境变量暴露

安全地管理敏感信息，如 API keys 和数据库凭证，避免将它们暴露给客户端。

a. 暴露敏感变量

不良配置示例：

// next.config.js

module.exports = {
env: {
SECRET_API_KEY: process.env.SECRET_API_KEY, // Exposed to the client
NEXT_PUBLIC_API_URL: process.env.NEXT_PUBLIC_API_URL, // Correctly prefixed for client
},
}

问题：

SECRET_API_KEY: 在没有 NEXT_PUBLIC_ 前缀的情况下，Next.js 不会将变量暴露给客户端。然而，如果错误地添加该前缀（例如，NEXT_PUBLIC_SECRET_API_KEY），它就会在客户端可访问。

攻击者如何滥用它：

如果敏感变量暴露在客户端，攻击者可以通过检查客户端代码或网络请求来获取它们，从而未经授权访问 APIs、数据库或其他服务。

重定向

在应用内管理 URL 重定向和重写，确保用户被适当引导，同时不引入 open redirect vulnerabilities。

a. Open Redirect Vulnerability

错误配置示例：

// next.config.js

module.exports = {
async redirects() {
return [
{
source: "/redirect",
destination: (req) => req.query.url, // Dynamically redirects based on query parameter
permanent: false,
},
]
},
}

问题:

动态目的地: 允许用户指定任意 URL，从而启用 open redirect 攻击。
信任用户输入: 将用户提供的 URL 在未验证的情况下重定向，可能导致 phishing、malware distribution 或 credential theft。

攻击者如何滥用它:

攻击者可以构造看似来自你域名的 URL，但会将用户重定向到恶意站点。例如：

https://yourdomain.com/redirect?url=https://malicious-site.com

信任原始域名的用户可能在不知情的情况下被引导到有害网站。

Webpack 配置

为你的 Next.js 应用自定义 Webpack 配置，但如果处理不慎，可能无意间引入安全漏洞。

a. 公开敏感模块

错误的配置示例：

// next.config.js

module.exports = {
webpack: (config, { isServer }) => {
if (!isServer) {
config.resolve.alias["@sensitive"] = path.join(__dirname, "secret-folder")
}
return config
},
}

问题：

暴露敏感路径： 为敏感目录创建别名并允许客户端访问会 leak 机密信息。
将敏感信息打包： 如果将敏感文件打包到客户端，它们的内容可以通过 source maps 或检查客户端代码来访问。

攻击者如何利用：

攻击者可以访问或重建应用的目录结构，可能发现并利用敏感文件或数据。

`pages/_app.js` 和 `pages/_document.js`

`pages/_app.js`

目的： 覆盖默认的 App 组件，允许使用全局状态、样式和布局组件。

用例：

注入全局 CSS。
添加布局包装器。
集成状态管理库。

示例：

// pages/_app.js
import "../styles/globals.css"

function MyApp({ Component, pageProps }) {
return <Component {...pageProps} />
}

export default MyApp

`pages/_document.js`

目的： 覆盖默认的 Document，允许自定义 <html> 和 <body> 标签。

使用场景：

修改 <html> 或 <body> 标签。
添加 meta 标签或自定义脚本。
集成第三方字体。

示例：

// pages/_document.js
import Document, { Html, Head, Main, NextScript } from "next/document"

class MyDocument extends Document {
render() {
return (
<Html lang="en">
<Head>{/* Custom fonts or meta tags */}</Head>
<body>
<Main />
<NextScript />
</body>
</Html>
)
}
}

export default MyDocument

自定义服务器（可选）

Purpose: 虽然 Next.js 附带内置服务器，但您可以创建自定义服务器以满足高级用例，例如自定义路由或与现有后端服务集成。

Note: 使用自定义服务器可能会限制部署选项，尤其是在像 Vercel 这样针对 Next.js 内置服务器进行优化的平台上。

Example:

// server.js
const express = require("express")
const next = require("next")

const dev = process.env.NODE_ENV !== "production"
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare().then(() => {
const server = express()

// Custom route
server.get("/a", (req, res) => {
return app.render(req, res, "/a")
})

// Default handler
server.all("*", (req, res) => {
return handle(req, res)
})

server.listen(3000, (err) => {
if (err) throw err
console.log("> Ready on http://localhost:3000")
})
})

额外的架构与安全注意事项

环境变量与配置

目的： 在代码库之外管理敏感信息和配置设置。

最佳实践：

使用 .env 文件： 将像 API 密钥这样的变量存储在 .env.local（被版本控制排除）。
安全访问变量： 使用 process.env.VARIABLE_NAME 来访问环境变量。
永远不要在客户端暴露机密： 确保敏感变量仅在服务端使用。

示例：

// next.config.js
module.exports = {
env: {
API_KEY: process.env.API_KEY, // Accessible on both client and server
SECRET_KEY: process.env.SECRET_KEY, // Be cautious if accessible on the client
},
}

注意： 若要将变量限制为仅在服务器端，可从 env 对象中省略它们，或在需要客户端暴露时在前缀加上 NEXT_PUBLIC_。

身份验证与授权

方法：

基于会话的认证： 使用 cookies 管理用户会话。
基于令牌的认证： 使用 JWTs 实现无状态认证。
第三方提供商： 使用像 next-auth 这样的库与 OAuth 提供者（例如 Google、GitHub）集成。

安全实践：

安全 Cookies： 设置 HttpOnly、Secure 和 SameSite 属性。
密码哈希： 在存储之前始终对密码进行哈希。
输入验证： 通过验证和清理输入来防止注入攻击。

示例：

// pages/api/login.js
import { sign } from "jsonwebtoken"
import { serialize } from "cookie"

export default async function handler(req, res) {
const { username, password } = req.body

// Validate user credentials
if (username === "admin" && password === "password") {
const token = sign({ username }, process.env.JWT_SECRET, {
expiresIn: "1h",
})
res.setHeader(
"Set-Cookie",
serialize("auth", token, {
path: "/",
httpOnly: true,
secure: true,
sameSite: "strict",
})
)
res.status(200).json({ message: "Logged in" })
} else {
res.status(401).json({ error: "Invalid credentials" })
}
}

性能优化

策略：

图像优化： 使用 Next.js 的 next/image 组件进行自动图像优化。
代码分割： 利用动态导入进行代码分割，减少初始加载时间。
缓存： 为 API 响应和静态资源实施缓存策略。
懒加载： 仅在需要时加载组件或资源。

示例：

// Dynamic Import with Code Splitting
import dynamic from "next/dynamic"

const HeavyComponent = dynamic(() => import("../components/HeavyComponent"), {
loading: () => <p>Loading...</p>,
})

Next.js Server Actions 枚举（hash to function name via source maps）

现代的 Next.js 使用 “Server Actions”，这些在服务器端执行但由客户端调用。在生产环境中这些调用是不可见的：所有 POST 请求都会到达一个通用端点，并通过在 Next-Action 头中发送的构建特定 hash 来区分。示例：

POST /
Next-Action: a9f8e2b4c7d1...

当 productionBrowserSourceMaps 启用时，minified JS chunks 包含对 createServerReference(...) 的调用，会 leak 足够的结构（以及相关的 source maps），从而恢复 action hash 与原始函数名之间的映射。这让你可以将 Next-Action 中观察到的哈希转换为具体目标，例如 deleteUserAccount() 或 exportFinancialData()。

提取方法 (regex on minified JS + optional source maps)

在下载的 JS chunks 中搜索 createServerReference，并提取 hash 以及函数/源符号。两个有用的模式：

# Strict pattern for standard minification
createServerReference\)"([a-f0-9]{40,})",\w+\.callServer,void 0,\w+\.findSourceMapURL,"([^"]+)"\)

# Flexible pattern handling various minification styles
createServerReference[^\"]*"([a-f0-9]{40,})"[^\"]*"([^"]+)"\s*\)

组 1：server action hash（40+ 十六进制字符）
组 2：符号或路径（在存在 source map 时可解析回原始函数名）

如果脚本声明了 source map（尾部注释 //# sourceMappingURL=<...>.map），获取它并将 symbol/path 解析为原始函数名。

实用工作流程

被动发现（浏览时）：捕获带有 Next-Action headers 的请求和 JS chunk URLs。
获取引用的 JS bundle 和随附的 *.map 文件（如果存在）。
运行上面的 regex 来构建 hash↔name 字典。
使用该字典进行针对性测试：
- 基于名称的筛选（例如：transferFunds、exportFinancialData）。
- 按函数名跟踪不同构建的覆盖情况（hash 会在构建间旋转）。

触发隐藏 actions（基于模板的请求）

以在代理中观察到的有效 POST 作为模板，替换 Next-Action 值以针对其他已发现的 action：

# Before
Next-Action: a9f8e2b4c7d1

# After
Next-Action: b7e3f9a2d8c5

在 Repeater 中重放并测试否则无法访问的操作的授权、输入验证和业务逻辑。

Burp automation

NextjsServerActionAnalyzer (Burp extension) 在 Burp 中自动化上述流程：
从 proxy 历史中挖掘 JS chunk，提取 createServerReference(...) 条目，并在可用时解析 source maps。
维护可搜索的 hash↔函数名字典，并按函数名跨构建去重。
可以定位有效的模板 POST 并打开一个准备发送的 Repeater 选项卡，将目标 action 的 hash 替换进去。
Repo: https://github.com/Adversis/NextjsServerActionAnalyzer

Notes and limitations

需要在 production 中启用 productionBrowserSourceMaps，以从 bundles/source maps 恢复名称。
函数名泄露本身并非漏洞；将其用于指引发现并测试每个 action 的授权。

React Server Components Flight protocol deserialization RCE (CVE-2025-55182)

在 react-server-dom-webpack 19.0.0–19.2.0 (Next.js 15.x/16.x) 上暴露 Server Actions 的 Next.js App Router 部署，在 Flight chunk 反序列化期间包含一个严重的服务端 prototype pollution 漏洞。通过在 Flight payload 中构造 $ 引用，攻击者可以从被污染的原型推进到任意 JavaScript 执行，进而在 Node.js 进程中执行操作系统命令。

NodeJS - proto & prototype Pollution

Flight chunks 中的攻击链

原型污染原语： 设置 "then": "$1:__proto__:then"，使解析器在 Object.prototype 上写入一个 then 函数。之后处理的任何普通对象都会变成一个 thenable，从而允许攻击者影响 RSC 内部的异步控制流。
重新绑定到全局 Function 构造函数： 将 _response._formData.get 指向 "$1:constructor:constructor"。在解析过程中，object.constructor → Object，Object.constructor → Function，因此后续对 _formData.get() 的调用实际上会执行 Function(...)。
通过 _prefix 执行代码： 将 JavaScript 源放入 _response._prefix。当被污染的 _formData.get 被调用时，框架会评估 Function(_prefix)(...)，因此注入的 JS 可以运行 require('child_process').exec() 或任何其他 Node 原语。

Payload skeleton

{
"then": "$1:__proto__:then",
"status": "resolved_model",
"reason": -1,
"value": "{\"then\":\"$B1337\"}",
"_response": {
"_prefix": "require('child_process').exec('id')",
"_chunks": "$Q2",
"_formData": { "get": "$1:constructor:constructor" }
}
}

映射 React Server Function 的暴露情况

React Server Functions (RSF) 是包含 ‘use server’; 指令的任何函数。每个绑定到这些函数之一的 form action、mutation 或 fetch helper 都会变成一个 RSC Flight endpoint，该端点会愉快地反序列化攻击者提供的 payload。基于 React2Shell 评估得出的有用侦查步骤：

Static inventory: 查找该指令以了解框架自动暴露了多少个 RSFs。

rg -n "'use server';" -g"*.{js,ts,jsx,tsx}" app/

App Router defaults: create-next-app 默认启用 App Router + app/ 目录，这会悄无声息地将每个路由变成支持 RSC 的端点。App Router 资产例如 /_next/static/chunks/app/ 或通过 text/x-component 流式传输 Flight chunks 的响应，都是明显的面向互联网的指纹。
Implicitly vulnerable RSC deployments: React 官方通告指出，发布 RSC runtime 的应用即便没有显式 RSFs也可能被利用，因此将任何使用 react-server-dom-* 19.0.0–19.2.0 的构建视为可疑。
Other frameworks bundling RSC: Vite RSC、Parcel RSC、React Router RSC preview、RedwoodSDK、Waku 等复用相同的 serializer，并继承相同的远程攻击面，直到它们嵌入了修补过的 React 构建为止。

版本覆盖 (React2Shell)

react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack: 在 19.0.0、19.1.0–19.1.1 和 19.2.0 中易受攻击；分别在 19.0.1、19.1.2 和 19.2.1 中已修复。
Next.js stable: App Router 发布的 15.0.0–16.0.6 嵌入了易受攻击的 RSC 堆栈。补丁车 15.0.5 / 15.1.9 / 15.2.6 / 15.3.6 / 15.4.8 / 15.5.7 / 16.0.7 包含已修复的依赖，因此任何低于这些版本的构建都是高价值目标。
Next.js canary: 14.3.0-canary.77+ 也携带有问题的 runtime，目前尚无修复的 canary 版本，因此这些指纹是强烈的利用候选。

远程检测 oracle

Assetnote 的 react2shell-scanner 向候选路径发送精心构造的 multipart Flight 请求并观察服务器端行为：

Default mode 执行确定性的 RCE payload（通过 X-Action-Redirect 反射的数学运算）以证明代码执行。
--safe-check mode 故意损坏 Flight 消息，使已修补的服务器返回 200/400，而易受攻击的目标会发出包含 E{"digest" 子串的 HTTP/500 响应体。该 (500 + digest) 配对目前是防御方发布的最可靠远程判定信号。
内置的 --waf-bypass、--vercel-waf-bypass 和 --windows 开关会调整 payload 布局、前置垃圾数据或替换 OS 命令，以便你探测真实的互联网资产。

python3 scanner.py -u https://target.tld --path /app/api/submit --safe-check
python3 scanner.py -l hosts.txt -t 20 --waf-bypass -o vulnerable.json

参考资料

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。