NodeJS Express

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Quick Fingerprinting

Useful Express indicators during recon:

  • X-Powered-By: Express or stack traces mentioning express, body-parser, qs, cookie-parser, express-session, or finalhandler
  • Cookies prefixed with s: (signed cookie) or j: (JSON cookie)
  • Session cookies such as connect.sid
  • Hidden form fields or query parameters such as _method=PUT / _method=DELETE
  • Error pages leaking Cannot GET /path, Cannot POST /path, Unexpected token in body-parser, or URIError during query parsing

When you confirm Express, focus on the middleware chain, because most interesting bugs come from parsers, proxy trust, session handling, and method-tunneling rather than from the framework core itself.

The tool https://github.com/DigitalInterruption/cookie-monster è un’utility per automatizzare il testing e il re-signing dei secrets dei cookie di Express.js.

Express commonly exposes two useful cookie formats:

  • s:<value>.<sig> signed cookies handled by cookie-parser or express-session
  • j:<json> JSON cookies that are automatically parsed by cookie-parser

If cookie-parser receives a signed cookie and the signature is invalid, the value becomes false instead of the tampered value. If the application accepts an array of secrets, old secrets may still verify existing cookies after rotation.

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

Wordlist personalizzata

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

Testare più cookies in modalità batch

cookie-monster -b -f cookies.json

Testare più cookies usando batch mode con una custom wordlist

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

Se conosci il segreto, puoi firmare il cookie.

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

Query String e abuso del parser URL-Encoded

Gli obiettivi Express spesso diventano interessanti quando analizzano chiavi controllate dall’attaccante in oggetti nidificati.

  • req.query può essere configurato con diversi parser, incluso qs
  • express.urlencoded({ extended: true }) usa il parsing in stile qs per application/x-www-form-urlencoded
  • Il parsing nidificato abilita object injection, mass assignment, NoSQL injection e prototype pollution chains se l’oggetto parsato viene unito nello stato dell’applicazione

Payloads pratici da provare:

# 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'

Se l’app riflette o persiste l’oggetto risultante, passa alle pagine dedicate per i dettagli sull’exploitation:

Mass Assignment Cwe 915

Express Prototype Pollution Gadgets

Test aggiuntivi da inviare specificamente contro Express:

  • Nesting profondo per cercare limiti del parser, timeout, o differenze 400/413
  • Chiavi duplicate per verificare se l’app mantiene il primo valore, l’ultimo, o un array
  • Sintassi con parentesi come a[b][c]=1, sintassi puntata come a.b=1, e __proto__ / constructor[prototype] payloads

Abuso di trust proxy

Se l’app usa app.set("trust proxy", true) o si fida di troppi hop, Express ricaverà valori rilevanti per la sicurezza dagli header di forwarding. Se il proxy inverso non li sovrascrive, un client può falsificarli direttamente.

Questo influisce su:

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

Questo è utile per:

  • Password reset poisoning and absolute URL poisoning
  • Bypassing IP-based allowlists, rate limits, or audit trails
  • Influencing secure cookie handling and HTTPS-only logic in apps that key off req.protocol
  • Poisoning redirects or cacheable responses when the app templates absolute links with forwarded host/proto headers
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"}

Verifica se i link generati, le destinazioni di redirect, i log o le decisioni di controllo degli accessi utilizzano ora valori forniti dall’attaccante.

Pagine correlate:

Reset/Forgotten Password Bypass

Cache Poisoning and Cache Deception

express-session Note di test

Le implementazioni comuni di Express usano express-session, che firma il cookie identificatore della sessione ma memorizza lo stato reale sul server.

Verifiche utili:

  • Session fixation: autenticarsi con un cookie pre-login e verificare se il SID rimane lo stesso dopo il login
  • Weak secret rotation: alcune implementazioni verificano i cookie con un array di secret vecchi, quindi firme precedentemente valide potrebbero continuare a funzionare
  • saveUninitialized: true: l’applicazione emette sessioni pre-auth per utenti anonimi, il che rende la fixation più facile e aumenta la superficie di sessione per brute-force o analisi della cache
  • MemoryStore in produzione solitamente indica scarsa maturità operativa e comportamento instabile delle sessioni durante i riavvii

Un flusso di lavoro pratico per la fixation:

  1. Ottieni un cookie di sessione anonimo dal target.
  2. Invia quel cookie a una vittima o usalo per autenticarti tu stesso.
  3. Verifica se il login associa lo stato autenticato all’SID esistente.
  4. Se sì, riproduci lo stesso cookie in una sessione del browser separata.

Se l’app non chiama req.session.regenerate() dopo l’autenticazione, la fixation è spesso ancora possibile.

Method Override Tunneling

Alcune app Express usano method-override per tunnelizzare verbi che i form HTML non possono inviare nativamente. Quando è abilitato, testa sempre se puoi contrabbandare metodi pericolosi attraverso una route che il front-end, il WAF o la logica CSRF presumeva fosse solo POST.

Probe tipiche:

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

Implicazioni interessanti:

  • Raggiungere rotte nascoste PUT / PATCH / DELETE attraverso un controllo edge che accetta solo POST
  • Bypassare middleware specifici per route che controllano solo req.method
  • Attivare handler che modificano lo stato via CSRF quando l’applicazione valida solo il metodo esterno della richiesta

Per default il middleware di solito sovrascrive solo POST, quindi dare priorità alle richieste POST con valori di override negli header, nel body e nella query-string.

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks