NodeJS Express

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Quick Fingerprinting

Indicadores úteis do Express durante recon:

  • X-Powered-By: Express ou stack traces mencionando express, body-parser, qs, cookie-parser, express-session ou finalhandler
  • Cookies prefixados com s: (signed cookie) ou j: (JSON cookie)
  • Cookies de sessão como connect.sid
  • Campos de formulário ocultos ou parâmetros de query como _method=PUT / _method=DELETE
  • Páginas de erro leaking Cannot GET /path, Cannot POST /path, Unexpected token em body-parser, ou URIError durante parsing de query

Quando você confirmar o Express, concentre-se na cadeia de middleware, porque a maioria dos bugs interessantes vem de parsers, proxy trust, session handling e method-tunneling em vez do core do framework.

A ferramenta https://github.com/DigitalInterruption/cookie-monster é uma utilidade para automatizar o teste e o re-signing dos secrets de cookie do Express.js.

O Express normalmente expõe dois formatos úteis de cookie:

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

Se o cookie-parser receber um cookie assinado e a assinatura for inválida, o valor se torna false em vez do valor adulterado. Se a aplicação aceitar um array de secrets, secrets antigos ainda podem verificar cookies existentes após a rotação.

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

Wordlist personalizada

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

Testar múltiplos cookies usando batch mode

cookie-monster -b -f cookies.json

Testar múltiplos cookies usando batch mode com uma wordlist customizada

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

Se você souber o segredo, pode assinar o cookie.

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

Query String and URL-Encoded Parser Abuse

Alvos Express frequentemente se tornam interessantes quando analisam chaves controladas pelo atacante em objetos aninhados.

  • req.query pode ser configurado com diferentes parsers, incluindo qs
  • express.urlencoded({ extended: true }) usa parsing no estilo qs para application/x-www-form-urlencoded
  • O parsing aninhado desbloqueia object injection, mass assignment, NoSQL injection e prototype pollution chains se o objeto parseado for mesclado no estado da aplicação

Payloads práticos para testar:

# 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 a app reflete ou persiste o objeto resultante, vá para as páginas dedicadas para detalhes de exploração:

Mass Assignment Cwe 915

Express Prototype Pollution Gadgets

Testes extras que valem a pena enviar especificamente contra Express:

  • Aninhamento profundo para procurar limites do parser, timeouts, ou diferenças 400/413
  • Chaves duplicadas para ver se a app mantém o primeiro valor, o último, ou um array
  • Sintaxe com colchetes como a[b][c]=1, sintaxe pontuada como a.b=1, e payloads __proto__ / constructor[prototype]

trust proxy Abuse

Se a app usa app.set("trust proxy", true) ou confia em hops demais, Express derivará valores relevantes para segurança a partir dos headers de forwarding. Se o reverse proxy não os sobrescrever, um cliente pode forjá-los diretamente.

Isso afeta:

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

Isso é útil para:

  • Envenenamento da redefinição de senha e envenenamento de URLs absolutas
  • Contornar allowlists baseadas em IP, rate limits, ou trilhas de auditoria
  • Influenciar o tratamento de cookies secure e a lógica HTTPS-only em apps que dependem de req.protocol
  • Envenenar redirects ou respostas cacheáveis quando a app renderiza links absolutos com 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"}

Verifique se links gerados, locais de redirecionamento, logs ou decisões de controle de acesso agora usam valores fornecidos pelo atacante.

Páginas relacionadas:

Reset/Forgotten Password Bypass

Cache Poisoning and Cache Deception

Notas de teste para express-session

Implantações Express comuns usam express-session, que assina o cookie identificador de sessão mas armazena o estado real no servidor.

Verificações úteis:

  • Session fixation: autentique-se com um cookie pré-login e verifique se o SID permanece o mesmo após o login
  • Weak secret rotation: algumas implantações verificam cookies com um array de segredos antigos, portanto assinaturas anteriormente válidas podem continuar funcionando
  • saveUninitialized: true: a aplicação emite sessões pré-autenticadas para usuários anônimos, o que facilita fixation e aumenta a superfície de sessão para brute-force ou análise de cache
  • MemoryStore em produção geralmente indica maturidade operacional fraca e comportamento instável de sessão durante reinícios

Um fluxo de trabalho prático para fixation:

  1. Obtenha um cookie de sessão anônima do alvo.
  2. Envie esse cookie para uma vítima ou autentique-se com ele você mesmo.
  3. Verifique se o login vincula o estado autenticado ao SID existente.
  4. Se sim, replay o mesmo cookie em uma sessão de navegador separada.

Se a app não chamar req.session.regenerate() após a autenticação, fixation muitas vezes ainda é possível.

Tunelamento de Method Override

Algumas apps Express usam method-override para tunelar verbos que formulários HTML não conseguem enviar nativamente. Quando ativado, sempre teste se você pode smuggle métodos perigosos através de uma rota que o front-end, WAF, ou a lógica de CSRF presumiu ser apenas POST.

Probes típicas:

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

Impactos interessantes:

  • Atingir rotas ocultas PUT / PATCH / DELETE através de um controle na borda que aceita apenas POST
  • Contornando middleware específico de rota que verifica apenas req.method
  • Acionando handlers que alteram estado via CSRF quando a aplicação valida apenas o método externo da requisição

Por padrão, o middleware normalmente só sobrescreve POST, então priorize requisições POST com valores de substituição no header, body e query-string.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks