Sikre MCP-systemet ditt: 11 vanlige risikoer og hvordan du beskytter deg mot dem

MCP-risikoer faller stort sett inn i tre kategorier: LLM-manipulering, data- og tilgangssikkerhet og sårbarheter i infrastrukturen.

Fordi MCP-servere ofte gir tilgang til et stort utvalg interne systemer, er den potensielle sikkerhetsrisikoen høy. Sannsynligheten avhenger imidlertid sterkt av oppsettet.

Det finnes mange tiltak enkeltpersoner og virksomheter kan iverksette for å sikre at systemene deres er beskyttet, og protokollene bør alltid stå i forhold til funksjonene og dataene som tilkoblede MCP-servere kan eksponere.

Hva er MCP og MCP-sikkerhet?

Model Context Protocol (MCP) er en åpen standard utviklet av Anthropic for å koble LLM-baserte apper (eller verter) til eksterne systemer.

Det er tre kjernekomponenter i et MCP-system: verten, klienten og serveren. Verten, som ofte er en AI-assistent, kobler seg til en ekstern MCP-server via en klient. Den kan deretter sende forespørsler om å kjøre ekstern funksjonalitet (verktøy), hente data (ressurser) eller hente prompter som skal legges til i LLM-ens kontekstvindu.

Forstørr

MCP-sikkerhet viser til protokollene som beskytter tilkoblingene og komponentene i et MCP-system. Det finnes flere sentrale utfordringer som er unike for MCP, blant annet at AI-apper ofte har agentiske egenskaper, og at ondsinnede instruksjoner kan bygges inn i meldinger.

Kjente problemer som ikke er spesifikke for MCP, som promptinjeksjon, svak autentisering og usikre tredjepartsintegrasjoner, skaper også utfordringer. Som med alle datasystemer er MCP avhengig av en blanding av prosedyremessige protokoller, som å bare bruke pålitelige servere, og tekniske kontroller, som API-gatewayer, for å ivareta sikkerheten.

Hvor alvorlige er MCP-trusler?

MCP har raskt blitt en populær LLM-teknologi, og mange organisasjoner og forbrukerrettede apper bruker den. Fordi MCP-servere er programmer skrevet i kode, har de sårbarheter som alle andre applikasjoner.

Når organisasjoner bruker MCP i kontrollerte utrullinger, er det imidlertid generelt trygt. Det er en betydelig forskjell mellom å bygge et system med pålitelige servere og verifiserte tillatelser og å koble en autonom agent til et dusin ukontrollerte servere.

Trussel nr. 1: Indirekte promptinjeksjon

En angriper kan plassere instruksjoner rettet mot LLM-en i et dokument, en nettside eller verktøyutdata som en MCP-server returnerer. Hvis verten legger dette materialet til i kontekstvinduet, er det en mulighet for at LLM-en forveksler det med ekte instruksjoner.

I tillegg kan disse instruksjonene virke passende på overflaten. En hentet supportsak kan for eksempel be LLM-en om å eksportere sensitive kundeposter før den genererer et svar.

Slik beskytter du deg mot indirekte promptinjeksjon

Promptinjeksjoner bør vanligvis håndteres på vertsnivå. Eksternt innhold bør merkes som ikke-pålitelig, og forespørsler om sensitiv informasjon bør kreve informert godkjenning fra et menneske i loopen. Sikkerhetstesting der man kaller opp ondsinnede dokumenter eller data for å se hvordan verten og LLM-en reagerer, kan også være nyttig.

Trussel nr. 2: Verktøyforgiftning og rug pull-angrep

I et verktøyforgiftningsangrep legges ondsinnet kode til i beskrivelsen eller skjemaet til et MCP-verktøy. Dette kan påvirke LLM-en i oppdagelsesfasen, når MCP først eksponerer tilgjengelige verktøy.

Forstørr

Et rug pull-angrep er en spesiell type verktøyforgiftning der godkjente metadata endres. Denne formen for verktøyforgiftning kan endre måten en modell bruker pålitelige verktøy på, i stedet for å kalle opp et ondsinnet verktøy direkte.

Slik beskytter du deg mot verktøyforgiftning og rug pull-angrep

Verten bør inspisere hele definisjonen av hvert verktøy før det tas i bruk og sammenligne den med en liste over godkjente, pålitelige verktøy, slik at eventuelle endringer oppdages. Parameterkontroller kan bidra til å identifisere potensielt farlige funksjoner og flagge dem.

Trussel nr. 3: For omfattende tillatelser

