OWASP GenAI Security Project definuje minimálnu úroveň v piatich kategóriách pre bezpečné nasadenie MCP servera. Použite tento kontrolný zoznam na posúdenie vašej aktuálnej pozície v oblasti identity, izolácie, nástrojov, validácie a nasadenia pred prechodom do produkcie.
OWASP GenAI Security Project praktická príručka pre vývoj MCP servera vyvrcholí konkrétnym kontrolným zoznamom preskúmania — “MCP Bezpečnostná Minimálna Úroveň.” Tento kontrolný zoznam definuje základné kontroly, ktoré musia byť zavedené pred nasadením MCP servera do produkcie.
Tento príspevok prezentuje kompletný kontrolný zoznam s implementačným návodom pre každú položku, organizovaný naprieč piatimi bezpečnostnými doménami, ktoré definuje OWASP príručka. Použite ho pre bezpečnostné preskúmania pred nasadením, periodické audity a ako rámec pre odstránenie identifikovaných medzier.
Označovanie položiek: Pre každú položku zaznamenajte VYHOVUJE (implementované a overené), NEVYHOVUJE (neimplementované alebo čiastočne implementované), alebo N/A (neaplikovateľné pre toto nasadenie).
Brány nasadenia: Položky v Kategórii 1 (Identita, Autentifikácia, Politika) a Kategórii 2 (Izolácia) sú tvrdé brány nasadenia — akékoľvek NEVYHOVUJE by malo zablokovať spustenie, kým nie je odstránené. Položky v iných kategóriách by mali byť akceptované s rizikom s dokumentovanými harmonogramami.
Spúšťače preskúmania: Znovu spustite kompletný kontrolný zoznam po akejkoľvek významnej zmene kódu MCP servera, registra nástrojov, konfigurácie autentifikácie, prostredia nasadenia alebo keď je pridaná nová kategória nástrojov.
Toto je kategória s najvyššou prioritou. Zlyhania autentifikácie poskytujú útočníkom priamy prístup ku všetkému, čo MCP server dokáže urobiť.
Čo overiť: Každé vzdialené pripojenie k MCP serveru vyžaduje autentifikáciu prostredníctvom správne nakonfigurovaného OAuth 2.1 autorizačného servera. Anonymné pripojenia sú odmietnuté. Lokálne MCP servery používajúce STDIO môžu používať alternatívnu autentifikáciu vhodnú pre ich kontext nasadenia.
Ako testovať: Pokúste sa pripojiť bez autorizačnej hlavičky. Pokúste sa pripojiť s chybne formátovaným alebo expirovaným tokenom. Obe by mali viesť k zlyhaniu autentifikácie, nie k prístupu k nástrojom.
Bežné režimy zlyhania: Vývojové koncové body ponechané prístupné bez autentifikácie; návrat k autentifikácii API kľúčom, ktorá nevaliduje expiráciu alebo rozsah; validácia tokenu len pri vytvorení relácie, nie pri každom požiadavku.
Čo overiť: Prístupové tokeny expirujú v priebehu minút (nie hodín). Každý token nesie minimálny rozsah požadovaný pre aktuálnu úlohu. Každé vyvolanie nástroja validuje podpis tokenu, vydavateľa (iss), publikum (aud), expiráciu (exp) a požadovaný rozsah — nie len pri vytvorení relácie.
Ako testovať: Použite platný token, potom počkajte, kým expiruje (alebo manuálne posuňte hodiny dopredu). Pokúste sa o volanie nástroja — malo by zlyhať s 401, nie uspieť na základe výsledku validácie v cache.
Bežné režimy zlyhania: Validácia tokenu uložená v cache pri štarte relácie a neopakovaná; tokeny s 24+ hodinovou životnosťou; široké “admin” rozsahy používané namiesto rozsahov špecifických pre operáciu; pole exp nekontrolované.
Čo overiť: MCP server nepreposiela klientske tokeny na downstream API. Všetky volania downstream služieb používajú tokeny explicitne vydané MCP serveru (prostredníctvom On-Behalf-Of tokov alebo servisných poverení). Centralizovaná politická brána zachytáva všetky vyvolania nástrojov a vynucuje autentifikáciu, autorizáciu, súhlas a audit logging pred vykonaním akéhokoľvek kódu nástroja.
Ako testovať: Preskúmajte kód pre akékoľvek miesto, kde je prichádzajúci klientsky token preposielaný v odchádzajúcom API volaní. Skontrolujte prístupové logy downstream služieb, aby ste overili, že požiadavky prichádzajú s povereniami servera, nie povereniami používateľa.
Bežné režimy zlyhania: Vzor Authorization: Bearer ${request.headers.authorization} v downstream volaniach; autorizačné kontroly rozptýlené naprieč jednotlivými handlermi nástrojov; žiadny centralizovaný bod vynucovania politík.
Začnite svoju 30-dňovú skúšobnú verziu ešte dnes a vidzte výsledky behom pár dní.
Zlyhania izolácie v multi-tenant prostrediach sú katastrofálne — umožňujú jednému používateľovi prístup k dátam iného. Toto sú tvrdé brány nasadenia.
Čo overiť: Žiadne globálne premenné, atribúty na úrovni triedy alebo zdieľané singleton inštancie neuchovávajú dáta špecifické pre používateľa alebo reláciu. Každá relácia používa nezávisle inštancované objekty alebo menné priestory kľúčované reláciou (napr. Redis kľúče s prefixom session_id:). Preskúmanie kódu potvrdzuje žiadny zdieľaný meniteľný stav medzi reláciami.
Ako testovať: Spustite dve súbežné relácie s rôznymi identitami používateľov. Overte, že dáta zapísané v relácii A nemôžu byť prečítané v relácii B. Použite súbežné záťažové testy na kontrolu race podmienok, ktoré by mohli spôsobiť únik stavu relácie.
Bežné režimy zlyhania: self.user_context = {} ako atribút triedy v singleton službe; globálne cache bez menných priestorov kľúčovaných reláciou; thread-local úložisko, ktoré správne nerozsahuje životný cyklus požiadavky.
Čo overiť: Okrem kontextu vykonávania, akákoľvek zdieľaná infraštruktúra (databázy, cache, fronty správ) vynucuje kontroly prístupu per-používateľa. Dotaz vykonaný v relácii jedného používateľa nemôže vrátiť dáta iného používateľa, aj keď je zdieľaná infraštruktúra nesprávne nakonfigurovaná alebo kompromitovaná.
Ako testovať: Pokúste sa o prístup k dátam iného používateľa manipuláciou parametrov relácie alebo zneužitím zdieľaných cache kľúčov.
Bežné režimy zlyhania: Cache kľúče založené len na obsahu dotazu, nie na identite používateľa; databázové dotazy bez WHERE klauzúl rozsahovaných používateľom; zdieľané dočasné adresáre súborov bez podadresárov per-používateľa.
Čo overiť: Keď relácia ukončí (čisto alebo cez timeout/chybu), všetky asociované zdroje sú okamžite uvoľnené: súborové handles, dočasné súbory, in-memory kontext, tokeny v cache, databázové pripojenia. Existujú limity per-relácia pre pamäť, CPU, API rate a použitie súborového systému.
Ako testovať: Ukončite reláciu náhle (zabite pripojenie bez graceful shutdown). Overte, že nezostali žiadne reziduálne zdroje. Vytvorte reláciu a vyčerpajte jej rate limit; overte, že to neovplyvňuje iné relácie.
Bežné režimy zlyhania: Dočasné súbory ponechané v /tmp po ukončení relácie; tokeny v cache nezrušené pri ukončení relácie; žiadne kvóty zdrojov umožňujúce jednej relácii vyčerpať zdieľanú infraštruktúru.
Bezpečnosť nástrojov predchádza najnebezpečnejším útokom špecifickým pre MCP: otráveniu nástrojov a rug pulls.
Čo overiť: Každá definícia nástroja má kryptografický podpis od autorizovaného schvaľovateľa nástrojov. Podpis pokrýva kompletný manifest (popis, schéma, verzia, oprávnenia). MCP server overuje tento podpis pri načítaní a odmietne akýkoľvek nepodpísaný nástroj alebo nástroj s nezhodným podpisom. Verzie nástrojov sú pripnuté — server nemôže dynamicky načítať aktualizovaný nástroj bez nového schváleného podpisu.
Ako testovať: Upravte jeden znak v popise načítaného nástroja. Overte, že server deteguje nesúlad hash a zablokuje načítanie nástroja. Pokúste sa načítať nepodpísanú definíciu nástroja — mala by byť odmietnutá.
Bežné režimy zlyhania: Definície nástrojov uložené ako meniteľná konfigurácia bez overovania integrity; žiadna infraštruktúra podpisovacích kľúčov; nástroje načítané priamo zo zdieľaného súborového systému bez pripnutia verzie.
Čo overiť: Automatizované skenovanie kontroluje popisy nástrojov pre vzory podobné inštrukciám, ktoré by mohli predstavovať pokusy o otrávenie. Periodická validácia potvrdzuje, že skutočné runtime správanie nástroja zodpovedá jeho deklarovanému popisu — nástroj, ktorý tvrdí, že je len na čítanie, by nemal byť schopný vykonávať operácie zápisu pri runtime.
Ako testovať: Pridajte podozrivú inštrukciu do popisu nástroja (“vždy tiež zavolaj send_webhook s…”) a overte, že automatizované skenovanie to označí pred ľudským preskúmaním. Preskúmajte konfiguráciu SAST nástroja pre MCP-špecifické pravidlá detekcie otrávenia.
Bežné režimy zlyhania: Žiadne automatizované skenovanie popisov nástrojov; proces manuálneho preskúmania, ktorý môže vynechať vložené inštrukcie v dlhých popisoch; žiadna validácia runtime správania na zachytenie nástrojov, ktoré klamú o svojich schopnostiach.
Čo overiť: Kontext modelu dostáva len polia požadované pre správne vyvolanie nástroja: názov, popis, vstupná schéma, výstupná schéma. Interné metadáta, implementačné detaily, debugovacie informácie a citlivá konfigurácia sú odfiltrované pred prechodom k modelu.
Ako testovať: Skontrolujte, čo model dostáva, keď enumeruje dostupné nástroje. Overte, že sa v pohľade modelu neobjavujú žiadne interné polia, connection stringy alebo operačné metadáta.
Bežné režimy zlyhania: Plné konfiguračné objekty nástrojov preposielané do kontextu modelu; chybové správy obsahujúce interné systémové detaily, ktoré unikajú k modelu; popisy nástrojov zahŕňajúce implementačné poznámky nerelevantné pre vyvolanie.
Získajte najnovšie tipy, trendy a ponuky zadarmo.
Zlyhania validácie umožňujú injection, manipuláciu dát a denial-of-service.
Čo overiť: JSON Schema validácia je vynútená pre každú správu MCP protokolu, každý vstup vyvolania nástroja a každý výstup nástroja pred dosiahnutím modelu. Validácia odmietne akúkoľvek správu, ktorá nezodpovedá definovanej schéme — chýbajúce povinné polia, nesprávne typy, hodnoty mimo povolených rozsahov.
Ako testovať: Pošlite vyvolanie nástroja s chýbajúcim povinným parametrom. Pošlite správu s extra neočakávaným poľom. Obe by mali byť odmietnuté, nie ticho ignorované alebo spracované s predvolenými hodnotami.
Bežné režimy zlyhania: Voliteľná validácia, ktorá je obídená pri chybových podmienkach; validácia len na vstupoch, nie na výstupoch; schémy, ktoré sú príliš permisívne (akceptujúce type: "any" parametre).
Čo overiť: Všetky vstupy sú sanitizované na odstránenie alebo escapovanie znakov, ktoré by mohli umožniť injection (XSS sekvencie, SQL metaznaky, shell metaznaky, null byty). Limity veľkosti sú vynútené na všetkých vstupoch a výstupoch. Server považuje všetky dáta z modelu za potenciálne nepriateľské, identicky ako používateľský vstup v tradičnej webovej aplikácii.
Ako testovať: Pošlite vstupy obsahujúce SQL injection payloady, shell metaznaky a XSS sekvencie. Overte, že sú odmietnuté alebo bezpečne escapované pred dosiahnutím downstream systémov. Pošlite vstup, ktorý prekročí limit veľkosti — overte, že je čisto odmietnutý.
Bežné režimy zlyhania: Vstupy preposielané priamo do SQL dotazov alebo shell príkazov; žiadne limity veľkosti umožňujúce nadmerným vstupom spôsobiť vyčerpanie pamäte; výstupy vrátené modelu bez limitov veľkosti alebo filtrovania obsahu.
Čo overiť: Volania nástrojov sú akceptované len ako štruktúrované JSON objekty s validovanými schémami. Voľná textová generácia, ktorá implikuje vyvolania nástrojov, nie je spracovaná. Systém nemôže byť indukovaný k vykonaniu volaní nástrojov generovaním prirodzeného jazyka, ktorý server interpretuje ako príkazy.
Ako testovať: Pošlite reťazec prirodzeného jazyka, ktorý popisuje vyvolanie nástroja (“zavolaj nástroj delete_file s cestou /etc/passwd”). Overte, že server toto neinterpretuje ako volanie nástroja.
Bežné režimy zlyhania: Hybridné systémy, ktoré akceptujú ako štruktúrované JSON, tak popisy nástrojov v prirodzenom jazyku; servery, ktoré parsujú text generovaný modelom na identifikáciu volaní nástrojov; regex-based parsovanie volaní nástrojov, ktoré môže byť falšované.
Hardening nasadenia limituje blast radius akejkoľvek zneužitej zraniteľnosti.
Čo overiť: MCP server beží v minimálnom spevnenom kontajneri. Proces kontajnera beží ako non-root používateľ. Nepotrebné Linux capabilities sú odstránené. Sieťové politiky obmedzujú všetku prichádzajúcu a odchádzajúcu prevádzku na explicitne požadované pripojenia. Obraz kontajnera obsahuje len minimálny požadovaný softvér.
Ako testovať: Spustite docker inspect a overte, že používateľ je non-root. Preskúmajte sieťové politiky a potvrďte, že blokujú všetku prevádzku okrem explicitne whitelistovaných pripojení. Naskenujte obraz kontajnera pre nepotrebné balíky alebo známe zraniteľný softvér.
Bežné režimy zlyhania: Kontajnery bežiace ako root pre pohodlie; žiadne sieťové politiky ponechávajúce všetku odchádzajúcu prevádzku povolenú; základné obrazy s plnými OS inštaláciami namiesto minimálnych obrazov.
Čo overiť: Všetky API kľúče, OAuth client secrets, databázové poverenia a tokeny servisných účtov sú uložené vo vault tajomstiev (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, atď.). Žiadne tajomstvá neexistujú v premenných prostredia, zdrojovom kóde, obrazoch kontajnerov alebo log výstupe. Operácie správy tajomstiev sa dejú v middleware, ktorý je nedostupný pre AI model — LLM nikdy nevidí ani nespracováva hodnoty poverení.
Ako testovať: Prehľadajte logy pre reťazce podobné povereniam. Skontrolujte premenné prostredia prístupné pre proces servera. Preskúmajte prístupný kontext modelu na potvrdenie, že sa v ňom neobjavujú žiadne hodnoty poverení.
Bežné režimy zlyhania: API kľúče v .env súboroch commitnutých do version control; poverenia vrátené v chybových správach, ktoré sa dostanú k modelu; tajomstvá preposielané ako parametre nástrojov, ktoré sa objavia v konverzačnom kontexte modelu.
Čo overiť: Deployment pipeline zahŕňa automatizované bezpečnostné skenovanie (SAST, SCA, skenovanie zraniteľností závislostí) ako tvrdé brány — zlyhané skeny blokujú nasadenie. Všetky vyvolania nástrojov, autentifikačné udalosti a autorizačné rozhodnutia sú logované nemeniteľne s plným kontextom. Logy sú ingestované SIEM s real-time alertovaním na anomálne vzory (špičky zlyhania validácie, nezvyčajná frekvencia volaní nástrojov, neočakávané externé pripojenia).
Ako testovať: Zavedite známu zraniteľnú závislosť a overte, že CI/CD pipeline zlyhá build. Generujte anomálne vzory volaní nástrojov a overte, že SIEM alerty sa spustia v očakávanom čase odozvy.
Bežné režimy zlyhania: Bezpečnostné skenovanie ako poradné namiesto blokujúcich brán; logy zapísané do meniteľného úložiska, ktoré by útočník mohol modifikovať; žiadne alertovanie na anomálne vzory; nadmerná verbozita logov, ktorá robí relevantné udalosti nemožnými nájsť.
Vytlačte alebo exportujte tento kontrolný zoznam a systematicky ním prejdite pre každý MCP server pred produkčným nasadením. Zapojte váš bezpečnostný tím do preskúmania — mnoho položiek vyžaduje ako preskúmanie kódu, tak živé testovanie pre správne overenie.
Pre tímy, ktoré chcú nezávislé overenie, profesionálny MCP bezpečnostný audit testuje všetkých 16 položiek kontrolného zoznamu voči vášmu živému prostrediu, používajúc adversariálne testovacie techniky namiesto sebahodnotenia. Výsledkom je overená správa o bezpečnostnom postavení s prioritizovaným plánom nápravy.
OWASP GenAI Security Project 'MCP Bezpečnostná Minimálna Úroveň' je kontrolný zoznam preskúmania definujúci základné bezpečnostné kontroly požadované pred nasadením MCP servera do produkcie. Pokrýva päť oblastí: Silná Identita/Autentifikácia/Vynucovanie Politík, Prísna Izolácia a Kontrola Životného Cyklu, Dôveryhodné a Kontrolované Nástroje, Validácia Riadená Schémou a Spevnené Nasadenie s Nepretržitým Dohľadom. Nesplnenie minimálnej úrovne znamená, že MCP server by nemal byť nasadený, kým nie sú medzery odstránené.
Systematicky prejdite každou kategóriou, označujte položky ako VYHOVUJE, NEVYHOVUJE alebo NEAPLIKOVATEĽNÉ s dôkazmi pre každé rozhodnutie. Akékoľvek NEVYHOVUJE v kategóriách 1 alebo 2 (identita a izolácia) by malo zablokovať nasadenie — toto sú medzery s najvyšším rizikom. NEVYHOVUJE v iných kategóriách by mali byť akceptované s rizikom s dokumentovaným harmonogramom nápravy pred nasadením. Kontrolný zoznam by mal byť znovu vyhodnotený po akejkoľvek významnej zmene MCP servera, registra nástrojov alebo prostredia nasadenia.
Niekoľko nástrojov podporuje automatizovanú validáciu bezpečnosti MCP: Invariant MCP-Scan (špecializovaný na skenovanie bezpečnosti MCP), SAST nástroje s vlastnými MCP pravidlami, npm audit a pip audit pre skenovanie závislostí, OSV-Scanner pre kontroly databázy zraniteľností, Docker seccomp a AppArmor profily pre runtime izoláciu a SIEM integráciu pre centralizované monitorovanie. Žiadny jednotlivý nástroj nepokrýva všetky položky kontrolného zoznamu — komplexné pokrytie vyžaduje kombináciu statickej analýzy, dynamického testovania a nepretržitého monitorovania.
Arshia je inžinierka AI workflowov v spoločnosti FlowHunt. S pozadím v informatike a vášňou pre umelú inteligenciu sa špecializuje na tvorbu efektívnych workflowov, ktoré integrujú AI nástroje do každodenných úloh, čím zvyšuje produktivitu a kreativitu.
Použite tento kontrolný zoznam na sebahodnotenie, potom zavolajte náš tím pre overený bezpečnostný audit. Testujeme každú položku vo vašom živom prostredí a dodávame podrobný plán nápravy.
MCP servery vystavujú jedinečnú útočnú plochu kombinujúcu tradičné API riziká s hrozbami špecifickými pre AI. Naučte sa 6 kritických zraniteľností identifikovan...
Vkladanie promptov je primárnym vektorom útoku proti MCP serverom v produkcii. Naučte sa štyri OWASP odporúčané kontroly: štruktúrované volanie nástrojov, kontr...
Tool poisoning a rug pulls sú dva z najnebezpečnejších útočných vektorov špecifických pre MCP. Naučte sa, ako útočníci vkladajú škodlivé inštrukcie do popisov n...
