Zabezpiecz swój system MCP: 11 typowych zagrożeń i sposoby ochrony przed nimi

Zagrożenia związane z MCP można ogólnie podzielić na trzy kategorie: manipulacja modelami LLM, bezpieczeństwo danych i dostępu oraz podatności infrastruktury.

Ponieważ serwery MCP często zapewniają dostęp do wielu systemów wewnętrznych, potencjalne ryzyko dla bezpieczeństwa jest wysokie. Prawdopodobieństwo jego wystąpienia zależy jednak w dużej mierze od konfiguracji.

Osoby prywatne i firmy mogą podjąć wiele kroków, aby zapewnić ochronę swoich systemów, a stosowane protokoły zawsze powinny być proporcjonalne do możliwości i danych, które mogą udostępniać podłączone serwery MCP.

Czym jest MCP i bezpieczeństwo MCP?

Model Context Protocol (MCP) to otwarty standard opracowany przez Anthropic, służący do łączenia aplikacji opartych na modelach LLM (czyli hostów) z systemami zewnętrznymi.

System MCP składa się z trzech podstawowych komponentów: hosta, klienta i serwera. Host, którym często jest asystent AI, łączy się z zewnętrznym serwerem MCP za pośrednictwem klienta. Może następnie wysyłać żądania uruchomienia zewnętrznych funkcji (narzędzi) lub pobrania danych (zasobów) albo promptów, które zostaną dodane do okna kontekstowego modelu LLM.

Powiększ

Bezpieczeństwo MCP to protokoły chroniące połączenia i komponenty w systemie MCP. Istnieje kilka kluczowych wyzwań charakterystycznych dla MCP, m.in. to, że aplikacje AI często mają możliwości agentowe, a w wiadomościach mogą być osadzone złośliwe instrukcje.

Problemy stwarzają też znane zagrożenia, które nie dotyczą wyłącznie MCP, takie jak wstrzykiwanie promptów, słabe uwierzytelnianie i niebezpieczne integracje zewnętrzne. Jak każdy system komputerowy, MCP opiera swoją ochronę na połączeniu protokołów proceduralnych, takich jak korzystanie wyłącznie z zaufanych serwerów, oraz zabezpieczeń technicznych, takich jak bramy API.

Jak poważne są zagrożenia związane z MCP?

MCP szybko stał się popularną technologią LLM i korzysta z niego wiele organizacji oraz aplikacji konsumenckich. Ponieważ serwery MCP są programami napisanymi w kodzie, mają podatności jak każda inna aplikacja.

Jednak gdy organizacje korzystają z MCP w kontrolowanych wdrożeniach, jest on zasadniczo bezpieczny. Istnieje ogromna różnica między zbudowaniem systemu z zaufanymi serwerami i zweryfikowanymi uprawnieniami a podłączeniem autonomicznego agenta do kilkunastu niesprawdzonych serwerów.

Zagrożenie nr 1: pośrednie wstrzykiwanie promptów

Atakujący może umieścić instrukcje skierowane do modelu LLM w dokumencie, na stronie internetowej lub w danych wyjściowych narzędzia zwracanych przez serwer MCP. Jeśli host doda te treści do okna kontekstowego, model LLM może uznać je za prawdziwe instrukcje.

Co więcej, na pierwszy rzut oka instrukcje te mogą wydawać się właściwe. Na przykład pobrane zgłoszenie do pomocy technicznej może nakazać modelowi LLM wyeksportowanie poufnych danych klientów przed wygenerowaniem odpowiedzi.

Jak chronić się przed pośrednim wstrzykiwaniem promptów

Wstrzykiwaniu promptów należy zazwyczaj przeciwdziałać na poziomie hosta. Treści zewnętrzne powinny być oznaczane jako niezaufane, a żądania dostępu do poufnych informacji powinny wymagać świadomej zgody człowieka nadzorującego proces (human in the loop). Pomocne mogą być również testy bezpieczeństwa polegające na wywoływaniu złośliwych dokumentów lub danych, aby sprawdzić, jak zareagują host i model LLM.

