Zabezpečte svůj systém MCP: 11 běžných rizik a jak se před nimi chránit

Rizika MCP lze obecně rozdělit do tří kategorií: manipulace s LLM, zabezpečení dat a přístupu a zranitelnosti infrastruktury.

Protože servery MCP často poskytují přístup k široké škále interních systémů, potenciální bezpečnostní riziko je vysoké. Pravděpodobnost však do velké míry závisí na konfiguraci.

Jednotlivci i podniky mohou podniknout řadu kroků, aby zajistili ochranu svých systémů, a bezpečnostní protokoly by vždy měly odpovídat schopnostem a datům, které mohou připojené servery MCP zpřístupnit.

Co je MCP a zabezpečení MCP?

Model Context Protocol (MCP) je otevřený standard vytvořený společností Anthropic pro propojení aplikací založených na LLM (neboli hostitelů) s externími systémy.

Systém MCP má tři hlavní komponenty: hostitele, klienta a server. Hostitel, kterým je často asistent AI, se připojuje k externímu serveru MCP prostřednictvím klienta. Poté může odesílat požadavky na spuštění externích funkcí (nástrojů) nebo na načtení dat (zdrojů) či promptů, které se přidají do kontextového okna LLM.

Zvětšit

Zabezpečení MCP označuje protokoly, které chrání připojení a komponenty v systému MCP. Existuje několik klíčových výzev, které jsou pro MCP jedinečné, včetně toho, že aplikace AI mají často agentní schopnosti a do zpráv mohou být vloženy škodlivé instrukce.

Problémy přinášejí i známé hrozby, které nejsou specifické pro MCP, jako je prompt injection, slabá autentizace a nebezpečné integrace třetích stran. Stejně jako každý počítačový systém se MCP při ochraně spoléhá na kombinaci procedurálních protokolů, jako je používání pouze důvěryhodných serverů, a technických kontrol, jako jsou brány API.

Jak závažné jsou hrozby MCP?

MCP se rychle stal populární technologií v oblasti LLM a používá ho mnoho organizací i spotřebitelských aplikací. Servery MCP jsou programy napsané v kódu, a proto mají zranitelnosti jako kterákoli jiná aplikace.

Pokud však organizace používají MCP v kontrolovaných nasazeních, je obecně bezpečný. Mezi vybudováním systému s důvěryhodnými servery a ověřenými oprávněními a připojením autonomního agenta k tuctu neprověřených serverů je propastný rozdíl.

Hrozba č. 1: Nepřímá prompt injection

Útočník může umístit instrukce určené pro LLM do dokumentu, webové stránky nebo výstupu nástroje, který vrací server MCP. Pokud hostitel tento obsah přidá do kontextového okna, existuje možnost, že je LLM zamění za skutečné instrukce.

Navíc se tyto instrukce mohou na první pohled zdát vhodné. Například načtený tiket podpory může LLM nařídit, aby před vygenerováním odpovědi exportoval citlivé záznamy zákazníků.

Jak se chránit před nepřímou prompt injection

Útoky typu prompt injection by se obvykle měly řešit na úrovni hostitele. Externí obsah by měl být označen jako nedůvěryhodný a požadavky na citlivé informace by měly vyžadovat informovaný souhlas člověka zapojeného do procesu (human in the loop). Užitečné může být také bezpečnostní testování, při kterém se volají škodlivé dokumenty nebo data, aby se zjistilo, jak hostitel a LLM zareagují.

Hrozba č. 2: Otrávení nástrojů a útoky typu rug pull

Při útoku otrávením nástroje se do popisu nebo schématu nástroje MCP přidá škodlivý kód. To může ovlivnit LLM ve fázi zjišťování, kdy MCP poprvé zpřístupní dostupné nástroje.

Zvětšit

Rug pull je zvláštní typ otrávení nástroje, při kterém dojde ke změně schválených metadat. Tato forma otrávení nástroje může změnit způsob, jakým model používá důvěryhodné nástroje, místo aby přímo vyvolala škodlivý nástroj.

Jak se chránit před otrávením nástrojů a útoky typu rug pull

Hostitel by měl před použitím každého nástroje zkontrolovat jeho úplnou definici a porovnat ji se seznamem schválených důvěryhodných nástrojů, a odhalit tak případné změny. Kontroly parametrů mohou pomoci identifikovat potenciálně nebezpečné schopnosti a označit je.

Hrozba č. 3: Nadměrná oprávnění