Det er vanlig at brukere gir MCP-servere og tilkoblede LLM-er (via verten) flere tillatelser enn det som er nødvendig for en oppgave. For eksempel skrivetillatelser når lesetilgang ville vært nok, eller full tilgang til et internt filsystem (som Google Drive).

Denne omfattende tillatelsesglidningen kan øke skadeomfanget av andre sårbarheter, som ondsinnede verktøykall. Det er vanlig at tillatelser «hoper seg opp» når brukere gir rettigheter i løpet av det daglige arbeidet med AI-verktøy i en virksomhet (akkumulering av privilegier).

Slik beskytter du deg mot for omfattende tillatelser

Den mest direkte måten å beskytte seg mot dette problemet på er å begrense tillatelser og OAuth-omfang (lesing, skriving, full tilgang osv.). Brukergodkjenninger, særlig for sensitive operasjoner, er en viktig del av dette, men tillatelser bør også kontrolleres på systemnivå (operativsystem, MCP-vert og server).

Trussel nr. 4: Svak autentisering og autorisasjon

Autentisering bekrefter identiteten til brukere eller applikasjoner som kobler seg til en MCP-server. Autorisasjon fastsetter hvilke verktøy og ressurser de har tilgang til.

Dårlig konfigurerte MCP-servere kan godta forespørsler eller tokener uten å autentisere brukere korrekt eller håndheve tilgangsbegrensninger. I tillegg kan stjålet påloggingsinformasjon gi ondsinnede aktører tilgang hvis valideringen er svak.

Slik beskytter du deg mot svak autentisering og autorisasjon

OAuth-basert autentisering for eksterne MCP-servere, kortlevde tokener og rollebasert tilgangskontroll (RBAS) er alle tiltak som bidrar til å motvirke svak autorisasjon. Rollebasert tilgang er nyttig fordi det hindrer brukere i å få tilgang til data og verktøy utover tillatelsene sine, selv om serveren selv har tilgang.

Trussel nr. 5: Lekkasje og misbruk av påloggingsinformasjon

MCP-servere bruker rutinemessig påloggingsinformasjon som API-nøkler og OAuth-tilgangstokener for å koble til eksterne tjenester. Hvis disse eksponeres eller misbrukes, kan angripere få tilgang til sensitive data og funksjonalitet.

Ett eksempel er token-videresending (token passthrough), der en MCP-server videresender et tilgangstoken til en annen tjeneste uten å bekrefte at det faktisk er ment for mottakertjenesten. Dette kan i sin tur føre til lekkasje hvis mottakertjenesten har utilstrekkelig beskyttelse.

Slik beskytter du deg mot lekkasje og misbruk av påloggingsinformasjon

Kortlevde tokener med snevert omfang og rotasjon av påloggingsinformasjon er effektive for å begrense i hvilken grad lekkede data kan brukes av ondsinnede aktører. API-nøkler og påloggingsinformasjon bør alltid lagres sikkert ved hjelp av en hemmelighetsbehandler.

Trussel nr. 6: Confused deputy-angrep

Et confused deputy-angrep skjer når en angriper lurer en pålitelig applikasjon til å bruke sine tillatelser til å utføre en handling som ikke er autorisert av en legitim bruker. I dette tilfellet er det MCP-serveren som er stedfortrederen («the deputy»).

Forstørr

Angriperen utnytter en sårbarhet i MCP-serveren (for eksempel svak OAuth-verifisering) til å utføre en ondsinnet prosess, som et verktøykall eller datahenting.

Slik beskytter du deg mot confused deputy-angrep

Autorisasjonsvalidering, der hvert verktøykall verifiseres som tilhørende en bestemt bruker, bidrar til å begrense confused deputy-angrep. I tillegg bør sensitive handlinger, som dataeksport, kreve eksplisitt autorisasjon.

Trussel nr. 7: Ondsinnede servere og kompromitterte avhengigheter

MCP-servere kan inneholde ondsinnet kode (de er i bunn og grunn eksterne programmer) eller bygge på kompromitterte avhengigheter, som tredjepartsbiblioteker. Dette er et problem i programvareforsyningskjeden snarere enn et problem som er unikt for MCP.

En enkel måte dette kan skje på, er at en angriper distribuerer en integrasjon som ser legitim ut. Når den er satt opp, kan den stjele og gjenbruke påloggingsinformasjon, få tilgang til sensitive data og utføre uautoriserte operasjoner.

Slik beskytter du deg mot ondsinnede servere og kompromitterte avhengigheter

Installer bare MCP-servere fra pålitelige og kontrollerte kilder. Gå gjennom koden deres hvis mulig, og sjekk alltid eventuelle eksterne avhengigheter. Sørg for at serverne oppdateres og patches jevnlig.

