Aizsargājiet savu MCP sistēmu: 11 izplatīti riski un kā pret tiem aizsargāties

MCP riskus kopumā var iedalīt trīs kategorijās: LLM manipulācija, datu un piekļuves drošība un infrastruktūras ievainojamības.

Tā kā MCP serveri bieži nodrošina piekļuvi plašam iekšējo sistēmu klāstam, potenciālais drošības risks ir augsts. Tomēr tā iestāšanās varbūtība lielā mērā ir atkarīga no konfigurācijas.

Privātpersonas un uzņēmumi var veikt daudzus pasākumus, lai nodrošinātu savu sistēmu aizsardzību, un protokoliem vienmēr jābūt samērīgiem ar iespējām un datiem, ko pievienotie MCP serveri varētu atklāt.

Kas ir MCP un MCP drošība?

Model Context Protocol (MCP) ir atvērts standarts, ko izveidojis Anthropic, lai savienotu uz LLM balstītas lietotnes (jeb resursdatorus) ar ārējām sistēmām.

MCP sistēmai ir trīs galvenie komponenti: resursdators, klients un serveris. Resursdators, kas bieži ir MI asistents, ar klienta starpniecību savienojas ar ārēju MCP serveri. Pēc tam tas var sūtīt pieprasījumus izpildīt ārējas funkcijas (rīkus) vai izgūt datus (resursus) vai uzvednes, ko pievienot LLM konteksta logam.

Izvērst

MCP drošība ir protokoli, kas aizsargā savienojumus un komponentus MCP sistēmā. Ir vairāki būtiski izaicinājumi, kas raksturīgi tieši MCP, tostarp tas, ka MI lietotnēm bieži ir aģentiskas spējas un ziņojumos var būt iegultas ļaunprātīgas instrukcijas.

Problēmas rada arī jau zināmas nepilnības, kas nav raksturīgas tikai MCP, piemēram, uzvednes injekcija, vāja autentifikācija un nedrošas trešo pušu integrācijas. Tāpat kā jebkura datorsistēma, MCP aizsardzībai paļaujas uz procesuālu protokolu, piemēram, tikai uzticamu serveru izmantošanas, un tehnisku kontroles līdzekļu, piemēram, API vārteju, kombināciju.

Cik nopietni ir MCP draudi?

MCP ātri kļuvis par populāru LLM tehnoloģiju, un to izmanto daudzas organizācijas un patērētājiem paredzētas lietotnes. Tā kā MCP serveri ir kodā rakstītas programmas, tiem, tāpat kā jebkurai citai lietotnei, ir ievainojamības.

Tomēr, ja organizācijas izmanto MCP kontrolētās izvietošanās, tas parasti ir drošs. Pastāv būtiska atšķirība starp sistēmas izveidi ar uzticamiem serveriem un pārbaudītām atļaujām un autonoma aģenta pievienošanu duci nepārbaudītu serveru.

1. drauds: netiešā uzvednes injekcija

Uzbrucējs var ievietot uz LLM vērstas instrukcijas dokumentā, tīmekļa lapā vai rīka izvadē, ko atgriež MCP serveris. Ja resursdators pievieno šo materiālu konteksta logam, pastāv iespēja, ka LLM to kļūdaini uztvers kā īstas instrukcijas.

Turklāt no pirmā acu uzmetiena šīs instrukcijas var šķist atbilstošas. Piemēram, izgūts atbalsta pieteikums var likt LLM pirms atbildes ģenerēšanas eksportēt sensitīvus klientu ierakstus.

Kā aizsargāties pret netiešo uzvednes injekciju

Uzvednes injekcijas parasti jārisina resursdatora līmenī. Ārējais saturs jāatzīmē kā neuzticams, un sensitīvas informācijas pieprasījumiem jāprasa informēts apstiprinājums no procesā iesaistīta cilvēka. Noderīga var būt arī drošības testēšana, kurā tiek izsaukti ļaunprātīgi dokumenti vai dati, lai redzētu, kā reaģē resursdators un LLM.

