Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Harden Azure Key Vault trusted endpoint matching

オープン
  • 何か問題がありますか？
#4,802 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@apoorvdeshmukh がすでに取り組んでいます。

2026年10月13日 から。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
azure, csharp
領域
backend, security

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
C#
スター
996
フォーク
348
平均マージ
5日 15時間
マージ済み PR（30日）
54

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dotnet/SqlClient のほかの issue

dotnet/SqlClient の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。