Säkra ditt MCP-system: 11 vanliga risker och hur du skyddar dig mot dem

MCP-risker delas i stora drag in i tre kategorier: manipulering av LLM:er, data- och åtkomstsäkerhet samt sårbarheter i infrastrukturen.

Eftersom MCP-servrar ofta ger åtkomst till ett stort antal interna system är den potentiella säkerhetsrisken hög. Sannolikheten beror dock i hög grad på hur systemet är konfigurerat.

Det finns många åtgärder som privatpersoner och företag kan vidta för att se till att deras system är skyddade, och skyddsrutinerna bör alltid stå i proportion till de funktioner och data som anslutna MCP-servrar kan exponera.

Vad är MCP och MCP-säkerhet?

Model Context Protocol (MCP) är en öppen standard som Anthropic har skapat för att ansluta LLM-baserade appar (eller värdar) till externa system.

Ett MCP-system består av tre kärnkomponenter: värden, klienten och servern. Värden, som ofta är en AI-assistent, ansluter till en extern MCP-server via en klient. Den kan sedan skicka förfrågningar om att köra extern funktionalitet (verktyg) eller hämta data (resurser) eller promptar som ska läggas till i LLM:ens kontextfönster.

Förstora

MCP-säkerhet avser de protokoll som skyddar anslutningarna och komponenterna i ett MCP-system. Det finns flera viktiga utmaningar som är unika för MCP, bland annat att AI-appar ofta har agentiska förmågor och att skadliga instruktioner kan bäddas in i meddelanden.

Välkända problem som inte är specifika för MCP, till exempel promptinjektion, svag autentisering och osäkra integrationer från tredje part, innebär också problem. Som för alla datorsystem bygger skyddet av MCP på en kombination av rutiner, som att bara använda betrodda servrar, och tekniska kontroller, som API-gateways.

Hur allvarliga är MCP-hoten?

MCP har snabbt blivit en populär LLM-teknik, och många organisationer och konsumentappar använder den. Eftersom MCP-servrar är program skrivna i kod har de sårbarheter precis som alla andra applikationer.

När organisationer använder MCP i kontrollerade driftsättningar är det dock i allmänhet säkert. Det är en betydande skillnad mellan att bygga ett system med betrodda servrar och verifierade behörigheter och att koppla en autonom agent till ett dussin servrar som inte har granskats.

Hot nr 1: Indirekt promptinjektion

En angripare kan placera instruktioner riktade till LLM:en i ett dokument, en webbsida eller verktygsutdata som en MCP-server returnerar. Om värden lägger till detta material i kontextfönstret finns det en risk att LLM:en misstar det för äkta instruktioner.

Dessutom kan dessa instruktioner verka rimliga på ytan. Ett hämtat supportärende kan till exempel uppmana LLM:en att exportera känsliga kunduppgifter innan den genererar ett svar.

Så skyddar du dig mot indirekt promptinjektion

Promptinjektioner bör normalt hanteras på värdnivå. Externt innehåll bör märkas som ej betrott, och förfrågningar om känslig information bör kräva ett informerat godkännande från en människa i loopen. Säkerhetstester där skadliga dokument eller data anropas för att se hur värden och LLM:en reagerar kan också vara till hjälp.

Hot nr 2: Verktygsförgiftning och rug pulls

Vid en verktygsförgiftningsattack läggs skadlig kod till i ett MCP-verktygs beskrivning eller schema. Det kan påverka LLM:en i upptäcktsfasen, när MCP först exponerar tillgängliga verktyg.

Förstora

En rug pull är en särskild typ av verktygsförgiftning där godkända metadata ändras. Den här formen av verktygsförgiftning kan ändra hur en modell använder betrodda verktyg i stället för att direkt anropa ett skadligt verktyg.

Så skyddar du dig mot verktygsförgiftning och rug pulls

Värden bör granska den fullständiga definitionen av varje verktyg innan det används och jämföra den med en lista över godkända, betrodda verktyg för att på så sätt upptäcka eventuella ändringar. Parameterkontroller kan hjälpa till att identifiera potentiellt farliga funktioner och flagga dem.

Hot nr 3: Överdrivna behörigheter

Det är vanligt att användare ger MCP-servrar och anslutna LLM:er (via värden) fler behörigheter än vad som krävs för en uppgift. Det kan till exempel vara skrivbehörighet när läsbehörighet hade räckt, eller fullständig åtkomst till ett internt filsystem (som Google Drive).

