FACT COPY · DE
Faktenfassung: MCP-Server-Sicherheit und Autorisierung
Bedrohungsmodell, OAuth, Tokenbindung, Zustimmungen, SSRF, Sessions und Least Privilege.
Originalseite: https://travel-mcp.com/de/mcp-server/sicherheit-autorisierung/
Sachliche Zusammenfassung
MCP-Sicherheit ist eine Kette unabhängiger Kontrollen. Kein Token, Prompt oder Clientdialog darf allein über den Zugriff auf sensible Daten und Nebenwirkungen entscheiden.
Bedrohungsmodell
Zu betrachten sind bösartige Clients, kompromittierte Server, manipulierte Ressourcen, überprivilegierte Nutzer und angegriffene Downstream-Systeme. Trust Boundaries werden im Datenflussdiagramm mit Identitäten, Tokens und Datenklassen markiert.
Prompt Injection ist ein Eingabekanal, aber nicht die einzige Gefahr. Confused Deputy, Token Theft, Session Hijacking, SSRF und DNS-Rebinding betreffen die Protokoll- und Netzwerkschicht.
OAuth und Protected Resource
Ein HTTP-MCP-Server fungiert als geschützte Ressource. Er veröffentlicht beziehungsweise referenziert Metadaten und validiert Access Tokens. Signatur, Issuer, Ablauf, Audience und Scope werden geprüft.
PKCE, exakte Redirect-URI-Prüfung und sicherer State schützen den Authorization Code Flow. Kurzlebige Tokens und rotierende Refresh Tokens begrenzen Diebstahlfolgen.
Token-Passthrough und Confused Deputy
Token-Passthrough umgeht Audience- und Serverkontrollen und ist verboten. Für Downstream-APIs verwendet der Server korrekt delegierte oder eigene Credentials mit minimalem Umfang.
MCP-Proxies benötigen Zustimmung pro Client. Eine frühere Zustimmung für eine statische Third-Party-Client-ID darf nicht einen neuen, potenziell bösartigen MCP-Client autorisieren.
SSRF und Netzwerkzugriffe
OAuth Discovery kann URLs aus nicht vertrauenswürdigen Metadaten laden. Server und Clients blockieren private, Loopback- und Link-local-Ziele, prüfen jeden Redirect und verlangen in Produktion HTTPS.
DNS-Rebinding und alternative IP-Kodierungen machen handgeschriebene Filter gefährlich. Egress-Proxies und etablierte URL-Prüfbibliotheken bieten Defense in Depth.
Least Privilege und Audit
Scopes begrenzen Capability-Gruppen; objektbezogene Policies begrenzen konkrete Datensätze. Jede schreibende Aktion wird der ursprünglichen Nutzeridentität zugeordnet.
Audit erfasst Entscheidung und Wirkung, aber keine Secrets. Regelmäßige Reviews entfernen ungenutzte Scopes und verwaiste Serverregistrierungen.
FAQ
Reicht OAuth für die Sicherheit?
Nein. OAuth adressiert Autorisierung auf Protokollebene. Eingabevalidierung, Fachrechte, Nutzerzustimmung, Ausgabekontrolle und Betriebssicherheit bleiben zusätzlich nötig.
Sind lokale Server sicherer?
Sie vermeiden entfernte Netzwerkrisiken, laufen aber häufig mit weitreichenden Benutzerrechten. Sandboxing und minimale Dateizugriffe bleiben erforderlich.