Zagrożenie nr 2: zatruwanie narzędzi i ataki typu rug pull

W ataku polegającym na zatruwaniu narzędzi złośliwy kod jest dodawany do opisu lub schematu narzędzia MCP. Może to wpłynąć na model LLM w fazie wykrywania, gdy MCP po raz pierwszy prezentuje dostępne narzędzia.

Powiększ

Rug pull to szczególny rodzaj zatruwania narzędzi, w którym zmieniane są zatwierdzone metadane. Ta forma zatruwania narzędzi może zmienić sposób, w jaki model korzysta z zaufanych narzędzi, zamiast bezpośrednio wywoływać złośliwe narzędzie.

Jak chronić się przed zatruwaniem narzędzi i atakami typu rug pull

Przed użyciem każdego narzędzia host powinien sprawdzić jego pełną definicję i porównać ją z listą zatwierdzonych, zaufanych narzędzi, co pozwala wykryć wszelkie zmiany. Weryfikacja parametrów może pomóc w wykrywaniu potencjalnie niebezpiecznych możliwości i ich oznaczaniu.

Zagrożenie nr 3: nadmierne uprawnienia

Użytkownicy często przyznają serwerom MCP i połączonym modelom LLM (za pośrednictwem hosta) więcej uprawnień, niż wymaga dane zadanie. Na przykład uprawnienia do zapisu, gdy wystarczyłby dostęp tylko do odczytu, lub pełny dostęp do wewnętrznego systemu plików (takiego jak Google Drive).

Takie rozległe narastanie uprawnień może zwiększać zasięg szkód wynikających z innych podatności, takich jak złośliwe wywołania narzędzi. Uprawnienia często się „sumują”, gdy użytkownicy przyznają kolejne uprawnienia w trakcie codziennej pracy z narzędziami AI w firmie (akumulacja uprawnień).

Jak chronić się przed nadmiernymi uprawnieniami

Najbardziej bezpośrednim sposobem ochrony przed tym problemem jest ograniczenie uprawnień i zakresów OAuth (odczyt, zapis, pełny dostęp itp.). Ważną rolę odgrywa tu zatwierdzanie przez użytkownika, zwłaszcza w przypadku operacji wrażliwych, ale uprawnienia powinny być też kontrolowane na poziomie systemu (systemu operacyjnego, hosta MCP i serwera).

Zagrożenie nr 4: słabe uwierzytelnianie i autoryzacja

Uwierzytelnianie weryfikuje tożsamość użytkowników lub aplikacji łączących się z serwerem MCP. Autoryzacja określa, do jakich narzędzi i zasobów mają oni dostęp.

Źle skonfigurowane serwery MCP mogą akceptować żądania lub tokeny bez prawidłowego uwierzytelnienia użytkowników lub egzekwowania ograniczeń dostępu. Ponadto przy słabej weryfikacji skradzione dane uwierzytelniające mogą umożliwić uzyskanie dostępu osobom o złych zamiarach.

Jak chronić się przed słabym uwierzytelnianiem i autoryzacją

Uwierzytelnianie oparte na OAuth w przypadku zdalnych serwerów MCP, tokeny o krótkim czasie ważności i kontrola dostępu oparta na rolach (RBAS) to środki, które pomagają ograniczyć ryzyko związane ze słabą autoryzacją. Dostęp oparty na rolach jest przydatny, ponieważ uniemożliwia użytkownikom dostęp do danych i narzędzi wykraczających poza ich uprawnienia, nawet jeśli sam serwer ma do nich dostęp.

Zagrożenie nr 5: wycieki i niewłaściwe wykorzystanie danych uwierzytelniających

Serwery MCP rutynowo używają danych uwierzytelniających, takich jak klucze API i tokeny dostępu OAuth, do łączenia się z usługami zewnętrznymi. Jeśli zostaną one ujawnione lub niewłaściwie wykorzystane, atakujący mogą uzyskać dostęp do poufnych danych i funkcji.

