Add role-specific MCP authorization and transport security scenarios

[adithyan-ak]

Summary

Add bounded, role-specific MCP authorization and transport security scenarios for protocol failures that have concrete specification requirements and real implementation advisories.

This must not be implemented as one universal MCP exploit module. Confused-deputy flows, token audience/passthrough, OAuth metadata SSRF, session hijacking, authorization-URL handling, and DNS-rebinding protection target different components and require different controlled harnesses.

Current state

AgentHound currently provides:

• MCP stdio, Streamable HTTP, and legacy SSE connectivity;
• strict TLS verification by default;
• static header support from discovered configuration;
• cross-host redirect protection for supplied authorization headers;
• read-only authentication posture classification;
• MCP tool-description poisoning through an operator-configured administrative endpoint.

It does not currently provide OAuth protected-resource/authorization-server discovery, PKCE, dynamic client registration, token minting, browser authorization handling, two-principal session testing, or malicious authorization/resource-server fixtures.

OAuth libraries may be present transitively in the collector dependency graph, but no reusable MCP OAuth security harness exists.

Attack classes and target roles

Implement each class as a separate scenario with explicit prerequisites and applicability:

A. Resource/audience binding and token passthrough

Target: MCP resource server or OAuth proxy.

• Verify that a token issued for resource A is rejected by resource B.
• Verify that the MCP server does not accept or forward an inbound client token as an upstream API token.
• Use synthetic tokens minted by an operator-owned authorization server fixture.
• Never reuse real third-party production tokens in automated tests.

B. Confused-deputy consent flow

Target: MCP OAuth proxy using an upstream identity provider or shared/static upstream client.

• Exercise browser/session-bound consent and callback state requirements.
• Use two isolated principals/clients and a controlled identity-provider fixture.
• Treat required user interaction, skipped upstream consent, and callback binding as explicit preconditions.
• Do not generalize a failure to MCP servers that do not implement this proxy pattern.

C. OAuth metadata/discovery SSRF

Target: MCP client or server-side MCP client performing protected-resource/authorization-server metadata discovery, especially with DCR.

• Serve controlled malicious metadata that references operator-owned callback targets.
• Record whether the target fetches an unauthorized destination, follows redirects, or resolves prohibited address classes.
• Keep default probes within operator-owned infrastructure. Requests to private, link-local, loopback, cloud-metadata, or arbitrary third-party targets require explicit allowlisting and engagement authorization.
• Bound redirect count, DNS resolution, request count, response bytes, and total duration.

D. Streamable HTTP session ownership/hijacking

Target: stateful Streamable HTTP server.

• Establish a victim session and attempt access from a second isolated principal/client.
• Test session-to-user binding and duplicate SSE stream handling independently.
• Distinguish guessed/stolen session prerequisites from server ownership-validation failure.
• Never claim session compromise solely because a session header exists.

E. Authorization URL validation

Target: MCP client/UI that opens or executes authorization URLs.

• Supply controlled authorization metadata containing invalid schemes and shell-sensitive forms.
• Verify rejection before browser/shell execution.
• Run client-specific browser/shell behavior in an isolated harness or optional sidecar; the lean collector must not gain a general browser runtime.

F. Origin/DNS-rebinding conformance

Target: Streamable HTTP server.

• Origin validation is a required mitigation, not an attack class by itself.
• Send controlled valid, absent, and disallowed Origin values and verify protocol-conformant handling.
• Keep any DNS-rebinding demonstration inside a dedicated lab; do not perform uncontrolled rebinding against arbitrary targets.

Architecture

