Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#934 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@tnaum-ms đang làm issue này rồi.

Từ ngày 23/10/2026.

  • #1050 của @tnaum-ms — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
82/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
azure, mongodb, typescript
Lĩnh vực
authentication, security

Hướng nghiên cứu

Bắt đầu trong src/documentdb/auth/oidcAllowedHosts.ts và đọc getAzureHostSuffix cùng với getOidcAllowedHosts. So sánh các hậu tố được nhận diện với các miền đám mây Azure được ghi trong tài liệu và xác minh rằng các host được ghi trong tài liệu vẫn được cho phép, trong khi các miền con azure dưới các TLD tùy ý bị từ chối.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
33
Fork
22
Merge trung bình
16 giờ 13 phút
Pull request đã merge (30 ngày)
36

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/vscode-documentdb

Tất cả issue của microsoft/vscode-documentdb

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.