A prompt injection veszélyei a gyakorlatban: védekezés proxyval
A nemrég napvilágra került GitHub MCP (Model-driven Co-pilot) sebezhetőség élesben mutatta meg, hogyan lehet egy jól irányzott prompt injection támadással, túlzott jogosultságú tokeneket kihasználva privát repositorykból adatokat kiszivárogtatni. Ennek apropóján szeretném megosztani veletek, mi hogyan közelítjük meg az MCP-k biztonságát egy proxy réteg beiktatásával.
A probléma gyökere: a féktelen bizalom
A legfőbb gond az, hogy az MCP eszközök gyakran gyakorlatilag teljes hozzáférést biztosító tokenekkel futnak (gondolj csak a mindenre kiterjedő GitHub PAT-okra vagy az AdminAccess jogosultságú AWS kulcsokra), mindenféle futásidejű korlátozás nélkül. Ez a felállás kísértetiesen emlékeztet a homokozó (sandbox) előtti idők JavaScriptjére, ami simán hozzáférhetett a teljes fájlrendszerhez. Elég egyetlen rosszindulatú prompt vagy egy feltört szerver, és a támadó mindenhez hozzáférhet.
Miért nem működik a jelenlegi hitelesítési modell?
A helyzet elég lehangoló. Tegyük fel, hogy el akarsz olvasni egyetlen GitHub issue-t. Ehhez a tokenednek az ÖSSZES repositoryhoz teljes körű hozzáférést kell adnia. Ezt a problémát az OAuth 2.1 RAR (Rich Authorization Requests) orvosolhatná, de a használata gyakorlatilag a nullával egyenlő. Az API szolgáltatóknak egyszerűen nincs gazdasági érdekük abban, hogy részletes, időben korlátozott jogosultsági szinteket (granular, temporal scoping) vezessenek be.
Az MCP Snitch: A mi megoldásunk a hiányzó láncszemre
Az MCP Snitch egy nyílt forráskódú biztonsági proxy, amit pontosan azért hoztunk létre, hogy pótolja azt a hiányzó közvetítő réteget, ami az MCP eszközökből hiányzik. A legfontosabb funkciói a következők:
- Whitelist-alapú hozzáférés-szabályozás: Alapértelmezetten mindent tilt, és csak a konkrétan, előre engedélyezett műveleteket engedi át.
- Futásidejű jogosultságkérések: A kérések megjelennek a felhasználói felületen is, így mindig láthatod, mihez kér éppen hozzáférést az eszköz.
- API kulcsok észlelése és blokkolása: Megakadályozza, hogy érzékeny kulcsok szivárogjanak ki a promptokon keresztül.
- Részletes naplózás: Minden egyes műveletet naplóz, így utólag is pontosan visszakövethető, mi történt.
Amit viszont nem old meg
Fontos tisztában lenni a korlátokkal is. Az MCP Snitch sem csodaszer, és nem véd meg minden ellen. Ilyenek például:
- Ellátási lánc elleni támadások (pl. egy kompromittált npm vagy pip csomag).
- Perzisztencia kiépítésére szolgáló technikák (pl. SSH kulcsok, cron jobok elhelyezése a rendszeren).
- Sávon kívüli (out-of-band) műveletek, például ha az MCP szerver közvetlenül indít hálózati kéréseket.
Konklúzió: Gyorsítósávon a biztonság felé
Gondolj csak bele: a böngészők biztonsági modelljének 25 év kellett ahhoz, hogy eljusson a „JavaScript letörölheti a fájljaidat” szinttől a mai, granuláris engedélyekkel rendelkező, homokozóban futó folyamatokig. Az MCP-knek is végig kellene járniuk ezt az utat, de a kockázatok már most itt vannak a nyakunkon. Amíg az IDE-k nem kapnak megfelelő, beépített sandboxing megoldásokat, és az MCP protokollok nem rendelkeznek natív biztonsági alapokkal, addig egy proxy-alapú védelem a leghatékonyabb gyakorlati megoldás.
Ha érdekel a projekt, nézd meg a GitHubon!