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

OIDC ALLOWED_HOSTS suffix recognition accepts any azure.<tld>, including non-Microsoft TLDs open for public registration

Aperta Adatta ai principianti
  • Qualcosa non va?
#934 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à
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
82/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
azure, mongodb, typescript
Ambito
authentication, security

Direzione di ricerca

Inizia in src/documentdb/auth/oidcAllowedHosts.ts e leggi getAzureHostSuffix insieme a getOidcAllowedHosts. Confronta i suffissi riconosciuti con i domini cloud Azure documentati e verifica che gli host documentati rimangano consentiti, mentre i sottodomini azure sotto TLD arbitrari vengano rifiutati.

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

Descrizione

Summary

#721 replaced the hardcoded *.azure.com OIDC allowlist with suffix recognition: getAzureHostSuffix (src/documentdb/auth/oidcAllowedHosts.ts) accepts a host when its registrable second-level label is azure — and the top-level label is ANY non-empty string:

const topLevel = labels[labels.length - 1];
const secondLevel = labels[labels.length - 2];

if (secondLevel === 'azure' && topLevel.length > 0) {
    return `azure.${topLevel}`;
}

So *.azure.com, *.azure.us, *.azure.cn pass — and so does *.azure.<any open TLD>: azure.xyz, azure.top, azure.live, and so on. Those domains are registrable by anyone. The file's own comment names the intent as "sovereign clouds (azure.us, azure.cn, ...)", but the implementation does not bound the suffix set to Microsoft-operated clouds.

Consequence, by the file's own description of the control ("the driver only sends the OIDC token to a server whose hostname matches one of these patterns"): a connection string whose host sits under a registrable azure.<openTld> is positively classified as Azure-family, and the token-delivery host allowlist widens to match it. On a machine with a managed identity (the new auth surface) or an interactive Entra sign-in, a connection string of the shape

mongodb://x.azure.xyz:10255/?authMechanism=MONGODB-OIDC&...

pasted into the connection wizard classifies x.azure.xyz as an allowed token-delivery host.

Two things bound this in practice and belong in the assessment:

  • The enabling surface predates the managed-identity work: the same azure.<tld> recognition already governed the Entra ID user-token path in 0.10.2 (oidcAllowedHosts.ts unchanged since 2026-06-26), so wizard + allowlist is pre-existing behavior; the new auth methods add token principals, not a new gate, host, or channel.
  • Reaching it needs the conjunction of an attacker-registered lookalike domain AND a user pasting a hostile connection string AND (for the identity-token path) a host with the relevant identity configured.
Repro

Logic-level, against the shipped function:

getAzureHostSuffix('x.azure.xyz')   // => 'azure.xyz'   (recognized as Azure-family)
getOidcAllowedHosts('mongodb://x.azure.xyz:10255/?authMechanism=MONGODB-OIDC')
// => ['*.azure.xyz']               (token-delivery allowlist widened to the lookalike)

Any first-level label under any azure.<tld> behaves the same; only the second-level label is inspected.

Suggested fix

Bound the recognized suffixes to the documented sovereign set instead of any TLD:

const AZURE_HOST_SUFFIXES = new Set(['azure.com', 'azure.us', 'azure.cn']);

// in getAzureHostSuffix:
const candidate = `${secondLevel}.${topLevel}`;
return AZURE_HOST_SUFFIXES.has(candidate) ? candidate : undefined;

Private endpoints keep working (they resolve under *.azure.com — the file comment already notes this). If broader coverage is ever wanted, the #639 option of an explicit user setting for custom domains keeps the default closed while still serving sovereign/custom deployments.

Impact framing

Allowlist-breadth hardening filed as a follow-up to #639/#721, not a vulnerability report: the design goals (don't echo the raw host back into the allowlist; cover sovereign clouds) are right, and the gap is that the suffix predicate is open-ended where the intent was a curated set. With the pre-existing parity noted above, tightening closes a lookalike-domain variant of the paste-a-connection-string flow while leaving every documented deployment shape unchanged.

Lingua principale
TypeScript
Stelle
33
Fork
22
Merge medio
18h 6m
PR unite (30g)
41

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 microsoft/vscode-documentdb

Tutte le issue di microsoft/vscode-documentdb

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.