Den här omfattande behörighetsglidningen kan öka skadeomfånget för andra sårbarheter, som skadliga verktygsanrop. Det är vanligt att behörigheter ”läggs ihop” när användare beviljar privilegier under sitt dagliga arbete med AI-verktyg i ett företag (ackumulering av privilegier).

Så skyddar du dig mot överdrivna behörigheter

Det mest direkta sättet att skydda sig mot det här problemet är att begränsa behörigheter och OAuth-omfång (läsning, skrivning, fullständig åtkomst osv.). Användargodkännanden, särskilt för känsliga åtgärder, är en viktig del av detta, men behörigheter bör också styras på systemnivå (operativsystem, MCP-värd och server).

Hot nr 4: Svag autentisering och auktorisering

Autentisering verifierar identiteten hos användare eller applikationer som ansluter till en MCP-server. Auktorisering anger vilka verktyg och resurser de har åtkomst till.

Felaktigt konfigurerade MCP-servrar kan acceptera förfrågningar eller tokens utan att korrekt autentisera användare eller upprätthålla åtkomstbegränsningar. Dessutom kan stulna inloggningsuppgifter ge illasinnade aktörer åtkomst om valideringen är svag.

Så skyddar du dig mot svag autentisering och auktorisering

OAuth-baserad autentisering för fjärranslutna MCP-servrar, kortlivade tokens och rollbaserad åtkomstkontroll (RBAS) är alla åtgärder som hjälper till att motverka svag auktorisering. Rollbaserad åtkomst är användbar eftersom den hindrar användare från att komma åt data och verktyg utöver sina behörigheter, även om servern själv har åtkomst.

Hot nr 5: Läckta och missbrukade inloggningsuppgifter

MCP-servrar använder rutinmässigt inloggningsuppgifter som API-nycklar och OAuth-åtkomsttokens för att ansluta till externa tjänster. Om dessa exponeras eller missbrukas kan angripare få åtkomst till känsliga data och funktioner.

Ett exempel är token passthrough, där en MCP-server vidarebefordrar en åtkomsttoken till en annan tjänst utan att verifiera att den faktiskt är avsedd för den mottagande tjänsten. Det kan i sin tur leda till läckor om den mottagande tjänsten har otillräckligt skydd.

Så skyddar du dig mot läckta och missbrukade inloggningsuppgifter

Kortlivade tokens med snävt omfång och rotation av inloggningsuppgifter är effektiva för att begränsa i vilken utsträckning läckta data kan användas av illasinnade aktörer. API-nycklar och inloggningsuppgifter bör alltid lagras säkert med hjälp av en hemlighetshanterare.

Hot nr 6: Confused deputy-attacker

En confused deputy-attack inträffar när en angripare lurar en betrodd applikation att använda sina behörigheter för att utföra en åtgärd som inte har godkänts av en legitim användare. I det här fallet är det MCP-servern som är ställföreträdaren (”the deputy”).

Förstora

Angriparen utnyttjar en sårbarhet i MCP-servern (som svag OAuth-verifiering) för att köra en skadlig process, till exempel ett verktygsanrop eller en datahämtning.

Så skyddar du dig mot confused deputy-attacker

Auktoriseringsvalidering, där varje verktygsanrop verifieras som tillhörande en specifik användare, hjälper till att begränsa confused deputy-attacker. Dessutom bör känsliga åtgärder, som dataexport, kräva uttrycklig auktorisering.

Hot nr 7: Skadliga servrar och komprometterade beroenden

MCP-servrar kan innehålla skadlig kod (de är i grunden externa program) eller förlita sig på komprometterade beroenden, som bibliotek från tredje part. Det här är ett problem i programvarans leveranskedja snarare än ett problem som är unikt för MCP.

Ett enkelt sätt som detta kan ske på är om en angripare distribuerar en integration som verkar vara legitim. När den väl har konfigurerats kan den stjäla och återanvända inloggningsuppgifter, komma åt känsliga data och utföra obehöriga åtgärder.

Så skyddar du dig mot skadliga servrar och komprometterade beroenden

Installera endast MCP-servrar från betrodda och granskade källor. Granska om möjligt deras kod och kontrollera alltid eventuella externa beroenden. Se till att servrarna uppdateras och patchas regelbundet.

