Proteggi il tuo sistema MCP: 11 rischi comuni e come difenderti

I rischi dell'MCP rientrano in linea generale in tre categorie: manipolazione degli LLM, sicurezza dei dati e degli accessi e vulnerabilità dell'infrastruttura.

Poiché i server MCP spesso forniscono accesso a un'ampia gamma di sistemi interni, il potenziale rischio per la sicurezza è elevato. Tuttavia, la probabilità dipende molto dalla configurazione.

Privati e aziende possono adottare molte misure per garantire la protezione dei propri sistemi, e i protocolli dovrebbero sempre essere proporzionati alle funzionalità e ai dati che i server MCP connessi potrebbero esporre.

Che cos'è l'MCP e cos'è la sicurezza MCP?

Il Model Context Protocol (MCP) è uno standard aperto creato da Anthropic per connettere app basate su LLM (o host) a sistemi esterni.

Un sistema MCP è composto da tre componenti principali: l'host, il client e il server. L'host, che spesso è un assistente IA, si connette a un server MCP esterno tramite un client. Può quindi inviare richieste per eseguire funzionalità esterne (strumenti) o per recuperare dati (risorse) o prompt da aggiungere alla finestra di contesto dell'LLM.

Espandi

La sicurezza MCP comprende i protocolli che proteggono le connessioni e i componenti di un sistema MCP. Esistono diverse sfide chiave specifiche dell'MCP, tra cui il fatto che le app di IA hanno spesso capacità agentiche e che nei messaggi possono essere incorporate istruzioni dannose.

Anche problemi noti non specifici degli MCP, come la prompt injection, l'autenticazione debole e le integrazioni di terze parti non sicure, rappresentano un rischio. Come per qualsiasi sistema informatico, la protezione dell'MCP si basa su una combinazione di protocolli procedurali, come l'uso esclusivo di server attendibili, e di controlli tecnici, come i gateway API.

Quanto sono gravi le minacce MCP?

L'MCP è diventato rapidamente una tecnologia LLM molto diffusa, utilizzata da molte organizzazioni e app rivolte ai consumatori. Poiché i server MCP sono programmi scritti in codice, presentano vulnerabilità come qualsiasi altra applicazione.

Tuttavia, quando le organizzazioni utilizzano l'MCP in implementazioni controllate, è generalmente sicuro. C'è un'enorme differenza tra costruire un sistema con server attendibili e autorizzazioni verificate e collegare un agente autonomo a una dozzina di server non verificati.

Minaccia n. 1: prompt injection indiretta

Un aggressore può inserire istruzioni destinate all'LLM all'interno di un documento, di una pagina web o dell'output di uno strumento restituito da un server MCP. Se l'host aggiunge questo materiale alla finestra di contesto, è possibile che l'LLM lo scambi per istruzioni autentiche.

Inoltre, in apparenza queste istruzioni potrebbero sembrare appropriate. Ad esempio, un ticket di assistenza recuperato potrebbe indicare all'LLM di esportare dati sensibili dei clienti prima di generare una risposta.

Come proteggersi dalla prompt injection indiretta

In genere, le prompt injection dovrebbero essere gestite a livello di host. I contenuti esterni dovrebbero essere etichettati come non attendibili e le richieste di informazioni sensibili dovrebbero richiedere l'approvazione consapevole di una persona coinvolta nel processo (human in the loop). Possono essere utili anche test di sicurezza che prevedono l'invocazione di documenti o dati dannosi per osservare come rispondono l'host e l'LLM.

Minaccia n. 2: tool poisoning e rug pull

In un attacco di tool poisoning, viene aggiunto codice dannoso alla descrizione o allo schema di uno strumento MCP. Ciò può influenzare l'LLM nella fase di individuazione, quando l'MCP espone per la prima volta gli strumenti disponibili.

Espandi

Un rug pull è un tipo particolare di tool poisoning in cui vengono modificati metadati già approvati. Questa forma di tool poisoning potrebbe cambiare il modo in cui un modello utilizza strumenti attendibili, anziché invocare direttamente uno strumento dannoso.

Come proteggersi dal tool poisoning e dai rug pull

Prima di utilizzare ogni strumento, l'host dovrebbe esaminarne la definizione completa e confrontarla con un elenco di strumenti attendibili approvati, così da rilevare eventuali modifiche. I controlli sui parametri possono aiutare a individuare funzionalità potenzialmente pericolose e a segnalarle.

Minaccia n. 3: autorizzazioni eccessive

