Sikr dit MCP-system: 11 almindelige risici, og hvordan du beskytter dig mod dem

MCP-risici falder overordnet i tre kategorier: LLM-manipulation, data- og adgangssikkerhed samt sårbarheder i infrastrukturen.

Fordi MCP-servere ofte giver adgang til en lang række interne systemer, er den potentielle sikkerhedsrisiko høj. Sandsynligheden afhænger dog i høj grad af opsætningen.

Der er mange skridt, som enkeltpersoner og virksomheder kan tage for at sikre, at deres systemer er beskyttet, og protokollerne bør altid stå i forhold til de funktioner og data, som tilsluttede MCP-servere kan eksponere.

Hvad er MCP og MCP-sikkerhed?

Model Context Protocol (MCP) er en åben standard, skabt af Anthropic, til at forbinde LLM-baserede apps (eller hosts) med eksterne systemer.

Der er tre kernekomponenter i et MCP-system: hosten, klienten og serveren. Hosten, som ofte er en AI-assistent, forbinder til en ekstern MCP-server via en klient. Den kan derefter sende anmodninger om at køre ekstern funktionalitet (værktøjer) eller hente data (ressourcer) eller prompts, der skal tilføjes til LLM’ens kontekstvindue.

Udvid

MCP-sikkerhed henviser til de protokoller, der beskytter forbindelserne og komponenterne i et MCP-system. Der er flere centrale udfordringer, som er unikke for MCP, herunder det faktum, at AI-apps ofte har agentiske egenskaber, og at ondsindede instruktioner kan være indlejret i beskeder.

Kendte problemer, der ikke er specifikke for MCP’er, såsom prompt injection, svag autentificering og usikre tredjepartsintegrationer, giver også problemer. Som med ethvert computersystem er MCP afhængig af en blanding af proceduremæssige protokoller, f.eks. kun at bruge betroede servere, og tekniske kontroller, f.eks. API-gateways, til beskyttelse.

Hvor alvorlige er MCP-trusler?

MCP er hurtigt blevet en populær LLM-teknologi, og mange organisationer og forbrugerrettede apps bruger den. Fordi MCP-servere er programmer skrevet i kode, har de sårbarheder ligesom alle andre applikationer.

Når organisationer bruger MCP i kontrollerede udrulninger, er det dog generelt sikkert. Der er en markant forskel på at bygge et system med betroede servere og verificerede tilladelser og at koble en autonom agent til et dusin ukontrollerede servere.

Trussel nr. 1: Indirekte prompt injection

En angriber kan placere instruktioner rettet mod LLM’en i et dokument, en webside eller et værktøjsoutput, som en MCP-server returnerer. Hvis hosten tilføjer dette materiale til kontekstvinduet, er der en risiko for, at LLM’en forveksler det med ægte instruktioner.

Desuden kan disse instruktioner virke passende på overfladen. For eksempel kan en hentet supportsag bede LLM’en om at eksportere følsomme kundeoplysninger, før den genererer et svar.

Sådan beskytter du dig mod indirekte prompt injection

Prompt injections bør typisk håndteres på host-niveau. Eksternt indhold bør mærkes som ikke-betroet, og anmodninger om følsomme oplysninger bør kræve informeret godkendelse fra et menneske i loopet. Sikkerhedstest, hvor man kalder ondsindede dokumenter eller data for at se, hvordan hosten og LLM’en reagerer, kan også være nyttige.

Trussel nr. 2: Værktøjsforgiftning og rug pulls

Ved et angreb med værktøjsforgiftning tilføjes ondsindet kode til et MCP-værktøjs beskrivelse eller skema. Det kan potentielt påvirke LLM’en i opdagelsesfasen, når MCP første gang eksponerer tilgængelige værktøjer.

Udvid

Et rug pull er en særlig type værktøjsforgiftning, hvor godkendte metadata ændres. Denne form for værktøjsforgiftning kan ændre den måde, en model bruger betroede værktøjer på, i stedet for at kalde et ondsindet værktøj direkte.

Sådan beskytter du dig mod værktøjsforgiftning og rug pulls

Hosten bør inspicere den fulde definition af hvert værktøj, før det bruges, og sammenligne den med en liste over godkendte, betroede værktøjer for derved at opdage eventuelle ændringer. Parametertjek kan hjælpe med at identificere potentielt farlige funktioner og markere dem.

Trussel nr. 3: Overdrevne tilladelser