Uživatelé běžně udělují serverům MCP a připojeným LLM (prostřednictvím hostitele) více oprávnění, než je pro daný úkol nutné. Například oprávnění k zápisu, když by stačilo oprávnění jen pro čtení, nebo úplný přístup k internímu systému souborů (například Google Drive).

Toto rozsáhlé plíživé rozšiřování oprávnění může zvětšit rozsah škod u dalších zranitelností, jako jsou škodlivá volání nástrojů. Je běžné, že se oprávnění postupně „sčítají“, jak uživatelé v podniku udělují práva v průběhu své každodenní práce s nástroji AI (akumulace oprávnění).

Jak se chránit před nadměrnými oprávněními

Nejpřímějším způsobem ochrany před tímto problémem je omezení oprávnění a rozsahů OAuth (čtení, zápis, úplný přístup atd.). Důležitou součástí jsou schválení uživatelem, zejména u citlivých operací, ale oprávnění by se měla řídit i na úrovni systému (operační systém, hostitel MCP a server).

Hrozba č. 4: Slabá autentizace a autorizace

Autentizace ověřuje identitu uživatelů nebo aplikací, které se připojují k serveru MCP. Autorizace určuje, ke kterým nástrojům a zdrojům mají přístup.

Špatně nakonfigurované servery MCP mohou přijímat požadavky nebo tokeny, aniž by správně ověřily uživatele nebo vynutily omezení přístupu. Kromě toho mohou odcizené přihlašovací údaje umožnit útočníkům získat přístup, pokud je ověřování slabé.

Jak se chránit před slabou autentizací a autorizací

Autentizace na bázi OAuth pro vzdálené servery MCP, krátkodobé tokeny a řízení přístupu na základě rolí (RBAS) jsou opatření, která pomáhají zmírnit rizika slabé autorizace. Přístup na základě rolí je užitečný, protože brání uživatelům v přístupu k datům a nástrojům nad rámec jejich oprávnění, i když k nim má přístup samotný server.

Hrozba č. 5: Úniky a zneužití přihlašovacích údajů

Servery MCP se k externím službám běžně připojují pomocí přihlašovacích údajů, jako jsou klíče API a přístupové tokeny OAuth. Pokud dojde k jejich vyzrazení nebo zneužití, útočníci mohou získat přístup k citlivým datům a funkcím.

Jedním z příkladů je předávání tokenů (token passthrough), kdy server MCP přepošle přístupový token jiné službě, aniž by ověřil, že je skutečně určen pro přijímající službu. To může následně vést k úniku, pokud přijímající služba nemá dostatečnou ochranu.

Jak se chránit před úniky a zneužitím přihlašovacích údajů

Krátkodobé tokeny s úzce vymezeným rozsahem a rotace přihlašovacích údajů účinně omezují, do jaké míry mohou útočníci uniklá data zneužít. Klíče API a přihlašovací údaje by se měly vždy bezpečně ukládat pomocí správce tajných údajů.

Hrozba č. 6: Útoky typu confused deputy

K útoku typu confused deputy („zmatený zástupce“) dochází, když útočník přiměje důvěryhodnou aplikaci, aby pomocí svých oprávnění provedla akci, kterou legitimní uživatel neautorizoval. V tomto případě je zástupcem server MCP.

Zvětšit

Útočník zneužije zranitelnost serveru MCP (například slabé ověřování OAuth) ke spuštění škodlivého procesu, jako je volání nástroje nebo načtení dat.

Jak se chránit před útoky typu confused deputy

Útoky typu confused deputy pomáhá omezit ověřování autorizace, při kterém se u každého volání nástroje ověřuje, že patří konkrétnímu uživateli. Kromě toho by citlivé akce, například exporty dat, měly vyžadovat výslovnou autorizaci.

Hrozba č. 7: Škodlivé servery a kompromitované závislosti

Servery MCP mohou obsahovat škodlivý kód (v podstatě jde o externí programy) nebo se spoléhat na kompromitované závislosti, například knihovny třetích stran. Jde o problém dodavatelského řetězce softwaru, nikoli o problém jedinečný pro MCP.

Jedním jednoduchým způsobem, jak k tomu může dojít, je, když útočník distribuuje integraci, která vypadá legitimně. Po nastavení může krást a znovu používat přihlašovací údaje, přistupovat k citlivým datům a provádět neautorizované operace.

Jak se chránit před škodlivými servery a kompromitovanými závislostmi