Trussel nr. 8: Forfalskning av forespørsler på serversiden (SSRF)

Forfalskning av forespørsler på serversiden (SSRF) er når en angriper lurer en MCP-server til å sende nettverksforespørsler til interne adresser som brukeren ikke hadde til hensikt å få tilgang til.

Dette kan skje når en MCP-server eksponerer et verktøy som henter informasjon fra en URL. Hvis en angriper kan påvirke URL-parameteren, kan vedkommende endre den til en ønsket nettverksadresse, for eksempel et internt API eller en skytjeneste. Dette kan føre til at sensitive data hentes og potensielt gjøres tilgjengelige

Slik beskytter du deg mot forfalskning av forespørsler på serversiden (SSRF)

MCP-servere bør alltid validere URL-er, blokkere tilgang til begrensede interne nettverksadresser og hindre utgående nettverkstilgang. Omdirigeringer bør også følge denne protokollen.

Trussel nr. 9: Øktkapring

Øktkapring innebærer at en angriper tar kontroll over en aktiv tilkobling mellom en MCP-klient og en server.

Angriperen kan for eksempel stjele en øktidentifikator fra en dårlig sikret MCP-applikasjon (f.eks. en vert eller en server). Hvis MCP-serveren godtar denne identifikatoren, kan angriperen potensielt kalle opp verktøy med brukerens legitime tillatelser.

Slik beskytter du deg mot

Risikoen for øktkapring kan reduseres med streng identitetsverifisering på tvers av alle applikasjoner i et MCP-system. Kryptering mellom MCP-klienter og eksterne servere er også avgjørende for å hindre at øktidentifikatorer fanges opp.

Trussel nr. 10: Mix-up-angrep

I et mix-up-angrep lurer angriperen en MCP-klient til å sende en autorisasjonskode til en ondsinnet autorisasjonsserver som sitter mellom klienten og MCP-serveren. En autorisasjonsserver er en applikasjon som utsteder OAuth-tilgangstokener etter å ha kontrollert at den forespurte tilgangen er autorisert.

Forstørr

Hvis en MCP-vert kobler til flere tjenester som hver bruker en egen autorisasjonsserver, kan en angriper potensielt kontrollere én av dem (kanskje ved å registrere en ondsinnet tjeneste) og få klienten til å sende en autorisasjonskode utstedt av en legitim server til den ondsinnede serveren. Denne forvekslingen kan gjøre det mulig for angriperen å utgi seg for å være den autoriserte applikasjonen og få tilgang til beskyttede tjenester.

Slik beskytter du deg mot mix-up-angrep

MCP-klienter bør verifisere identiteten til autorisasjonsserveren gjennom hele OAuth-prosessen. Nærmere bestemt bør de sjekke serverens utstederidentifikator (iss) mot den forventede identiteten og avvise avvik.

Trussel nr. 11: Kompromittering av lokale MCP-servere

Mange MCP-servere kjører på brukerens lokale maskin. Brukeren kan ha installert serveren fra en tredjepart eller bygget den selv. Hvis en angriper kan kompromittere denne lokale MCP-serveren, kan vedkommende potensielt få tilgang til store deler av det lokale systemet.

Det finnes ulike måter en angriper kan få tilgang på. Angriperen kan distribuere en ondsinnet server forkledd som en legitim integrasjon, endre konfigurasjonen til en MCP-vert slik at den utsteder en ondsinnet kommando, eller få tilgang til en MCP-server som kjører i et miljø med utilstrekkelige sikkerhetskontroller, for eksempel via DNS-rebinding, som lurer en nettleser til å sende forespørsler til en localhost-tjeneste.

Slik beskytter du deg mot kompromittering av lokale MCP-servere

Isolering i sandbox og strenge samtykkeprotokoller er viktig når du bruker lokale MCP-servere. MCP-servere bør bare installeres fra pålitelige leverandører, og tillatelser i operativsystemet bør begrense hvilke kataloger de har tilgang til.

MCP-sårbarheter er ofte gamle trusler i ny drakt

MCP-sårbarheter oppstår ofte når etablerte risikoer og angrepsmetoder tas i bruk på nye måter. MCP introduserer nye måter angripere kan utnytte disse sårbarhetene på, gjennom samspillet mellom LLM-er, MCP-servere og eksterne tjenester.

Det finnes selvsagt MCP-spesifikke trusler. Det er likevel verdt å huske at standard sikkerhetsprotokoller, som å håndheve streng autorisasjon, bruke pålitelige leverandører og beskytte mot promptinjeksjoner, vil gjøre mye for å beskytte enhver MCP-implementering.