Det er almindeligt, at brugere giver MCP-servere og tilsluttede LLM’er (via hosten) flere tilladelser, end en opgave kræver. For eksempel skrivetilladelser, når skrivebeskyttet adgang ville være tilstrækkeligt, eller fuld adgang til et internt filsystem (såsom Google Drive).

Denne omfattende udvidelse af tilladelser kan øge skadesomfanget af andre sårbarheder såsom ondsindede værktøjskald. Det er almindeligt, at tilladelser ”hober sig op”, efterhånden som brugere tildeler rettigheder i løbet af deres daglige arbejde med AI-værktøjer i en virksomhed (akkumulering af rettigheder).

Sådan beskytter du dig mod overdrevne tilladelser

Den mest direkte måde at beskytte sig mod dette problem på er at begrænse tilladelser og OAuth-scopes (læse, skrive, fuld adgang osv.). Brugergodkendelser, især ved følsomme handlinger, er en vigtig del af dette, men tilladelser bør også styres på systemniveau (operativsystem, MCP-host og server).

Trussel nr. 4: Svag autentificering og autorisation

Autentificering verificerer identiteten af brugere eller applikationer, der forbinder til en MCP-server. Autorisation fastlægger, hvilke værktøjer og ressourcer de har adgang til.

Dårligt konfigurerede MCP-servere kan acceptere anmodninger eller tokens uden at autentificere brugere korrekt eller håndhæve adgangsbegrænsninger. Derudover kan stjålne legitimationsoplysninger give ondsindede aktører adgang, hvis valideringen er svag.

Sådan beskytter du dig mod svag autentificering og autorisation

OAuth-baseret autentificering for MCP-fjernservere, kortlivede tokens og rollebaseret adgangskontrol (RBAS) er alle tiltag, der hjælper med at afbøde svag autorisation. Rollebaseret adgang er nyttig, fordi den forhindrer brugere i at få adgang til data og værktøjer ud over deres tilladelser, selv hvis serveren selv har adgang.

Trussel nr. 5: Læk og misbrug af legitimationsoplysninger

MCP-servere bruger rutinemæssigt legitimationsoplysninger som API-nøgler og OAuth-adgangstokens til at forbinde til eksterne tjenester. Hvis disse eksponeres eller misbruges, kan angribere få adgang til følsomme data og funktioner.

Et eksempel er token passthrough, hvor en MCP-server videresender et adgangstoken til en anden tjeneste uden at verificere, at det faktisk er beregnet til den modtagende tjeneste. Det kan igen føre til læk, hvis den modtagende tjeneste har utilstrækkelig beskyttelse.

Sådan beskytter du dig mod læk og misbrug af legitimationsoplysninger

Kortlivede tokens med snævert omfang og rotation af legitimationsoplysninger er effektive til at begrænse, i hvilket omfang lækkede data kan bruges af ondsindede aktører. API-nøgler og legitimationsoplysninger bør altid opbevares sikkert ved hjælp af en secret manager.

Trussel nr. 6: Confused deputy-angreb

Et confused deputy-angreb opstår, når en angriber narrer en betroet applikation til at bruge sine tilladelser til at udføre en handling, som ikke er autoriseret af en legitim bruger. I dette tilfælde er det MCP-serveren, der er stedfortræderen (”deputy”).

Udvid

Angriberen udnytter en sårbarhed i MCP-serveren (såsom svag OAuth-verifikation) til at udføre en ondsindet proces, såsom et værktøjskald eller datahentning.

Sådan beskytter du dig mod confused deputy-angreb

Autorisationsvalidering, hvor hvert værktøjskald verificeres som tilhørende en bestemt bruger, hjælper med at begrænse confused deputy-angreb. Derudover bør følsomme handlinger, såsom dataeksport, kræve eksplicit autorisation.

Trussel nr. 7: Ondsindede servere og kompromitterede afhængigheder

MCP-servere kan indeholde ondsindet kode (de er i bund og grund eksterne programmer) eller bygge på kompromitterede afhængigheder, såsom tredjepartsbiblioteker. Det er et problem i softwareforsyningskæden snarere end et problem, der er unikt for MCP.

En enkel måde, dette kan ske på, er, hvis en angriber distribuerer en integration, der ser legitim ud. Når den er sat op, kan den stjæle og genbruge legitimationsoplysninger, få adgang til følsomme data og udføre uautoriserede handlinger.

Sådan beskytter du dig mod ondsindede servere og kompromitterede afhængigheder