Przykładem jest przekazywanie tokenów (token passthrough), gdy serwer MCP przekazuje token dostępu do innej usługi bez sprawdzenia, czy faktycznie jest on przeznaczony dla usługi odbierającej. To z kolei może doprowadzić do wycieku, jeśli usługa odbierająca ma niewystarczające zabezpieczenia.

Jak chronić się przed wyciekami i niewłaściwym wykorzystaniem danych uwierzytelniających

Tokeny o krótkim czasie ważności i wąskim zakresie oraz rotacja danych uwierzytelniających skutecznie ograniczają możliwość wykorzystania danych, które wyciekły, przez osoby o złych zamiarach. Klucze API i dane uwierzytelniające należy zawsze bezpiecznie przechowywać w menedżerze sekretów.

Zagrożenie nr 6: ataki typu confused deputy

Atak typu confused deputy („zdezorientowany zastępca”) ma miejsce, gdy atakujący nakłania zaufaną aplikację do wykorzystania jej uprawnień w celu wykonania działania, na które nie zezwolił uprawniony użytkownik. W tym przypadku „zastępcą” jest serwer MCP.

Powiększ

Atakujący wykorzystuje podatność serwera MCP (np. słabą weryfikację OAuth), aby uruchomić złośliwy proces, taki jak wywołanie narzędzia lub pobranie danych.

Jak chronić się przed atakami typu confused deputy

Weryfikacja autoryzacji, w ramach której każde wywołanie narzędzia jest sprawdzane pod kątem przypisania do konkretnego użytkownika, pomaga ograniczyć ataki typu confused deputy. Ponadto działania wrażliwe, takie jak eksport danych, powinny wymagać wyraźnej autoryzacji.

Zagrożenie nr 7: złośliwe serwery i przejęte zależności

Serwery MCP mogą zawierać złośliwy kod (w gruncie rzeczy są to programy zewnętrzne) lub opierać się na przejętych zależnościach, takich jak biblioteki innych firm. Jest to problem łańcucha dostaw oprogramowania, a nie problem charakterystyczny wyłącznie dla MCP.

Jednym z prostych scenariuszy jest sytuacja, w której atakujący rozpowszechnia integrację wyglądającą na legalną. Po skonfigurowaniu może ona wykradać i ponownie wykorzystywać dane uwierzytelniające, uzyskiwać dostęp do poufnych danych i wykonywać nieautoryzowane operacje.

Jak chronić się przed złośliwymi serwerami i przejętymi zależnościami

Instaluj serwery MCP wyłącznie z zaufanych i sprawdzonych źródeł. Jeśli to możliwe, przejrzyj ich kod i zawsze sprawdzaj wszelkie zależności zewnętrzne. Dbaj o to, aby na serwerach regularnie instalowano aktualizacje i poprawki.

Zagrożenie nr 8: fałszowanie żądań po stronie serwera (SSRF)

Fałszowanie żądań po stronie serwera (SSRF) polega na tym, że atakujący nakłania serwer MCP do wysyłania żądań sieciowych na adresy wewnętrzne, do których użytkownik nie zamierzał uzyskać dostępu.

Może do tego dojść, gdy serwer MCP udostępnia narzędzie pobierające informacje spod adresu URL. Jeśli atakujący może wpłynąć na parametr URL, może zmienić go na wybrany adres sieciowy, np. wewnętrznego interfejsu API lub usługi w chmurze. W rezultacie poufne dane mogą zostać pobrane i potencjalnie udostępnione

Jak chronić się przed fałszowaniem żądań po stronie serwera (SSRF)

Serwery MCP powinny zawsze weryfikować adresy URL, blokować dostęp do zastrzeżonych wewnętrznych adresów sieciowych i uniemożliwiać wychodzący dostęp do sieci. Te same zasady powinny obowiązywać również w przypadku przekierowań.

Zagrożenie nr 9: przejęcie sesji