2. drauds: rīku saindēšana un „rug pull” uzbrukumi

Rīku saindēšanas uzbrukumā MCP rīka aprakstam vai shēmai tiek pievienots ļaunprātīgs kods. Tas var ietekmēt LLM atklāšanas fāzē, kad MCP pirmo reizi parāda pieejamos rīkus.

Izvērst

„Rug pull” ir īpašs rīku saindēšanas veids, kurā tiek mainīti apstiprinātie metadati. Šis rīku saindēšanas veids var mainīt to, kā modelis izmanto uzticamus rīkus, nevis tieši izsaukt ļaunprātīgu rīku.

Kā aizsargāties pret rīku saindēšanu un „rug pull” uzbrukumiem

Pirms katra rīka izmantošanas resursdatoram jāpārbauda tā pilnā definīcija un jāsalīdzina tā ar apstiprināto uzticamo rīku sarakstu, tādējādi konstatējot jebkādas izmaiņas. Parametru pārbaudes var palīdzēt identificēt potenciāli bīstamas iespējas un tās atzīmēt.

3. drauds: pārmērīgas atļaujas

Lietotāji bieži piešķir MCP serveriem un pievienotajiem LLM (ar resursdatora starpniecību) vairāk atļauju, nekā uzdevumam nepieciešams. Piemēram, rakstīšanas atļaujas, kad pietiktu ar tikai lasīšanas atļauju, vai pilnu piekļuvi iekšējai failu sistēmai (piemēram, Google Drive).

Šāda plaša atļauju pakāpeniska paplašināšanās var palielināt citu ievainojamību, piemēram, ļaunprātīgu rīku izsaukumu, iespējamās ietekmes apmēru. Bieži vien atļaujas „sakrājas”, lietotājiem uzņēmumā piešķirot privilēģijas ikdienas darbā ar MI rīkiem (privilēģiju uzkrāšanās).

Kā aizsargāties pret pārmērīgām atļaujām

Tiešākais veids, kā aizsargāties pret šo problēmu, ir ierobežot atļaujas un OAuth tvērumus (lasīšana, rakstīšana, pilna piekļuve utt.). Svarīga daļa no tā ir lietotāju apstiprinājumi, īpaši sensitīvām darbībām, taču atļaujas jākontrolē arī sistēmas līmenī (operētājsistēmā, MCP resursdatorā un serverī).

4. drauds: vāja autentifikācija un autorizācija

Autentifikācija pārbauda to lietotāju vai lietotņu identitāti, kas savienojas ar MCP serveri. Autorizācija nosaka, kuriem rīkiem un resursiem tie var piekļūt.

Nepareizi konfigurēti MCP serveri var pieņemt pieprasījumus vai marķierus, pienācīgi neautentificējot lietotājus vai neieviešot piekļuves ierobežojumus. Turklāt, ja validācija ir vāja, nozagti akreditācijas dati var ļaut ļaunprātīgām personām iegūt piekļuvi.

Kā aizsargāties pret vāju autentifikāciju un autorizāciju

Uz OAuth balstīta autentifikācija attālajiem MCP serveriem, īslaicīgi marķieri un uz lomām balstīta piekļuves kontrole (RBAS) ir pasākumi, kas palīdz mazināt vājas autorizācijas riskus. Uz lomām balstīta piekļuve ir noderīga, jo tā neļauj lietotājiem piekļūt datiem un rīkiem ārpus viņu atļaujām pat tad, ja pašam serverim šāda piekļuve ir.

5. drauds: akreditācijas datu noplūde un ļaunprātīga izmantošana

Lai savienotos ar ārējiem pakalpojumiem, MCP serveri regulāri izmanto akreditācijas datus, piemēram, API atslēgas un OAuth piekļuves marķierus. Ja tie tiek atklāti vai ļaunprātīgi izmantoti, uzbrucēji var piekļūt sensitīviem datiem un funkcijām.