Hot nr 8: Förfalskning av förfrågningar på serversidan (SSRF)

Förfalskning av förfrågningar på serversidan (SSRF) innebär att en angripare lurar en MCP-server att skicka nätverksförfrågningar till interna adresser som användaren inte hade för avsikt att komma åt.

Det kan hända när en MCP-server exponerar ett verktyg som hämtar information från en URL. Om en angripare kan påverka URL-parametern kan angriparen ändra den till valfri nätverksadress, till exempel ett internt API eller en molntjänst. Det kan leda till att känsliga data hämtas och eventuellt görs åtkomliga

Så skyddar du dig mot förfalskning av förfrågningar på serversidan (SSRF)

MCP-servrar bör alltid validera URL:er, blockera åtkomst till begränsade interna nätverksadresser och förhindra utgående nätverksåtkomst. Omdirigeringar bör också följa samma protokoll.

Hot nr 9: Sessionskapning

Vid sessionskapning tar en angripare kontroll över en aktiv anslutning mellan en MCP-klient och en server.

Angriparen kan till exempel stjäla en sessionsidentifierare från en dåligt skyddad MCP-applikation (t.ex. en värd eller en server). Om MCP-servern accepterar identifieraren kan angriparen potentiellt anropa verktyg med användarens legitima behörigheter.

Så skyddar du dig mot

Risken för sessionskapning kan minskas med strikt identitetsverifiering i alla applikationer i ett MCP-system. Kryptering mellan MCP-klienter och fjärrservrar är också avgörande för att förhindra att sessionsidentifierare kan identifieras.

Hot nr 10: Mix-up-attacker

Vid en mix-up-attack lurar angriparen en MCP-klient att skicka en auktoriseringskod till en skadlig auktoriseringsserver som befinner sig mellan klienten och MCP-servern. En auktoriseringsserver är en applikation som utfärdar OAuth-åtkomsttokens efter att ha kontrollerat att den begärda åtkomsten är auktoriserad.

Förstora

Om en MCP-värd ansluter till flera tjänster som var och en använder en egen auktoriseringsserver kan en angripare potentiellt kontrollera en av dem (kanske genom att registrera en skadlig tjänst) och få klienten att skicka en auktoriseringskod som utfärdats av en legitim server till den skadliga servern. Den här förväxlingen kan göra det möjligt för angriparen att utge sig för att vara den auktoriserade applikationen och få åtkomst till skyddade tjänster.

Så skyddar du dig mot mix-up-attacker

MCP-klienter bör verifiera auktoriseringsserverns identitet under hela OAuth-processen. Mer specifikt bör de jämföra serverns utfärdaridentifierare (iss) med den förväntade identiteten och avvisa avvikelser.

Hot nr 11: Komprometterade lokala MCP-servrar

Många MCP-servrar körs på användarens lokala dator. Användaren kan ha installerat servern från en tredje part eller byggt den själv. Om en angripare lyckas kompromettera den lokala MCP-servern kan angriparen potentiellt få åtkomst till stora delar av det lokala systemet.

En angripare kan få åtkomst på flera olika sätt. Angriparen kan distribuera en skadlig server förklädd till en legitim integration, ändra en MCP-värds konfiguration så att den utfärdar ett skadligt kommando eller komma åt en MCP-server som körs i en miljö med otillräckliga säkerhetskontroller, till exempel via DNS-rebinding, som lurar en webbläsare att skicka förfrågningar till en localhost-tjänst.

Så skyddar du dig mot komprometterade lokala MCP-servrar

Isolering i sandlåda och strikta samtyckesrutiner är viktiga när du använder lokala MCP-servrar. MCP-servrar bör endast installeras från betrodda leverantörer, och operativsystemets behörigheter bör begränsa vilka kataloger de har åtkomst till.

MCP-sårbarheter är ofta gamla hot i ny förklädnad

MCP-sårbarheter uppstår ofta när välkända risker och attackmetoder tillämpas på nya sätt. MCP ger angripare nya sätt att utnyttja dessa sårbarheter genom samspelet mellan LLM:er, MCP-servrar och externa tjänster.

Det finns naturligtvis hot som är specifika för MCP. Det är dock värt att komma ihåg att vedertagna säkerhetsprotokoll, som att tillämpa strikt auktorisering, använda betrodda leverantörer och skydda sig mot promptinjektioner, räcker långt för att skydda alla MCP-implementeringar.