Przejęcie sesji polega na tym, że atakujący przejmuje kontrolę nad aktywnym połączeniem między klientem MCP a serwerem.

Atakujący może na przykład wykraść identyfikator sesji ze słabo zabezpieczonej aplikacji MCP (np. hosta lub serwera). Jeśli serwer MCP zaakceptuje ten identyfikator, atakujący może potencjalnie wywoływać narzędzia z wykorzystaniem prawowitych uprawnień użytkownika.

Jak się chronić

Ryzyko przejęcia sesji można ograniczyć dzięki rygorystycznej weryfikacji tożsamości we wszystkich aplikacjach systemu MCP. Niezbędne jest również szyfrowanie połączeń między klientami MCP a serwerami zdalnymi, aby nie dało się ustalić identyfikatorów sesji.

Zagrożenie nr 10: ataki typu mix-up

W ataku typu mix-up atakujący nakłania klienta MCP do wysłania kodu autoryzacji do złośliwego serwera autoryzacji, który znajduje się między klientem a serwerem MCP. Serwer autoryzacji to aplikacja, która wystawia tokeny dostępu OAuth po sprawdzeniu, czy żądany dostęp jest autoryzowany.

Powiększ

Jeśli host MCP łączy się z wieloma usługami, z których każda korzysta z innego serwera autoryzacji, atakujący może potencjalnie przejąć kontrolę nad jednym z tych serwerów (np. rejestrując złośliwą usługę) i sprawić, że klient wyśle kod autoryzacji wystawiony przez prawowity serwer do serwera złośliwego. Takie pomylenie może umożliwić atakującemu podszycie się pod autoryzowaną aplikację i uzyskanie dostępu do chronionych usług.

Jak chronić się przed atakami typu mix-up

Klienci MCP powinni weryfikować tożsamość serwera autoryzacji przez cały proces OAuth. W szczególności powinni porównywać identyfikator wystawcy serwera (iss) z oczekiwaną tożsamością i odrzucać niezgodności.

Zagrożenie nr 11: przejęcie lokalnego serwera MCP

Wiele serwerów MCP działa na lokalnym komputerze użytkownika. Użytkownik może zainstalować serwer od zewnętrznego dostawcy lub zbudować go samodzielnie. Jeśli atakującemu uda się przejąć taki lokalny serwer MCP, może potencjalnie uzyskać dostęp do dużej części systemu lokalnego.

Atakujący może uzyskać dostęp na różne sposoby. Może rozpowszechniać złośliwy serwer podszywający się pod legalną integrację, zmodyfikować konfigurację hosta MCP tak, aby wydał on złośliwe polecenie, lub uzyskać dostęp do serwera MCP działającego w środowisku z niewystarczającymi zabezpieczeniami, np. za pomocą techniki DNS rebinding, która nakłania przeglądarkę do wysyłania żądań do usługi działającej na localhost.

Jak chronić się przed przejęciem lokalnego serwera MCP

Podczas korzystania z lokalnych serwerów MCP ważne są izolacja w piaskownicy (sandboxing) i rygorystyczne procedury wyrażania zgody. Serwery MCP należy instalować wyłącznie od zaufanych dostawców, a uprawnienia systemu operacyjnego powinny ograniczać, do których katalogów mają one dostęp.

Podatności MCP to często stare zagrożenia w nowej odsłonie

Podatności MCP często wynikają z nowych zastosowań znanych zagrożeń i metod ataku. MCP otwiera przed atakującymi nowe sposoby wykorzystywania tych podatności poprzez interakcje między modelami LLM, serwerami MCP i usługami zewnętrznymi.

Oczywiście istnieją zagrożenia specyficzne dla MCP. Warto jednak pamiętać, że standardowe protokoły bezpieczeństwa, takie jak egzekwowanie rygorystycznej autoryzacji, korzystanie z zaufanych dostawców i ochrona przed wstrzykiwaniem promptów, w dużym stopniu przyczyniają się do ochrony każdej implementacji MCP.