Instalujte servery MCP pouze z důvěryhodných a prověřených zdrojů. Pokud je to možné, zkontrolujte jejich kód a vždy prověřte všechny externí závislosti. Zajistěte, aby se servery pravidelně aktualizovaly a záplatovaly.

Hrozba č. 8: Podvržení požadavku na straně serveru (SSRF)

K podvržení požadavku na straně serveru (SSRF) dochází, když útočník přiměje server MCP, aby odesílal síťové požadavky na interní adresy, ke kterým uživatel neměl v úmyslu přistupovat.

K tomu může dojít, když server MCP zpřístupní nástroj, který načítá informace z adresy URL. Pokud útočník může ovlivnit parametr URL, může ho změnit na požadovanou síťovou adresu, například interní API nebo cloudovou službu. To může vést k načtení citlivých dat a jejich případnému zpřístupnění

Jak se chránit před podvržením požadavku na straně serveru (SSRF)

Servery MCP by měly vždy ověřovat adresy URL, blokovat přístup k omezeným interním síťovým adresám a zabránit odchozímu síťovému přístupu. Tento postup by se měl uplatňovat i u přesměrování.

Hrozba č. 9: Únos relace

Při únosu relace útočník převezme kontrolu nad aktivním připojením mezi klientem MCP a serverem.

Útočník může například odcizit identifikátor relace ze špatně zabezpečené aplikace MCP (např. hostitele nebo serveru). Pokud server MCP tento identifikátor přijme, útočník může potenciálně volat nástroje s legitimními oprávněními uživatele.

Jak se chránit před

Riziko únosu relace lze snížit přísným ověřováním identity ve všech aplikacích systému MCP. Šifrování mezi klienty MCP a vzdálenými servery je také nezbytné, aby nedošlo k odhalení identifikátorů relací.

Hrozba č. 10: Útoky typu mix-up

Při útoku typu mix-up útočník přiměje klienta MCP, aby odeslal autorizační kód škodlivému autorizačnímu serveru, který se nachází mezi klientem a serverem MCP. Autorizační server je aplikace, která vydává přístupové tokeny OAuth poté, co ověří, že je požadovaný přístup autorizován.

Zvětšit

Pokud se hostitel MCP připojuje k více službám, z nichž každá používá jiný autorizační server, útočník může potenciálně jeden z nich ovládnout (třeba registrací škodlivé služby) a přimět klienta, aby autorizační kód vydaný legitimním serverem odeslal škodlivému serveru. Tato záměna může útočníkovi umožnit vydávat se za autorizovanou aplikaci a získat přístup k chráněným službám.

Jak se chránit před útoky typu mix-up

Klienti MCP by měli během celého procesu OAuth ověřovat identitu autorizačního serveru. Konkrétně by měli porovnat identifikátor vydavatele serveru (iss) s očekávanou identitou a neshody odmítnout.

Hrozba č. 11: Kompromitace lokálního serveru MCP

Mnoho serverů MCP běží na lokálním počítači uživatele. Uživatel může server nainstalovat od třetí strany nebo si ho sestavit sám. Pokud útočník dokáže tento lokální server MCP kompromitovat, může potenciálně získat přístup k velké části lokálního systému.

Útočník může získat přístup různými způsoby. Může distribuovat škodlivý server maskovaný jako legitimní integrace, upravit konfiguraci hostitele MCP tak, aby vydal škodlivý příkaz, nebo přistoupit k serveru MCP běžícímu v prostředí s nedostatečnými bezpečnostními kontrolami, například pomocí DNS rebindingu, který přiměje prohlížeč odesílat požadavky na službu na localhostu.

Jak se chránit před kompromitací lokálního serveru MCP

Při používání lokálních serverů MCP je důležitý sandboxing a přísné protokoly souhlasu. Servery MCP by se měly instalovat výhradně od důvěryhodných poskytovatelů a oprávnění operačního systému by měla omezovat, ke kterým adresářům mají přístup.

Zranitelnosti MCP jsou často staré hrozby v novém hávu

Zranitelnosti MCP často vycházejí z nového uplatnění známých rizik a metod útoku. MCP přináší útočníkům nové způsoby, jak tyto zranitelnosti zneužít prostřednictvím interakcí mezi LLM, servery MCP a externími službami.

Hrozby specifické pro MCP samozřejmě existují. Je však dobré mít na paměti, že standardní bezpečnostní protokoly, jako je vynucování přísné autorizace, používání důvěryhodných poskytovatelů a ochrana před útoky typu prompt injection, výrazně přispějí k ochraně jakékoli implementace MCP.