• Implement scenarios through the campaign contracts tracked in Harden and complete the verified attack campaign substrate #82.
• Each scenario must declare target role, prerequisites, mutation class, required fixtures, budget, oracle observation, and cleanup behavior.
• Reuse MCP transport code only where doing so does not hide the raw protocol property under test.
• Add controlled fixture interfaces for authorization server, resource server, malicious MCP server, browser/redirect handler, and second client/principal.
• Prefer deterministic protocol observations: HTTP status, token audience rejection, outbound request receipt at a trusted sink, duplicate-stream response, or URL rejection.
• Model behavior and user interaction are not guaranteed repeatable and must not be used as the sole oracle.

Safety requirements

• Default to plan/dry-run; require explicit authorized commit.
• Use synthetic identities, clients, codes, and tokens by default.
• Never serialize bearer tokens, authorization codes, PKCE verifiers, client secrets, session IDs, or fetched metadata bodies into graph evidence/logs.
• Scope credentials and headers to the original authority.
• Enforce request, redirect, response-size, and duration budgets.
• SSRF fixtures must fail closed when destination ownership/allowlisting is not established.
• Report exploitation/oracle outcome separately from fixture cleanup.

Evidence and graph integration

• Emit versioned, sanitized scenario reports first.
• Add graph nodes/edges for OAuth clients, authorization servers, sessions, or redirects only when they materially improve path analysis; do not expand schema merely to mirror protocol traffic.
• A positive finding must name the tested role and exact failed invariant.
• A non-applicable target is not_runnable, not secure.
• Timeout, user cancellation, unsupported OAuth flow, and missing fixture are indeterminate, not negative evidence.

Non-goals

• A full OAuth provider implementation for production use.
• Automated exploitation of real third-party identity providers.
• Generic browser automation in the collector binary.
• Treating all MCP transports or servers as equally exposed.
• Converting specification conformance failures into CVE claims.
• Origin validation as proof of complete DNS-rebinding resistance.

Acceptance criteria

• Scenarios are split by target role and prerequisites; no monolithic generic exploit command is introduced.
• Initial milestone implements at least token resource/audience binding and one transport/client scenario.
• Every scenario has a deterministic protocol observation and explicit indeterminate/not-runnable states.
• Controlled fixtures use synthetic credentials and operator-owned endpoints.
• SSRF destinations are ownership-checked/allowlisted and strictly budgeted.
• Session testing uses two isolated principals/clients and verifies ownership, not only possession of a session ID.
• Authorization URL tests cannot execute arbitrary local commands in the collector process.
• Evidence contains no token/code/session secret material.
• Finding text identifies the target role, prerequisite, tested invariant, and observed result.

Test plan

• Unit tests for role applicability, outcome matrices, redaction, budgets, redirects, and destination allowlisting.
• Fixture integration tests for synthetic AS/RS token audience mismatch and forbidden passthrough.
• Two-client session ownership and duplicate-stream tests.
• Malicious metadata fixture tests for allowed callback, redirect escape, private-address denial, and response-size cap.
• Authorization URL scheme/shell-character rejection tests.
• Compiled-binary tests proving secrets do not appear in stdout, JSON evidence, graph properties, or receipt files.
• Repository formatting, build, vet, race tests, dependency-boundary check, and collector-size check.

Documentation and sources

Update CLI, graph, post-processor, detection-rule, module-authoring, and operator safety docs as applicable.

Primary references:

• MCP Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
• MCP Authorization specification: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
• MCP Transport specification: https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
• FastMCP token-resource advisory: GHSA-5h2m-4q8j-pqpj
• FastMCP confused-deputy advisory: GHSA-rww4-4w9c-7733
• Spring MCP discovery SSRF advisory: GHSA-qjp4-4jvr-xqg3
• MCP Ruby SDK session advisory: GHSA-qvqr-5cv7-wh35

Relevant code

• modules/mcp/transport.go
• modules/mcp/enumerate.go
• modules/mcppoison/
• sdk/campaign/
• collector/cli/campaign.go
• server/internal/analysis/processors/

Dependency

Depends on the hardened campaign evidence and safety contracts in #82. Client/browser-specific authorization URL testing may require an optional harness outside the lean collector.