Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

SSRF guard re-resolves DNS at connect time, so rebinding is still possible

Aperta
  • Qualcosa non va?
#515 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
node.js, typescript
Ambito
backend, networking, security

Direzione di ricerca

Start with src/net/ssrf.ts and trace how its lookup, fetchImpl, and redirect handling work; then read the existing tests that exercise those injectable dependencies. Run those tests before making changes. Done means the connected address is one that was validated, TLS verification and redirect checks remain intact, the injections still work, a rebinding test passes, and the module comment accurately states the guarantee.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area:security help wanted

Follow-up to #407, which was closed by #488. That PR is a thorough guard and removed the whole easy attack surface — this is the residue it deliberately left.

Not a Wave issue right now. The repo's Wave budget for this round is exhausted, so this is filed for tracking rather than for points. It will be labelled for the Wave when the next round opens.

The gap

src/net/ssrf.ts validates and then fetches:

let url = await assertUrlSafe(target, opts)
const response = await fetchImpl(url.toString(), { ...init, redirect: 'manual' })

assertUrlSafe resolves the hostname and checks every returned address. fetchImpl is then given the hostname, and Node resolves it again when it opens the connection.

An attacker who controls a DNS zone can serve a short-TTL record that answers the first query with a public address and the second with 169.254.169.254. The check passes, the connection goes somewhere else. This is DNS rebinding, and it is the specific thing a post-resolution check is otherwise meant to defeat.

It matters here because the MCP server takes its target URL from an agent, and agents routinely read attacker-influenced text.

What to build

Pin the connection to an address that was actually validated.

  • An undici dispatcher with a custom connect or lookup is the usual route: resolve once, validate, and hand the chosen address to the connector so no second resolution happens.
  • Or connect by IP with the Host header preserved — be careful, this breaks TLS SNI and certificate verification unless servername is set explicitly, so it is not the simpler option it appears to be.
  • Re-validate on every redirect hop, as the current code already does.
  • The existing injectable lookup and fetchImpl should stay injectable, because that is what makes the current tests possible.
Also

Correct the module comment. It currently reads:

to decide that after resolving the hostname, because a public-looking name can resolve to a private address — the classic way this check is bypassed.

True of a static name, not of an attacker-controlled one. Say plainly that connect-time resolution is not yet pinned, so nobody reads it as a guarantee it does not make.

Acceptance criteria
  • The address connected to is one that was validated
  • A test proves a hostname resolving differently on the second lookup does not reach the second address
  • TLS verification still works against the original hostname
  • Redirect hops remain validated
  • lookup and fetchImpl stay injectable and the existing tests still pass
  • The module comment states what is and is not guaranteed
Lingua principale
TypeScript
Stelle
4
Fork
71
Merge medio
1g 9h
PR unite (30g)
46

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Divinity-Labs/Lens

Tutte le issue di Divinity-Labs/Lens

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.