SSRF- und Netzwerk-Policy

Grundsatz

Jede Tool-URL, jeder Redirect und jede Browsernavigation ist nicht vertrauenswürdig. HTTP(S)-Requests werden ausschließlich auf dem privaten Proxy ausgeführt. Die lokale Policy des Proxy ist maßgeblich, auch wenn der öffentliche MCP-Server den Auftrag bereits akzeptiert hat.

Prüfpfad

URL muss absolut, ohne Userinfo und Fragment sowie auf ein freigegebenes http-/https-Schema beschränkt sein.
Host- und Port-Allow-/Deny-Regeln werden vor DNS angewendet; Deny gewinnt.
Der private Proxy löst den Namen mit begrenztem Timeout auf und prüft jede gelieferte IPv4-/IPv6-Adresse. Eine verbotene Adresse verwirft das gesamte Ergebnis.
Der Dialer verbindet nur zu einer Adresse aus genau diesem geprüften Ergebnis; eine zweite Namensauflösung findet nicht statt. URL-Host, HTTP-Host und TLS-SNI bleiben korrekt.
Jeder Redirect und jede Browser-Subresource durchläuft die Regeln erneut.

Umgebungsabhängige HTTP-Proxys werden nicht übernommen, weil sie die Dial-Prüfung umgehen könnten.

Default-Deny für nicht öffentliche Ziele

Ohne Opt-in sind unter anderem Loopback, private IPv4-Netze, IPv6 ULA, Link-local, Multicast, unspecified, reservierte und Dokumentationsbereiche sowie bekannte Cloud-Metadatenziele gesperrt. Eine Host-Allowlist allein hebt diese Sperre nicht auf.

Interne Ziele benötigen das einzige explizite Opt-in allow_cidrs, möglichst als einzelner /32- oder /128-Host, kombiniert mit Host und Port:

http:
  network_policy:
    allowed_hosts: [service.example]
    allowed_ports: [8443]
    allow_cidrs: [192.0.2.10/32]

192.0.2.10 und service.example sind reservierte Dokumentationswerte und müssen im Deployment durch das exakt freizugebende Ziel ersetzt werden. Eine breite RFC1918-/ULA-Freigabe ist zu vermeiden. deny_cidrs, Deny-Hosts und Deny-Ports haben auch gegenüber Allows Vorrang.

Weitere Grenzen

Methoden-Allowlist und sichere Headernormalisierung;
Authorization/Cookie nur nach explizitem Opt-in, niemals Proxy-Authorization, Host oder Hop-by-hop-/Framing-Header;
separate Limits für Requestbody, Wire-Response und dekomprimierten Body;
Redirect-, Parallelitäts-, DNS-, Connect- und Requestlimits;
Profile verändern nur freigegebene Identitätsheader, nie Zielpolicy, Credentials, Cookies, TLS-Fingerprint oder Rate Limits;
Media besitzt zusätzlich eine Host-/Port-Allowlist und benötigt Egress- Isolation für extractor-gesteuerte Folgeverbindungen; InnerTube-Transcript- HTTP läuft über dieselbe httpexec-Policy;
Browser verwendet dieselbe HTTP-Netzwerk-Policy für Navigation, Redirects und Subresources.

Defense in Depth

Die Anwendungs-Policy ersetzt keine Firewall, Container-/Pod-Egress-Regeln oder Zielauthentisierung. Ein bewusst erlaubtes internes Ziel bleibt gegenüber unerwünschten Methoden, Datenabfluss und anwendungsspezifischen Schwachstellen exponiert. Freigaben werden deshalb minimal gehalten und regelmäßig geprüft.

Normative Implementierungsbeschreibung: Netzwerk-Policy und SSRF-Schutz.