Sicurezza nella pipeline DevOps

Nello sviluppo del software e nei processi DevOps, dalla progettazione alla distribuzione, la sicurezza deve essere in primo piano. Se non ci si pensa, gli incidenti di sicurezza si ritorceranno contro di voi.

In questo post affronteremo una svista comune ma critica commessa dagli sviluppatori di API GraphQL: l'abilitazione delle funzioni di introspezione negli ambienti di produzione. L'introspezione è una funzione incredibile per comprendere e testare le funzionalità dell'API quando si è in fase di sviluppo. Ma se non la disabilitate prima di andare in produzione, aprite la vostra applicazione a vulnerabilità significative. Discuteremo come questo possa trasformarsi in un grave rischio per la sicurezza, insieme alle misure preventive che potete adottare per rafforzare la sicurezza nella vostra pipeline DevOps.

Lo scenario

Immaginate un team di sviluppo che guida l'implementazione dell'API GraphQL della propria organizzazione. GraphQL è un potente linguaggio di interrogazione progettato per consentire ai clienti di richiedere esattamente ciò di cui hanno bisogno con un'unica interrogazione. A differenza delle API REST tradizionali, che potrebbero richiedere più richieste per mettere insieme dati e relazioni complesse. La struttura dei dati in GraphQL è definita in uno schema, che delinea i tipi di dati, le query e le mutazioni disponibili.

Il team di sviluppatori si è impegnato a fondo e ha costruito qualcosa di davvero impressionante. Questa API non è solo robusta, ma anche scalabile, in grado di gestire milioni di transazioni al minuto, grazie alle funzionalità di autoscaling che il team ha progettato e realizzato. Grazie alla loro attenzione alle prestazioni e alla scalabilità, hanno fatto in modo che questa API possa gestire un carico enorme senza alcun intoppo.

Tuttavia, nella fretta di distribuire e stupire con questa nuova API GraphQL, hanno trascurato un piccolo dettaglio: l'introspezione è ancora abilitata nell'ambiente di produzione. L'introspezione è uno strumento potente per gli sviluppatori, che possono interrogare le risorse disponibili nell'API. Ma non è qualcosa che dovrebbe essere aperto all'accesso in produzione.

Quali sono le conseguenze?

Poiché l'API si espande per soddisfare la domanda, ogni nuova istanza moltiplica il rischio potenziale. Ora, la significativa vulnerabilità di sicurezza si è diffusa su un numero crescente di nodi. In questo modo, abbiamo preparato il terreno per un potenziale sfruttamento da parte di malintenzionati. Hanno tutto ciò che serve per scoprire informazioni dettagliate sulla struttura e sulle capacità di questa nuova API.

Dimenticando una semplice levetta, il team ha trasformato una funzione ben intenzionata in una lacunosa falla di sicurezza.

Comprendere la vulnerabilità

Con l'introspezione abilitata, uno sviluppatore può interrogare l'API GraphQL per vedere lo schema completo, con tutti i tipi di dati, i campi, le query e le mutazioni. È come avere una mappa dettagliata di tutti gli endpoint operativi e delle strutture dati di un'API. È una grande risorsa da avere nelle mani di uno sviluppatore. Ma non è una risorsa da mettere nelle mani di un cyberattaccante.

Si consideri come un utente malintenzionato potrebbe sfruttare le capacità di introspezione per conoscere la vostra API GraphQL. Innanzitutto, può definire dei frammenti per rendere i risultati delle query più leggibili.

fragment FullType on __Type {     kind     name     description     fields(includeDeprecated: true) {       name       description       args {         ...InputValue       }       type {         ...TypeRef       }       isDeprecated       deprecationReason     }     inputFields {       ...InputValue     }     interfaces {       ...TypeRef     }     enumValues(includeDeprecated: true) {       name       description       isDeprecated       deprecationReason     }     possibleTypes {       ...TypeRef     }   }   fragment InputValue on __InputValue {     name     description     type { ...TypeRef }     defaultValue   }   fragment TypeRef on __Type {     kind     name     ofType {       kind       name       ofType {         kind         name         ofType {           kind           name           ofType {             kind             name             ofType {               kind               name               ofType {                 kind                 name                 ofType {                   kind                   name                 }               }             }           }         }       }     }   }

Quindi, possono inviare una richiesta di introspezione del __schema che è disponibile nel tipo principale di una query. La query GraphQL potrebbe essere simile a questa:

{   __schema {     queryType {       name     }     mutationType {       name     }     subscriptionType {       name     }     types {       ...FullType     }     directives {       name       description       locations       args {         ...InputValue       }     }   } }

Inviando questa query, insieme alle definizioni dei frammenti, a un'API GraphQL con l'introspezione abilitata, un utente malintenzionato riceverà una risposta con un oggetto JSON completo di tutti i dettagli dell'API. Quindi, può utilizzare uno strumento come GraphQL Voyager per mostrare l'API GraphQL come un grafico interattivo.

Ecco un esempio di visualizzazione di un'API GraphQL basata sulla risposta alla query di introspezione mostrata sopra:

