check_resource_allowed(): path matching skips dot-segment/percent-encoding normalization (auth-boundary bypass)

Bắt đầu trong src/mcp/shared/auth_utils.py tại check_resource_allowed() và tái hiện các ví dụ về dot-segment và mã hóa phần trăm từ issue. Xác minh rằng các đường dẫn được yêu cầu đã chuẩn hóa không thể thoát khỏi tài nguyên được cấu hình, đồng thời vẫn giữ nguyên ngữ nghĩa của dấu gạch chéo ở cuối, sau đó chạy các bài kiểm thử tiện ích xác thực liên quan.

Summary

check_resource_allowed() in src/mcp/shared/auth_utils.py performs hierarchical path matching with str.startswith() after only trailing-slash normalization. It does not resolve dot-segments (.., .) or decode percent-encoding, so a requested resource can satisfy startswith(configured) while resolving to a path outside the configured resource.

This is a confused-deputy / path-traversal gap at the resource-authorization boundary: any downstream resource server that normalizes paths (most do) will serve a different resource than the one the SDK authorized.

Reproduction

from mcp.shared.auth_utils import check_resource_allowed

# Access to /api is configured; /admin is NOT
configured = "https://mcp.example.com/api"
requested  = "https://mcp.example.com/api/../admin"

print(check_resource_allowed(requested, configured))  # -> True (should be False)

The current code normalizes to /api/../admin/ vs /api/, and "/api/../admin/".startswith("/api/") is True. The resolved path is /admin. Percent-encoded variants (%2e%2e) bypass it the same way.

Impact

Where the result gates access to a protected resource, a caller can craft a resource indicator that passes the check but points elsewhere. Severity depends on deployment, but it's an auth-boundary correctness bug, not cosmetic.

Fix

Decode percent-encoding and resolve dot-segments (posixpath.normpath after unquote) on both paths before the startswith comparison, preserving trailing-slash semantics. A patch implementing exactly this was opened as #2585 and closed in the post-v2 backlog sweep with the note to reopen if still relevant against v2 — filing this issue per CONTRIBUTING so it can be triaged. The bug is present verbatim on current main. Happy to refresh the PR against v2 once triaged.