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

Inizia in src/mcp/shared/auth_utils.py, in check_resource_allowed(), e riproduci gli esempi di segmenti punto e di codifica percentuale dell’issue. Verifica che i percorsi richiesti normalizzati non possano uscire dalla risorsa configurata, mantenendo al contempo la semantica della barra finale, quindi esegui i test pertinenti delle utility di autenticazione.

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.