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

dns-rebinding-protection: check Host and Origin validation separately

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

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

まだ誰も着手していません。

評価

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

調査の方向性

Start with the commented constants in src/scenarios/server/dns-rebinding.ts and the existing dns-rebinding-protection checks. Read the fixture files dns-rebinding-host-only.ts, dns-rebinding-origin-only.ts, and no-dns-rebinding-protection.ts, then inspect negative.test.ts. Done means Host-only and Origin-only requests are checked separately, the fixture schema issue is corrected, and the listed server results are asserted.

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

説明

enhancement

Gap

localhost-host-rebinding-rejected sends Host: evil.example.com and Origin: http://evil.example.com in the same request and passes on any 4xx. A server that validates only one of the two headers passes it.

The two headers are separate defenses:

  • Host is wrong on every rebound request, including the same-origin GET that opens the SSE stream, which carries no Origin. The SDK advisories (GHSA-w48q-cv73-mx4w, GHSA-9h52-p55h-vw2f) were fixed by validating Host on localhost.
  • Origin is what the transport spec requires, with a fixed status code.

So the scenario cannot tell whether a server meets the Origin MUST, and it cannot tell whether a server validates Host.

Example: the everything-server in this repo uses createMcpExpressApp() from @modelcontextprotocol/sdk 1.29, which validates Host only. With a localhost Host and Origin: http://evil.example.com it returns 200, and it passes the current scenario 2/2.

Spec text

Streamable HTTP, draft ("Security & Endpoint"), and the same wording in 2025-11-25 ("Security Warning"):

  1. Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks.
    • If the Origin header is present and invalid, servers MUST respond with HTTP 403 Forbidden. The HTTP response body MAY comprise a JSON-RPC error response that has no id.

The 403 sentence came from modelcontextprotocol/modelcontextprotocol#1439. No spec text requires Host validation.

Proposal

Add two checks to the existing dns-rebinding-protection scenario. No new scenario. localhost-host-rebinding-rejected and localhost-host-valid-accepted keep their ids and behavior.

Check Request Pass Miss
localhost-host-only-rebinding-rejected Host: evil.example.com, no Origin any 4xx WARNING
localhost-origin-only-rebinding-rejected localhost Host, Origin: http://evil.example.com exactly 403 FAILURE

The Origin check is FAILURE because both sentences above are MUST. The Host check is WARNING because there is no spec keyword behind it. If you would rather it be FAILURE (the scenario text already says "MUST validate the Host or Origin header") or INFO, that is a one-line change.

modelcontextprotocol/modelcontextprotocol#3370

#3370 (open, labeled bug) proposes changing this text: Host validation MUST for servers that grant access by network position, Origin validation MUST only when ambient credentials are accepted and SHOULD otherwise, 403 unchanged when a server does validate Origin. As of 2026-09-27 it has no maintainer reply and no linked spec PR. The Streamable HTTP file on main last changed in 4d260f4 (2026-08-21), and the Security section reads as quoted above.

The expected status (403) and the two miss severities are three constants in one commented block in src/scenarios/server/dns-rebinding.ts. If #3370 lands as proposed, the change is: Host miss WARNING to FAILURE, Origin miss FAILURE to WARNING, 403 unchanged.

Pass and fail examples

Results at 2025-11-25:

Server combined Host-only Origin-only valid accepted
everything-server with an added Origin check SUCCESS SUCCESS SUCCESS SUCCESS
everything-server as on main (Host only) SUCCESS SUCCESS FAILURE (200) SUCCESS
new dns-rebinding-host-only.ts SUCCESS SUCCESS FAILURE (200) SUCCESS
new dns-rebinding-origin-only.ts SUCCESS WARNING (200) SUCCESS SUCCESS
no-dns-rebinding-protection.ts FAILURE WARNING FAILURE SUCCESS

The branch adds the Origin check to the everything-server so it stays green, adds the two fixtures, and asserts each row in negative.test.ts.

Against real SDK conformance servers (conformance sdk ... --mode server --scenario dns-rebinding-protection):

  • python-sdk main (f1b6589): 4/4 pass. Its localhost default validates both headers and returns 421 for Host, 403 for Origin.
  • typescript-sdk v1.x (289ac2c, 1.30.1): 3/4. The Origin-only check fails with 200; its conformance server uses localhostHostValidation() only. It would need a fix or a baseline entry. The v2 conformance server on main uses the same middleware; I have not run it.

Related fixture bug

no-dns-rebinding-protection.ts declares inputSchema: { message: { type: 'string' } }, which SDK 1.29 rejects, so the fixture returns 500 for every request. The existing negative test passes on that 500, not on the missing protection. The branch switches it to z.string(); after that it returns 200 to the forged request and the check fails for the right reason.

Branch: https://github.com/modelcontextprotocol/conformance/compare/main...ninadphalak:conformance:server-dns-rebinding-split-checks

主要言語
TypeScript
スター
127
フォーク
107
平均マージ
2日 22時間
マージ済み PR（30日）
5

環境構築

はじめの一歩

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

modelcontextprotocol/conformance のほかの issue

modelcontextprotocol/conformance の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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