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

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

オープン 初心者向け
  • 何か問題がありますか？
#934 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

@tnaum-ms がすでに取り組んでいます。

2026年10月23日 から。

  • #1050 @tnaum-ms による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
82/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
azure, mongodb, typescript
領域
authentication, security

調査の方向性

src/documentdb/auth/oidcAllowedHosts.ts から始め、getAzureHostSuffix と getOidcAllowedHosts を併せて読みます。認識されるサフィックスを文書化されている Azure クラウドドメインと比較し、文書化されているホストが引き続き許可される一方で、任意の TLD 配下にある azure サブドメインが拒否されることを確認します。

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

説明

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.

主要言語
TypeScript
スター
34
フォーク
22
平均マージ
16時間 12分
マージ済み PR（30日）
53

環境構築

Codespaces で開く

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

はじめの一歩

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

microsoft/vscode-documentdb のほかの issue

microsoft/vscode-documentdb の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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