Viens piemērs ir marķiera tālāknodošana (token passthrough), kad MCP serveris pārsūta piekļuves marķieri citam pakalpojumam, nepārbaudot, vai tas patiešām ir paredzēts saņēmējam pakalpojumam. Tas savukārt var izraisīt noplūdi, ja saņēmēja pakalpojuma aizsardzība ir nepietiekama.

Kā aizsargāties pret akreditācijas datu noplūdi un ļaunprātīgu izmantošanu

Īslaicīgi marķieri ar šauru tvērumu un akreditācijas datu rotācija efektīvi ierobežo, cik lielā mērā ļaunprātīgas personas var izmantot nopludinātos datus. API atslēgas un akreditācijas dati vienmēr jāglabā droši, izmantojot noslēpumu pārvaldnieku.

6. drauds: apjukušā vietnieka (confused deputy) uzbrukumi

Apjukušā vietnieka uzbrukums notiek, kad uzbrucējs piemāna uzticamu lietotni izmantot tās atļaujas, lai veiktu darbību, ko likumīgs lietotājs nav autorizējis. Šajā gadījumā vietnieks ir MCP serveris.

Izvērst

Uzbrucējs izmantos MCP servera ievainojamību (piemēram, vāju OAuth verifikāciju), lai izpildītu ļaunprātīgu procesu, piemēram, rīka izsaukumu vai datu izgūšanu.

Kā aizsargāties pret apjukušā vietnieka uzbrukumiem

Autorizācijas validācija, kurā par katru rīka izsaukumu tiek pārbaudīts, vai tas pieder konkrētam lietotājam, palīdz ierobežot apjukušā vietnieka uzbrukumus. Turklāt sensitīvām darbībām, piemēram, datu eksportēšanai, jāpieprasa skaidra autorizācija.

7. drauds: ļaunprātīgi serveri un kompromitētas atkarības

MCP serveros var būt ļaunprātīgs kods (būtībā tās ir ārējas programmas), vai tie var izmantot kompromitētas atkarības, piemēram, trešo pušu bibliotēkas. Tā ir programmatūras piegādes ķēdes problēma, nevis problēma, kas raksturīga tikai MCP.

Viens vienkāršs veids, kā tas var notikt, ir tad, ja uzbrucējs izplata integrāciju, kas šķiet likumīga. Kad tā ir iestatīta, tā var nozagt un atkārtoti izmantot akreditācijas datus, piekļūt sensitīviem datiem un izpildīt neautorizētas darbības.

Kā aizsargāties pret ļaunprātīgiem serveriem un kompromitētām atkarībām

Instalējiet MCP serverus tikai no uzticamiem un pārbaudītiem avotiem. Ja iespējams, pārskatiet to kodu un vienmēr pārbaudiet visas ārējās atkarības. Nodrošiniet, lai serveri tiktu regulāri atjaunināti un tiem tiktu uzstādīti ielāpi.

8. drauds: servera puses pieprasījumu viltošana (SSRF)

Servera puses pieprasījumu viltošana (SSRF) notiek, kad uzbrucējs piemāna MCP serveri sūtīt tīkla pieprasījumus uz iekšējām adresēm, kurām lietotājs nebija paredzējis piekļūt.

Tas var notikt, ja MCP serveris piedāvā rīku, kas izgūst informāciju no URL. Ja uzbrucējs var ietekmēt URL parametru, viņš var to nomainīt uz sev vēlamo tīkla adresi, piemēram, iekšēju API vai mākoņpakalpojumu. Tā rezultātā var tikt izgūti sensitīvi dati, kas, iespējams, kļūst pieejami

Kā aizsargāties pret servera puses pieprasījumu viltošanu (SSRF)

MCP serveriem vienmēr jāvalidē URL, jābloķē piekļuve ierobežotām iekšējā tīkla adresēm un jānovērš izejošā tīkla piekļuve. Arī novirzīšanām jāievēro šis protokols.

9. drauds: sesijas nolaupīšana

Sesijas nolaupīšana nozīmē, ka uzbrucējs pārņem kontroli pār aktīvu savienojumu starp MCP klientu un serveri.

