Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Harden Azure Key Vault trusted endpoint matching

Abierto
  • ¿Algo no está bien?
#4,802 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 2 días

@apoorvdeshmukh ya está trabajando en esto.

Desde el 13/10/2026.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
azure, csharp
Área
backend, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
996
Forks
348
Merge medio
5 d 15 h
PR fusionados (30 d)
54

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/SqlClient

Todos los issues de dotnet/SqlClient

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.