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

Harden Azure Key Vault trusted endpoint matching

Aperta
  • Qualcosa non va?
#4,802 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@apoorvdeshmukh ci sta già lavorando.

Dal 13/10/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
azure, csharp
Ambito
backend, security

Direzione di ricerca

Start by locating SqlColumnEncryptionAzureKeyVaultProvider and reading its trusted-endpoint validation and constructor behavior, then inspect the related tests. Add coverage for the listed DNS, scheme, port, normalization, and input-mutation cases; done means endpoint validation follows the requested structured rules while preserving the described compatibility path.

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

Descrizione

Area\AKV Provider
Is your feature request related to a problem? Please describe.

SqlColumnEncryptionAzureKeyVaultProvider validates an Azure Key Vault key URI by checking whether Uri.Host ends with one of its trusted endpoint strings. Raw suffix matching does not require a DNS-label boundary, so a hostname can match a trusted suffix without being that domain or one of its subdomains.

The trusted-endpoint representation also does not express whether an entry is an exact host, a DNS suffix, or a complete origin. This makes it difficult to apply clear scheme and port rules to application-supplied endpoints while preserving compatibility with custom Azure environments and development endpoints.

Describe the solution you'd like

Harden and clarify trusted endpoint validation:

  • Match built-in domain suffixes only when the host is exactly the suffix or ends with "." + suffix, using ordinal case-insensitive comparison.
  • Normalize DNS hosts consistently, including IDN and terminal-dot handling.
  • Require HTTPS for built-in Azure Key Vault and Managed HSM endpoints.
  • Validate and normalize application-supplied trusted endpoints when the provider is constructed.
  • Provide structured semantics for custom endpoints, distinguishing exact origins from entries that intentionally include DNS subdomains.
  • Defensively copy trusted endpoint collections so validation policy cannot be changed by mutating the constructor input.
  • Preserve reasonable compatibility for existing custom endpoints, with diagnostics and an explicit migration path for ambiguous legacy entries.

Add tests covering:

  • Valid exact hosts and subdomains.
  • Lookalike suffixes that do not share a DNS-label boundary.
  • Hosts that append another DNS suffix after a trusted name.
  • Mixed-case, IDN, and terminal-dot hostnames.
  • HTTP, HTTPS, default ports, and explicit custom ports.
  • Mutation of the input trusted-endpoint array after construction.
Describe alternatives you've considered
  • Keep raw EndsWith matching. This retains ambiguous behavior and does not accurately model DNS domain membership.
  • Require exact host matching for every entry. This would not work for the built-in Azure Key Vault domains, where each vault has its own subdomain.
  • Immediately reject every legacy custom endpoint format. This would provide simpler rules but could unnecessarily disrupt applications using private clouds, proxies, or development services. A compatibility-conscious migration to structured endpoint rules is preferable.
Additional context

The current built-in list covers Azure Key Vault and Managed HSM domains in public and sovereign clouds. DNS-label-boundary matching should preserve valid hostnames beneath those domains while making the allowlist behavior precise.

Lingua principale
C#
Stelle
996
Fork
348
Merge medio
6g 3h
PR unite (30g)
58

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 dotnet/SqlClient

Tutte le issue di dotnet/SqlClient

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.