Piemēram, uzbrucējs var nozagt sesijas identifikatoru no slikti aizsargātas MCP lietotnes (piem., resursdatora vai servera). Ja MCP serveris pieņem šo identifikatoru, uzbrucējs, iespējams, var izsaukt rīkus ar lietotāja likumīgajām atļaujām.

Kā aizsargāties pret

Sesijas nolaupīšanas risku var samazināt ar stingru identitātes verifikāciju visās MCP sistēmas lietotnēs. Lai novērstu sesiju identifikatoru atklāšanu, būtiska ir arī šifrēšana starp MCP klientiem un attālajiem serveriem.

10. drauds: sajaukšanas (mix-up) uzbrukumi

Sajaukšanas uzbrukumā uzbrucējs piemāna MCP klientu nosūtīt autorizācijas kodu ļaunprātīgam autorizācijas serverim, kas atrodas starp klientu un MCP serveri. Autorizācijas serveris ir lietotne, kas izsniedz OAuth piekļuves marķierus pēc tam, kad pārbaudīts, ka pieprasītā piekļuve ir autorizēta.

Izvērst

Ja MCP resursdators savienojas ar vairākiem pakalpojumiem, no kuriem katrs izmanto citu autorizācijas serveri, uzbrucējs, iespējams, var kontrolēt vienu no tiem (piemēram, reģistrējot ļaunprātīgu pakalpojumu) un panākt, ka klients nosūta likumīga servera izsniegtu autorizācijas kodu ļaunprātīgajam serverim. Šāda sajaukšana var ļaut uzbrucējam uzdoties par autorizēto lietotni un piekļūt aizsargātiem pakalpojumiem.

Kā aizsargāties pret sajaukšanas uzbrukumiem

MCP klientiem visā OAuth procesā jāverificē autorizācijas servera identitāte. Konkrēti, tiem jāsalīdzina servera izdevēja identifikators (iss) ar sagaidāmo identitāti un jānoraida neatbilstības.

11. drauds: lokālā MCP servera kompromitēšana

Daudzi MCP serveri darbojas lietotāja lokālajā datorā. Lietotājs var instalēt serveri no trešās puses vai izveidot to pats. Ja uzbrucējs var kompromitēt šo lokālo MCP serveri, viņš, iespējams, var iegūt piekļuvi lielai daļai lokālās sistēmas.

Uzbrucējs var iegūt piekļuvi dažādos veidos. Viņš var izplatīt ļaunprātīgu serveri, kas maskēts kā likumīga integrācija, modificēt MCP resursdatora konfigurāciju tā, lai tas izdotu ļaunprātīgu komandu, vai piekļūt MCP serverim, kas darbojas vidē ar nepietiekamām drošības kontrolēm, piemēram, izmantojot DNS atkārtotu piesaisti (DNS rebinding), kas piemāna pārlūkprogrammu sūtīt pieprasījumus uz localhost pakalpojumu.

Kā aizsargāties pret lokālā MCP servera kompromitēšanu

Izmantojot lokālos MCP serverus, svarīgi ir izmantot smilšu kasti un stingrus piekrišanas protokolus. MCP serverus drīkst instalēt tikai no uzticamiem nodrošinātājiem, un operētājsistēmas atļaujām jāierobežo, kuriem direktorijiem tie var piekļūt.

MCP ievainojamības bieži ir veci draudi jaunā ietērpā

MCP ievainojamības bieži rodas, jaunos veidos piemērojot zināmus riskus un uzbrukumu metodoloģijas. MCP paver uzbrucējiem jaunus veidus, kā izmantot šīs ievainojamības ar LLM, MCP serveru un ārējo pakalpojumu mijiedarbības starpniecību.

Protams, pastāv arī tieši MCP raksturīgi draudi. Tomēr ir vērts paturēt prātā, ka standarta drošības protokoli, piemēram, stingras autorizācijas ieviešana, uzticamu nodrošinātāju izmantošana un aizsardzība pret uzvednes injekcijām, ievērojami palīdzēs aizsargāt jebkuru MCP ieviešanu.