Come si può vedere, questo rivela gran parte della struttura e dei dettagli relativi alle operazioni di pagamento sensibili. Si tratta di informazioni estremamente utili per un aggressore che tenta di penetrare nella vostra API. Ancora una volta: ottimo per gli sviluppatori, ma purtroppo anche per gli aggressori.

Se si lascia l'introspezione abilitata in produzione, ecco i rischi a cui si va incontro:

• Esposizione delle informazioni: Informazioni dettagliate sullo schema possono fornire agli aggressori informazioni sui sistemi di backend, sui modelli di dati e sulla logica aziendale. Consegnando loro le planimetrie del vostro castello, li agevolate nella realizzazione di attacchi mirati.
• Facilitazione degli attacchi: Armati di questi dettagli sulla vostra API, gli aggressori possono creare query che sfruttano le vulnerabilità. Questo può portare a violazioni dei dati o a interruzioni del servizio.
• Drenaggio di risorse: Gli aggressori possono anche utilizzare queste conoscenze per creare query dannose come attacchi DoS (denial of service). Questi attacchi prosciugheranno le risorse e potenzialmente porteranno alla completa chiusura del sistema.

Ma non disperate! I passi per mitigare questo rischio sono semplici e immediati. Come primo passo per proteggerci, vediamo cosa dice OWASP.

Indicazioni dal foglio di istruzioni OWASP GraphQL

L'OWASP GraphQL Cheat Sheet è una risorsa preziosa per la sicurezza delle API GraphQL. Fornisce indicazioni per aiutarvi nelle seguenti aree:

• Convalida degli ingressi
• Limitare o prevenire query costose
• Garantire un'adeguata verifica del controllo degli accessi
• Disabilitare le configurazioni non sicure, come l'introspezione.

Il foglio informativo contiene una sezione dedicata all'introspezione e a GraphiQL. GraphiQL è un IDE in-browser per esplorare GraphQL. Simile alle capacità di introspezione, GraphiQL può esporre informazioni dettagliate sul funzionamento interno e sulla progettazione dell'API.

Se state costruendo un'API GraphQL, vi consigliamo di familiarizzare con il cheat sheet di OWASP.

Come mitigare la vulnerabilità di sicurezza Introspection

Prendendo spunto dal cheat sheet di OWASP, seguiremo le istruzioni per disabilitare le query di introspezione negli ambienti di produzione o accessibili al pubblico. Questo è fondamentale per evitare l'accesso non autorizzato a informazioni dettagliate sullo schema che potrebbero essere sfruttate dagli aggressori.

Come possiamo farlo?

Ecco un semplice frammento di codice in JavaScript che dimostra come disattivare l'introspezione in produzione se si usa Apollo Server:

const { ApolloServer } = require('apollo-server'); const server = new ApolloServer({   typeDefs,   resolvers,  // Enable introspection only in development or test environments   introspection: process.env.NODE_ENV === 'development' ||                 process.env.NODE_ENV === 'test', }); server.listen().then(({ url }) => {   console.log(`Server ready at ${url}`); });

Sì, in pratica è tutto qui. Questo semplice passo (impostare introspection a false quando si configura una nuova istanza di ApolloServer) impedirà agli utenti di accedere a informazioni dettagliate sullo schema tramite query di introspezione. In questo modo si riduce il rischio di fuga di informazioni sensibili.

Fare in modo che questo sia parte della pipeline Secure DevOps

Se il passo è così semplice, perché gli sviluppatori lo dimenticano così spesso? Perché sono concentrati su altre cose e impegnati a rispettare scadenze critiche. Non c'è da stupirsi che impostazioni di configurazione apparentemente minori vengano occasionalmente trascurate.

Ecco perché esistono i test automatizzati e la pipeline DevOps: per evitare errori umani e dimenticanze.

Come si può integrare questa misura di sicurezza nella pipeline DevOps? Ecco due suggerimenti:

• Scrivere un test di pre-deployment che verifichi esplicitamente la configurazione del server GraphQL per garantire che l'introspezione sia disabilitata al momento della distribuzione in produzione.
• Scrivere un test post-deployment che tenti una query di introspezione sull'ambiente di produzione. Quando il tentativo viene accolto da una risposta di errore (come ad esempio Cannot query field '__schema' on type 'Query'), il test dovrebbe essere superato.

Sfruttate gli strumenti della pipeline CI/CD come Jenkins, GitHub Actions o CircleCI per eseguire script che controllino le impostazioni dell'API GraphQL come parte del processo CI/CD.

Conclusione

La creazione di API GraphQL può essere un ottimo modo per innovare la vostra azienda, ma richiede che siate proattivi sulle vostre pratiche di sicurezza. Un piccolo errore potrebbe esporre la vostra API a enormi vulnerabilità. In questo post abbiamo trattato un esempio emblematico: la disabilitazione dell'introspezione per le implementazioni di produzione, in modo che gli aggressori non abbiano accesso a informazioni dettagliate sullo schema GraphQL.

Per ulteriori indicazioni e risorse, consultare la libreria completa di Linode di guide relative alla sicurezza, allo sviluppo GraphQL e a https://www.linode.com/docs/guides/platform/.