Installer kun MCP-servere fra betroede og kontrollerede kilder. Gennemgå om muligt deres kode, og tjek altid eventuelle eksterne afhængigheder. Sørg for, at serverne regelmæssigt opdateres og patches.

Trussel nr. 8: Server-side request forgery (SSRF)

Server-side request forgery (SSRF) er, når en angriber narrer en MCP-server til at sende netværksanmodninger til interne adresser, som brugeren ikke havde til hensigt at tilgå.

Det kan ske, når en MCP-server eksponerer et værktøj, der henter oplysninger fra en URL. Hvis en angriber kan påvirke URL-parameteren, kan vedkommende ændre den til den ønskede netværksadresse, såsom en intern API eller en cloudtjeneste. Det kan føre til, at følsomme data hentes og potentielt gøres tilgængelige

Sådan beskytter du dig mod server-side request forgery (SSRF)

MCP-servere bør altid validere URL’er, blokere adgang til begrænsede interne netværksadresser og forhindre udgående netværksadgang. Omdirigeringer bør også følge denne protokol.

Trussel nr. 9: Sessionskapring

Sessionskapring indebærer, at en angriber overtager kontrollen med en aktiv forbindelse mellem en MCP-klient og en server.

For eksempel kan angriberen stjæle et sessions-id fra en dårligt sikret MCP-applikation (f.eks. en host eller en server). Hvis MCP-serveren accepterer dette id, kan angriberen potentielt kalde værktøjer med brugerens legitime tilladelser.

Sådan beskytter du dig mod

Risikoen for sessionskapring kan reduceres med streng identitetsverifikation på tværs af alle applikationer i et MCP-system. Kryptering mellem MCP-klienter og fjernservere er også afgørende for at forhindre, at sessions-id’er bliver identificeret.

Trussel nr. 10: Mix-up-angreb

Ved et mix-up-angreb narrer angriberen en MCP-klient til at sende en autorisationskode til en ondsindet autorisationsserver, der sidder mellem klienten og MCP-serveren. En autorisationsserver er en applikation, der udsteder OAuth-adgangstokens efter at have kontrolleret, at den anmodede adgang er autoriseret.

Udvid

Hvis en MCP-host forbinder til flere tjenester, der hver bruger en forskellig autorisationsserver, kan en angriber potentielt kontrollere én af dem (måske ved at registrere en ondsindet tjeneste) og få klienten til at sende en autorisationskode, der er udstedt af en legitim server, til den ondsindede server. Denne forveksling kan give angriberen mulighed for at udgive sig for at være den autoriserede applikation og få adgang til beskyttede tjenester.

Sådan beskytter du dig mod mix-up-angreb

MCP-klienter bør verificere autorisationsserverens identitet under hele OAuth-processen. Konkret bør de kontrollere serverens udsteder-id (iss) mod den forventede identitet og afvise uoverensstemmelser.

Trussel nr. 11: Kompromittering af lokale MCP-servere

Mange MCP-servere kører på brugerens lokale maskine. Brugeren kan have installeret serveren fra en tredjepart eller bygget den selv. Hvis en angriber kan kompromittere denne lokale MCP-server, kan vedkommende potentielt få adgang til store dele af det lokale system.

Der er forskellige måder, en angriber kan få adgang på. Angriberen kan distribuere en ondsindet server forklædt som en legitim integration, ændre en MCP-hosts konfiguration, så den udsteder en ondsindet kommando, eller få adgang til en MCP-server, der kører i et miljø med utilstrækkelige sikkerhedskontroller, f.eks. via DNS rebinding, som narrer en browser til at sende anmodninger til en localhost-tjeneste.

Sådan beskytter du dig mod kompromittering af lokale MCP-servere

Sandboxing og strenge samtykkeprotokoller er vigtige, når man bruger lokale MCP-servere. MCP-servere bør kun installeres fra betroede udbydere, og operativsystemets tilladelser bør begrænse, hvilke mapper de har adgang til.

MCP-sårbarheder er ofte gamle trusler i ny forklædning

MCP-sårbarheder opstår ofte, når kendte risici og angrebsmetoder anvendes på nye måder. MCP giver angribere nye måder at udnytte disse sårbarheder på gennem samspillet mellem LLM’er, MCP-servere og eksterne tjenester.

Der findes selvfølgelig MCP-specifikke trusler. Det er dog værd at huske på, at standardsikkerhedsprotokoller, såsom at håndhæve streng autorisation, bruge betroede udbydere og beskytte mod prompt injections, vil gøre meget for at beskytte enhver MCP-implementering.