Capita spesso che gli utenti concedano ai server MCP e agli LLM connessi (tramite l'host) più autorizzazioni del necessario per un'attività. Ad esempio, autorizzazioni di scrittura quando basterebbe l'accesso in sola lettura, oppure l'accesso completo a un sistema di file interno (come Google Drive).

Questa estesa proliferazione delle autorizzazioni può ampliare il raggio d’impatto di altre vulnerabilità, come le chiamate dannose agli strumenti. È comune che le autorizzazioni “si sommino” man mano che gli utenti concedono privilegi nel corso del loro lavoro quotidiano con gli strumenti di IA in un contesto aziendale (accumulo di privilegi).

Come proteggersi dalle autorizzazioni eccessive

Il modo più diretto per proteggersi da questo problema è limitare le autorizzazioni e gli ambiti OAuth (lettura, scrittura, accesso completo e così via). Le approvazioni degli utenti, soprattutto per le operazioni sensibili, ne sono una parte importante, ma le autorizzazioni dovrebbero essere controllate anche a livello di sistema (sistema operativo, host MCP e server).

Minaccia n. 4: autenticazione e autorizzazione deboli

L'autenticazione verifica l'identità degli utenti o delle applicazioni che si connettono a un server MCP. L'autorizzazione stabilisce a quali strumenti e risorse possono accedere.

I server MCP configurati in modo inadeguato potrebbero accettare richieste o token senza autenticare correttamente gli utenti o applicare le restrizioni di accesso. Inoltre, se la convalida è debole, le credenziali rubate possono consentire a malintenzionati di ottenere l'accesso.

Come proteggersi da autenticazione e autorizzazione deboli

L'autenticazione basata su OAuth per i server MCP remoti, i token di breve durata e il controllo degli accessi basato sui ruoli (RBAS) sono tutte misure che aiutano a mitigare i rischi di un'autorizzazione debole. L'accesso basato sui ruoli è utile perché impedisce agli utenti di accedere a dati e strumenti al di là delle proprie autorizzazioni, anche se il server stesso vi ha accesso.

Minaccia n. 5: fuga e uso improprio delle credenziali

I server MCP utilizzano abitualmente credenziali come chiavi API e token di accesso OAuth per connettersi a servizi esterni. Se queste vengono esposte o usate in modo improprio, gli aggressori possono ottenere l'accesso a dati e funzionalità sensibili.

Un esempio è il token passthrough, in cui un server MCP inoltra un token di accesso a un altro servizio senza verificare che sia effettivamente destinato al servizio ricevente. Ciò, a sua volta, può causare fughe di dati se il servizio ricevente dispone di protezioni inadeguate.

Come proteggersi dalla fuga e dall'uso improprio delle credenziali

I token di breve durata con ambito ristretto e la rotazione delle credenziali sono efficaci per limitare la misura in cui i dati trapelati possono essere sfruttati da malintenzionati. Le chiavi API e le credenziali dovrebbero essere sempre archiviate in modo sicuro con un gestore di segreti.

Minaccia n. 6: attacchi confused deputy

Un attacco confused deputy ("delegato confuso") si verifica quando un aggressore induce un'applicazione attendibile a usare le proprie autorizzazioni per eseguire un'azione non autorizzata da un utente legittimo. In questo caso, il delegato è il server MCP.

Espandi

L'aggressore sfrutta una vulnerabilità del server MCP (ad esempio verifiche OAuth deboli) per eseguire un processo dannoso, come una chiamata a uno strumento o il recupero di dati.

Come proteggersi dagli attacchi confused deputy

La convalida delle autorizzazioni, in cui si verifica che ogni chiamata a uno strumento appartenga a un utente specifico, aiuta a limitare gli attacchi confused deputy. Inoltre, le azioni sensibili, come le esportazioni di dati, dovrebbero richiedere un'autorizzazione esplicita.

Minaccia n. 7: server dannosi e dipendenze compromesse

I server MCP possono contenere codice dannoso (sono essenzialmente programmi esterni) o basarsi su dipendenze compromesse, come librerie di terze parti. Si tratta di un problema della catena di fornitura del software, più che di un problema specifico dell'MCP.

Un modo semplice in cui ciò può accadere è quando un aggressore distribuisce un'integrazione che sembra legittima. Una volta configurata, può rubare e riutilizzare credenziali, accedere a dati sensibili ed eseguire operazioni non autorizzate.

Come proteggersi da server dannosi e dipendenze compromesse

Installa server MCP solo da fonti attendibili e verificate. Se possibile, esaminane il codice e controlla sempre eventuali dipendenze esterne. Assicurati che i server vengano aggiornati regolarmente e ricevano le patch.

Minaccia n. 8: server-side request forgery (SSRF)

Si parla di server-side request forgery (SSRF) quando un aggressore induce un server MCP a inviare richieste di rete verso indirizzi interni a cui l'utente non intendeva accedere.

Ciò può accadere quando un server MCP espone uno strumento che recupera informazioni da un URL. Se un aggressore riesce a influenzare il parametro URL, può modificarlo con l'indirizzo di rete desiderato, ad esempio un'API interna o un servizio cloud. Ciò può portare al recupero di dati sensibili e, potenzialmente, a renderli accessibili

Come proteggersi dalla server-side request forgery (SSRF)

I server MCP dovrebbero sempre convalidare gli URL, bloccare l'accesso agli indirizzi di rete interni riservati e impedire l'accesso di rete in uscita. Anche i reindirizzamenti dovrebbero seguire questo protocollo.

Minaccia n. 9: dirottamento di sessione

Il dirottamento di sessione si verifica quando un aggressore assume il controllo di una connessione attiva tra un client MCP e un server.

Ad esempio, potrebbe rubare un identificatore di sessione da un'applicazione MCP poco protetta (ad es. un host o un server). Se il server MCP accetta questo identificatore, l'aggressore può potenzialmente chiamare strumenti con le autorizzazioni legittime dell'utente.

Come proteggersi

Il rischio di dirottamento di sessione può essere ridotto con una verifica rigorosa dell'identità in tutte le applicazioni di un sistema MCP. Anche la crittografia tra i client MCP e i server remoti è essenziale per impedire che gli identificatori di sessione vengano individuati.

Minaccia n. 10: attacchi mix-up

In un attacco mix-up, l'aggressore induce un client MCP a inviare un codice di autorizzazione a un server di autorizzazione dannoso che si interpone tra il client e il server MCP. Un server di autorizzazione è un'applicazione che emette token di accesso OAuth dopo aver verificato che l'accesso richiesto sia autorizzato.

Espandi

Se un host MCP si connette a più servizi, ognuno dei quali utilizza un server di autorizzazione diverso, un aggressore può potenzialmente controllarne uno (ad esempio registrando un servizio dannoso) e indurre il client a inviare al server dannoso un codice di autorizzazione emesso da un server legittimo. Questa confusione può consentire all’aggressore di impersonare l’applicazione autorizzata e ottenere l’accesso a servizi protetti.

Come proteggersi dagli attacchi mix-up

I client MCP dovrebbero verificare l'identità del server di autorizzazione durante l'intero processo OAuth. In particolare, dovrebbero confrontare l'identificatore dell'emittente del server (iss) con l'identità prevista e rifiutare le mancate corrispondenze.

Minaccia n. 11: compromissione del server MCP locale

Molti server MCP vengono eseguiti sul computer locale dell'utente, che potrebbe installare il server da terze parti o crearlo autonomamente. Se un aggressore riesce a compromettere questo server MCP locale, può potenzialmente ottenere l'accesso a gran parte del sistema locale.

Un aggressore può ottenere l'accesso in vari modi. Può distribuire un server dannoso camuffato da integrazione legittima, modificare la configurazione di un host MCP in modo che esegua un comando dannoso oppure accedere a un server MCP in esecuzione in un ambiente con controlli di sicurezza insufficienti, ad esempio tramite il DNS rebinding, che induce un browser a inviare richieste a un servizio localhost.

Come proteggersi dalla compromissione del server MCP locale

L'uso di sandbox e di protocolli di consenso rigorosi è importante quando si utilizzano server MCP locali. I server MCP dovrebbero essere installati esclusivamente da fornitori attendibili e le autorizzazioni del sistema operativo dovrebbero limitare le directory a cui possono accedere.

Le vulnerabilità MCP sono spesso vecchie minacce in una nuova veste

Le vulnerabilità MCP derivano spesso da nuove applicazioni di rischi e metodologie di attacco consolidati. L'MCP introduce nuovi modi in cui gli aggressori possono sfruttare queste vulnerabilità attraverso le interazioni tra LLM, server MCP e servizi esterni.

Naturalmente, le minacce specifiche dell'MCP esistono. Tuttavia, vale la pena ricordare che i protocolli di sicurezza standard, come l'applicazione di un'autorizzazione rigorosa, l'uso di fornitori attendibili e la protezione dalle prompt injection, contribuiscono in modo significativo a proteggere qualsiasi implementazione MCP.