dns-rebinding-protection: check Host and Origin validation separately
Maintainer thường phản hồi trong vòng 4 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 45/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ệ
- typescript
- Lĩnh vực
- security, testing-qa
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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:
Hostis wrong on every rebound request, including the same-origin GET that opens the SSE stream, which carries noOrigin. The SDK advisories (GHSA-w48q-cv73-mx4w, GHSA-9h52-p55h-vw2f) were fixed by validatingHoston localhost.Originis 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"):
- Servers MUST validate the
Originheader on all incoming connections to prevent DNS rebinding attacks.
- If the
Originheader is present and invalid, servers MUST respond with HTTP 403 Forbidden. The HTTP response body MAY comprise a JSON-RPC error response that has noid.
- draft: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/ab3a39c13bd23be691c2760e1c6c5c15a64582e1/docs/specification/draft/basic/transports/streamable-http.mdx#L54-L68
- 2025-11-25: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/ab3a39c13bd23be691c2760e1c6c5c15a64582e1/docs/specification/2025-11-25/basic/transports.mdx#L74-L84
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 forOrigin. - 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.
- Ngôn ngữ chính
- TypeScript
- Star
- 127
- Fork
- 107
- Merge trung bình
- 2 ngày 22 giờ
- Pull request đã merge (30 ngày)
- 5
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của modelcontextprotocol/conformance
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
modelcontextprotocol/conformance#531 ·
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
modelcontextprotocol/conformance#530 ·
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
modelcontextprotocol/conformance#519 ·
Maintainer thường phản hồi trong vòng 4 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
modelcontextprotocol/conformance#315 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 4 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
modelcontextprotocol/conformance#312 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 4 ngày
Tất cả issue của modelcontextprotocol/conformance
Issue tương tự
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
inu-appcenter/memorIN-frontend#106 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
kind/bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 7 ngày
-
[Bug] @deck.gl/arcgis dist import resolves to unpublished @deck.gl/core source path (9.3.11, 9.4.0)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
fix: CopyFilters ignores tabĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
CSCfi/sd-search-ui#145 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add: Cbeebies pl SDĐang mởcheck:passed streams:add
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày