Le 10 principali minacce API di OWASP

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Questo documento descrive vari approcci che puoi utilizzare in Apigee per risolvere le vulnerabilità di sicurezza identificate da OWASP. Per altri approcci documentati per Apigee, consulta Opzioni di mitigazione delle 10 principali vulnerabilità OWASP del 2021 su Google Cloud.

Introduzione

OWASP è una community aperta dedicata ad aiutare le organizzazioni a sviluppare, acquistare e gestire applicazioni e API affidabili. Tramite il progetto OWASP API Security, OWASP pubblica i rischi per la sicurezza più critici per le applicazioni web e le API REST e fornisce consigli per affrontare questi rischi.

Questo documento illustrerà gli approcci per proteggersi dagli attacchi comuni basati su API, come identificati dalle 10 principali minacce alla sicurezza delle API di OWASP del 2019. Un tema comune nelle principali minacce evidenziate dall'ultimo elenco è causato dal posizionamento improprio dei controlli di autenticazione e autorizzazione, come l'affidamento al filtraggio dei dati restituiti da una richiesta API all'interno delle app client, utilizzando l'anti-pattern di affidarsi all'app client di consumo per eseguire l'applicazione del controllo dell'accesso.

Con la crescita dell'ecosistema API che continua a un ritmo rapido, gli abusi e gli usi impropri delle API che comportano l'esfiltrazione di dati da parte degli autori degli attacchi stanno purtroppo diventando uno dei vettori di attacco più comuni oggi. La sicurezza continua a essere una priorità fondamentale per Apigee, con una serie di nuove funzionalità come Advanced API Ops, che include funzionalità di rilevamento delle anomalie. Tuttavia, progettare e implementare correttamente le funzionalità di sicurezza di Apigee è fondamentale per ridurre la probabilità di attacchi riusciti alle tue API.

Le applicazioni consumer devono essere considerate non attendibili o "pubbliche", in quanto non controlli la piattaforma su cui viene eseguita l'app. Supponi che qualsiasi app pubblica possa essere compromessa e lo sarà, pertanto non è possibile fare affidamento su di essa per l'applicazione del controllo dell'accesso (API1, API5), il filtro dei dati di risposta (API6) o l'archiviazione sicura dei secret client (API2), come chiavi API o token di accesso. Alcuni consigli emergono dall'esame della OWASP Top 10 del 2019:

  • Determina il tipo di app client che utilizzeranno le tue API (SPA, mobile o basate su browser) e progetta i pattern di autenticazione, autorizzazione e sicurezza appropriati.
  • Utilizza sempre i flussi OAuth o OpenID Connect "client pubblico" (l'utilizzo di PKCE è vivamente consigliato)
  • Pensa alla logica di business della tua app, definisci prima la specifica OpenAPI e progetta i proxy API per filtrare tutti i dati di risposta dal backend in Apigee. Non fare mai affidamento sulla logica del codice dell'app downstream per eseguire questa operazione.
  • Filtra tutte le richieste di dati contenenti PII specifiche dell'utente per consentire solo i dati del backend appartenenti all'utente richiedente.

API1:2019 Autorizzazione a livello di oggetto compromessa

Descrizione minaccia

La convalida dell'autorizzazione insufficiente di una richiesta di accesso a un oggetto consente a un malintenzionato di eseguire un'azione non autorizzata riutilizzando un token di accesso. Questa minaccia è causata da una configurazione non corretta delle convalide dell'autorizzazione. Apigee fornisce criteri VerifyApiKey, OAuth e JSON Web Token (JWT) che contribuiscono a proteggere da questa vulnerabilità, ma è fondamentale che questi criteri siano configurati correttamente per prevenire questa minaccia.

Per prevenire questa minaccia, è importante che i team di sviluppo e sicurezza delle applicazioni collaborino a stretto contatto. L'autorizzazione è per sua natura un argomento complesso e un'autorizzazione granulare efficace richiede una profonda comprensione della logica di business dell'applicazione.

Dal punto di vista dell'implementazione di Apigee, ci sono due aspetti principali da considerare:

  • Integrità del token di accesso
  • Applicazione del controllo dell'accesso

Integrità del token di accesso

È fondamentale verificare che il token fornito dal client richiedente non sia stato manomesso utilizzando il flusso OAuth o OpenID Connect corretto insieme al meccanismo di convalida o firma delle credenziali appropriato. Apigee supporta tutti i flussi OAuth più utilizzati.

Le policy di verifica dei token di accesso Apigee includono:

Applicazione del controllo dell'accesso

Una volta verificata la validità del token di accesso, è fondamentale implementare policy di applicazione del controllo dell'accesso per valutare ogni richiesta API in entrata in base ai diritti di accesso del token di autorizzazione.

Apigee fornisce due meccanismi principali per verificare e applicare i criteri di autorizzazione:

  • Interno: utilizza flussi condizionali per valutare le richieste di accesso in base alle attestazioni estratte come variabili di flusso da un token di autorizzazione
  • Delegata: utilizzo di un callout del servizio a una soluzione di gestione dell'accesso di terze parti

L'approccio interno (illustrato nella figura precedente) è consigliato quando il modello di controllo dell'accesso è relativamente semplice. Ad esempio, se le rivendicazioni estratte da un token di accesso possono essere utilizzate per valutare e autorizzare direttamente una richiesta di oggetto API.

Utilizza le variabili di flusso disponibili per le policy OAuth o JWT per valutare le richieste di accesso utilizzando istruzioni di flusso condizionali.

L'approccio delegato (illustrato nella figura precedente) è consigliato quando le rivendicazioni estratte da un token di accesso non possono essere utilizzate direttamente per autorizzare una richiesta API a un oggetto di backend o per tipi di flusso OAuth più complessi che richiedono una chiamata separata a un server di autorizzazione per ottenere un token di accesso.

Utilizzando le norme relative al callout del servizio, è possibile richiedere una decisione relativa alle norme di autorizzazione a un servizio di terze parti oppure ottenere informazioni aggiuntive sulle attestazioni relative all'agente richiedente per poi prendere una decisione sul controllo degli accessi utilizzando un flusso condizionale.

API2:2019 Autenticazione utente compromessa

Descrizione minaccia

Le norme di autenticazione utente implementate in modo errato consentono agli autori degli attacchi di impersonare utenti legittimi sfruttando i difetti di implementazione nelle implementazioni dell'autenticazione. Alcuni principi di autenticazione da tenere presente quando implementi approcci di autenticazione includono:

  • Autentica sempre sia lo user agent (l'app) sia l'utente che ha inviato la richiesta
  • Utilizza pattern di autenticazione e autorizzazione delegata ed evita di passare le password direttamente all'interno di una richiesta API
  • Convalida sempre la firma delle credenziali di accesso e assicurati che tutte le credenziali di accesso utilizzate abbiano una data di scadenza definita
  • Prevenire gli attacchi di forza bruta impostando quote e utilizzando Apigee Sense per rilevare e rispondere agli attacchi di forza bruta basati su bot

Secondo un paradigma outside-in, la progettazione dell'API si basa sui casi d'uso dei consumatori per i dati anziché sulla struttura dei dati esistenti nei sistemi di backend e la sicurezza è un elemento fondamentale durante la progettazione delle API per i consumatori esterni. I sistemi di backend tradizionalmente non sono creati con implementazioni di autenticazione sufficientemente solide per l'esposizione a reti pubbliche. È qui che Apigee, in combinazione con una soluzione di gestione dell'identità e degli accessi, può offrire soluzioni efficaci per proteggerti da questa minaccia.

Ci sono alcuni elementi principali da considerare, che verranno trattati nelle sezioni successive:

  • Progettazione della sicurezza: sfruttare appieno le funzionalità di Apigee per implementare pattern di autenticazione
  • Governance: garantire che l'uso corretto dei pattern di autenticazione progettati venga utilizzato in modo coerente in tutti i prodotti API pubblicati
  • Sicurezza operativa: capacità di rilevare comportamenti sospetti o anomali e tentativi di aggirare o forzare i proxy API autenticati

Progettazione della sicurezza

L'obiettivo della progettazione della sicurezza è implementare correttamente i flussi di autenticazione e l'integrazione con strumenti di identità di terze parti. La progettazione della sicurezza è una fase fondamentale e inizia con la comprensione del tipo giusto di flusso di autenticazione delegata da utilizzare in base al tipo di app che utilizzerà gli endpoint API. Il passaggio successivo consiste nel definire, insieme al team di gestione delle identità, i pattern di integrazione da implementare con la tua soluzione di gestione delle identità.

Le RFC OpenID Connect e OAuth forniscono un ampio numero di flussi di autenticazione e autorizzazione delegati, nonché gli attori coinvolti in questi flussi. Si tratta di un argomento complesso e non sorprende che l'autenticazione interrotta sia una delle principali minacce all'API OWASP. Fornire un'introduzione completa all'implementazione corretta degli standard di identità non rientra nell'ambito di questo documento, ma Apigee dispone di molte risorse aggiuntive per comprendere meglio i flussi OAuth, come questo ebook e questo webcast, nonché un'implementazione di esempio.

Criteri di autenticazione

Le norme Apigee che aiutano a risolvere i problemi di identità e autenticazione includono:

Gestione del traffico

Le seguenti funzionalità di gestione del traffico di Apigee aiutano a proteggere dagli attacchi di forza bruta:

  • Il criterio Arresto picchi, per impostare un limite di frequenza della media mobile complessiva su un proxy API
  • Norme relative alle quote, per impostare limiti di frequenza granulari per i proxy API in base alle quote definite da chiavi app, sviluppatori o quote di prodotti API
  • Norme di memorizzazione nella cache, per la memorizzazione nella cache dei token di accesso archiviati in base ai tempi di scadenza definiti, nonché la possibilità di invalidare le credenziali memorizzate nella cache (ad esempio, in una situazione in cui un token di accesso valido viene compromesso)

Governance

La sicurezza è un processo continuo, non un progetto da impostare e dimenticare, e una delle maggiori cause di violazioni della sicurezza è la configurazione errata. Una volta definiti i flussi di autenticazione, i pattern di integrazione delle identità e i criteri di gestione del traffico correlati all'autenticazione, è assolutamente fondamentale che vengano implementati in modo corretto e coerente.

Apigee fornisce una serie di funzionalità e strumenti per garantire l'integrità dell'implementazione e prevenire errori di configurazione.

Controllo dell'accesso basato sui ruoli (RBAC)

Che tu sia una grande azienda o una piccola startup, per evitare errori di configurazione devi assicurarti che solo le persone e i team giusti possano accedere e modificare le configurazioni del proxy API. I programmi API sono supportati da team multidisciplinari in tutta l'organizzazione. È assolutamente essenziale che a ogni team vengano concesse solo le autorizzazioni necessarie per svolgere il proprio lavoro nell'ambito del percorso API.

Apigee fornisce le funzionalità per gestire l'accesso basato sui ruoli, consentendoti di assegnare utenti a ruoli predefiniti o di creare ruoli personalizzati adatti ai tuoi team API. Definire e gestire correttamente l'assegnazione dei ruoli è fondamentale per consentirti di scalare in modo sicuro il tuo programma API. Puoi anche utilizzare il federation per l'integrazione con la directory aziendale esistente e per ridurre la necessità di gestire un secondo insieme di credenziali amministratore in Apigee.

Flussi condivisi

I flussi condivisi consentono di definire criteri e risorse in un oggetto riutilizzabile che può essere implementato nei proxy API. Ad esempio, potresti aver progettato in collaborazione con i tuoi team di sicurezza più pattern di progettazione dell'autenticazione in base al tipo di app che utilizza un'API. Uno sviluppatore di API non deve essere un esperto di identità per riutilizzare questo flusso, ma deve semplicemente conoscere il flusso condiviso corretto da aggiungere alla configurazione del proxy API esistente utilizzando il criterio Flow callout.

Figura: i flussi condivisi sono bundle riutilizzabili di norme e logica condizionale che ti consentono di mantenere un pattern composito.

Sicurezza operativa

Una volta che le API sono in produzione utilizzando i giusti pattern di autenticazione con la gestione del traffico di base, il tuo team SecOps deve anche essere in grado di monitorare e rispondere ad attività sospette, che spesso iniziano con tentativi di compromissione delle credenziali di autenticazione.

Apigee Sense

Apigee Sense protegge le tue API dal traffico di richieste indesiderato, inclusi gli attacchi di client dannosi. Apigee Sense analizza il traffico delle richieste API, identificando pattern che potrebbero rappresentare richieste indesiderate. Utilizzando questa analisi, puoi identificare i client che effettuano richieste indesiderate, quindi intervenire per consentire, bloccare o contrassegnare queste richieste. Le funzionalità future di Sense includeranno la possibilità di attivare automaticamente la verifica reCAPTCHA sul traffico sospetto.

Con Apigee Sense, puoi proteggere le tue API da pattern di richieste che includono:

  • Comportamento automatizzato che si integra con il comportamento umano
  • Tentativi persistenti dallo stesso IP
  • Tassi di errore insoliti
  • Richieste client sospette
  • Scansione dei dati
  • Attacchi di raccolta delle chiavi e di forza bruta per l'autenticazione
  • Picchi di attività
  • Pattern geografici

Operazioni API avanzate

Sebbene Sense sia stato progettato specificamente per rilevare e rispondere a minacce simili a bot, Advanced API Ops include sia il rilevamento di anomalie sia la definizione di avvisi avanzati.

Il rilevamento delle anomalie funziona applicando modelli di intelligenza artificiale (AI) e machine learning (ML) ai tuoi dati API storici. Il rilevamento delle anomalie può quindi generare avvisi in tempo reale per scenari a cui non avevi nemmeno pensato, per migliorare la tua produttività e ridurre il tempo medio di risoluzione (MTTR) dei problemi dell'API.

Advanced API Ops si basa sul meccanismo di avviso di monitoraggio delle API esistente per aggiungere i seguenti tipi di avvisi avanzati:

  • Avvisi di anomalie. Edge rileva i problemi di traffico e rendimento senza che tu debba predeterminarli. A questo punto, puoi generare un avviso per queste anomalie.
  • Avvisi di scadenza TLS. Genera una notifica quando un certificato TLS sta per scadere

API3:2019 Esposizione eccessiva dei dati

Descrizione minaccia

Un'API pubblicata potrebbe esporre più dati del necessario, facendo affidamento sull'app client per eseguire il filtraggio necessario. Se un malintenzionato esegue query direttamente sull'API sottostante, può accedere a dati sensibili.

Uno dei principi di progettazione "dall'esterno verso l'interno" di Apigee per la progettazione di API è la parsimonia dei dati. Collabora con i tuoi progettisti UX e sviluppatori per esporre solo i dati tramite le API necessari all'interno della UI dell'app. I sistemi di backend non sono stati creati per i pattern di utilizzo pubblici, quindi uno dei primi compiti della progettazione API-first con Apigee è ridurre i dati esposti al minimo necessario per fornire un ottimo prodotto API per i tuoi clienti e sviluppatori.

Un altro dei principi di progettazione di Apigee è la riutilizzabilità. A parte i problemi di sicurezza, affidarsi a un'app per filtrare i dati forniti da un'API comporta la necessità di trasferire la logica di filtraggio su ogni piattaforma per cui sviluppi un'app.

Dal punto di vista della sicurezza, questa minaccia deriva dalla delega dell'applicazione dell'autorizzazione a un'app, spesso però su una piattaforma o un sistema operativo su cui non hai il controllo. Abbiamo già esaminato in API1 e API2 l'importanza di implementare correttamente l'autenticazione e l'autorizzazione per evitare l'accesso ai dati non autorizzato.

Le sezioni successive esaminano come:

  • Riscrivi le richieste e le risposte ai servizi di backend per ridurre al minimo l'esposizione dei dati
  • Implementa la gestione dei guasti per impedire che i messaggi di errore dettagliati espongano informazioni sensibili sull'ambiente agli attaccanti sui tuoi servizi di backend

Riscrivere risposte e richieste

I sistemi di backend in genere non sono progettati per l'utilizzo su app pubbliche o su reti pubbliche non attendibili. Apigee Edge è stato progettato per consentirti di implementare prodotti API pubblici proteggendo i tuoi backend da un'esposizione eccessiva dei dati.

Per farlo, Apigee utilizza tre criteri chiave:

  • Assegna messaggio
  • Callout di codice
  • Gestione dei guasti

Assegna policy dei messaggi

Il criterio Assign Message modifica o crea nuovi messaggi di richiesta e risposta durante il flusso del proxy API. La policy ti consente di eseguire le seguenti azioni su questi messaggi:

  • Aggiungi nuovi parametri del modulo, intestazioni o parametri di ricerca a un messaggio
  • Copia le proprietà esistenti da un messaggio all'altro
  • Rimuovi intestazioni, parametri di query, parametri del modulo e/o payload dei messaggi da un messaggio
  • Imposta il valore delle proprietà esistenti in un messaggio

Con Assegna messaggio, in genere aggiungi, modifichi o rimuovi le proprietà della richiesta o della risposta. Tuttavia, puoi anche utilizzare Assegna messaggio per creare un messaggio di richiesta o risposta personalizzato e passarlo a una destinazione alternativa, come descritto in Creare messaggi di richiesta personalizzati.

Riscrittura complessa con codice personalizzato

Per la gestione e la riscrittura di dati complessi la cui complessità va oltre le capacità della policy Assegna messaggio, puoi utilizzare linguaggi procedurali come JavaScript, Java o Python. Puoi aggiungere codice personalizzato a un proxy API e poi chiamarlo dalle norme aggiunte al flusso del proxy. Il supporto del codice procedurale è progettato per semplificare l'implementazione della gestione complessa di variabili di flusso, errori e corpi di richiesta e risposta.

Con il codice procedurale puoi:

  • Crea o manipola valori del corpo complessi, come i valori di richiesta e risposta.
  • Riscrivi gli URL, ad esempio per mascherare un URL endpoint di destinazione.

Apigee Edge include un criterio separato per i linguaggi supportati: criterio JavaScript, criterio Callout Java e criterio Script Python.

Gestione dei guasti

Apigee ti consente di eseguire la gestione personalizzata delle eccezioni utilizzando una policy di tipo Raise Fault. Il criterio Raise Fault, che è una variante del criterio Assign Message, consente di generare una risposta di errore personalizzata in risposta a una condizione di errore.

Flussi condivisi

I flussi condivisi possono essere utilizzati per imporre la standardizzazione dei messaggi di errore. Ad esempio, le stesse policy configurate che rilevano un codice di errore HTTP specifico dal backend possono essere utilizzate per riscrivere la risposta di errore in modo da restituire un messaggio di errore generico.

API4:2019 Lack of resources & rate limiting

Descrizione minaccia

Se non implementano le norme di limitazione della frequenza, gli autori di attacchi possono sovraccaricare il backend con attacchi Denial of Service.

Questa minaccia può essere facilmente risolta utilizzando le seguenti funzionalità di Apigee:

  • Policy relative a quote e Spike Arrest come controlli preventivi per imporre limiti di traffico alle richieste API in entrata
  • Apigee Sense per rilevare e rispondere in modo dinamico agli attacchi basati su bot
  • Monitoraggio e avvisi avanzati delle API come controlli di rilevamento per ricevere avvisi in caso di attacchi DDoS in corso

Limitazione di frequenza con le policy Quota e Spike Arrest

Apigee fornisce due criteri per la limitazione di frequenza:

  • Spike Arrest fornisce una policy generale, definita a livello di proxy API, per limitare la frequenza del numero complessivo di richieste in entrata a un backend.
  • Le quote forniscono uno strumento di policy granulare per l'applicazione delle policy di quota a livello di proxy API o prodotto API.

Spike Arrest

La policy Spike Arrest protegge dai picchi di traffico. Questa policy limita il numero di richieste elaborate da un proxy API e inviate a un backend, proteggendo da ritardi nelle prestazioni e tempi di inattività, utilizzando un valore medio mobile definibile all'interno della policy.

Quote

Il criterio Quota consente di configurare il numero di messaggi di richiesta consentiti da un proxy API in un periodo di tempo, ad esempio un minuto, un'ora, un giorno, una settimana o un mese. Puoi impostare la quota in modo che sia la stessa per tutte le app che accedono al proxy API oppure puoi impostarla in base a:

  • Il prodotto che contiene il proxy API
  • L'app che richiede l'API
  • Lo sviluppatore di app
  • Molti altri criteri

Questo criterio è più granulare di Spike Arrest e in genere deve essere utilizzato contemporaneamente.

Rilevamento di bot con Apigee Sense

Con Apigee Sense, puoi intervenire per consentire, bloccare o contrassegnare esplicitamente le richieste di client, intervalli IP o organizzazioni di sistemi autonomi specifici, in base a client o località che mostrano comportamenti dannosi o sospetti. Apigee Edge applica queste azioni alle richieste prima che vengano elaborate dai proxy API. Ad esempio, è possibile rilevare un intervallo IP o un client specifico che mostra un comportamento di "brute guessor", quindi bloccarlo o segnalarlo.

Rilevamento delle minacce con Advanced API Ops Monitoring

Utilizza un avviso sul traffico per generare una notifica quando il traffico per un ambiente, un proxy o una regione cambia di una percentuale specificata in un intervallo di tempo. Questa funzionalità può generare dinamicamente un avviso quando il traffico si discosta in modo significativo dal throughput previsto, come accadrebbe durante un attacco DDoS. Questi avvisi possono essere facilmente inviati a una soluzione di logging e monitoraggio di terze parti.

API5:2019 Autorizzazione a livello di funzione interrotta

Descrizione minaccia

Questa minaccia è una variante di API1 ed è anche una vulnerabilità di autorizzazione. Con questa minaccia, un malintenzionato è in grado di eseguire azioni inviando richieste a funzioni a cui non è autorizzato ad accedere. Ad esempio, un malintenzionato potrebbe essere in grado di modificare o eliminare dati che è autorizzato solo a leggere se un endpoint API non convalida il verbo della richiesta HTTP, sostituendo una GET con una PUT o una DELETE. In alternativa, se non implementa un controllo dell'accesso sufficientemente restrittivo su un percorso URI di risorsa API, un endpoint API potrebbe consentire a un malintenzionato di visualizzare i dati di un altro utente semplicemente modificando il percorso in una richiesta.

Questo tipo di minaccia evidenzia il valore dell'utilizzo di Apigee come livello di mediazione e astrazione, in quanto molti sistemi di backend, non essendo progettati per l'accesso pubblico, potrebbero fornire per impostazione predefinita un singolo endpoint per l'esecuzione di più funzioni di logica di business, incluse anche funzionalità amministrative ad alto rischio.

Gli elementi concettuali per ridurre la probabilità di questa minaccia sono in genere suddivisi in:

  • Che cosa viene protetto? Pensa alla tua strategia di prodotto API e implementa una segmentazione logica delle funzionalità quando utilizzi le best practice RESTful per progettare i percorsi e le risorse esposti dalle funzionalità di proxy API, prodotti e app Apigee.
  • Chi accede alle risorse API? Definisci le buyer persona di alto livello e implementa i diritti di accesso predefiniti con "privilegio minimo" utilizzando alcune delle funzionalità di autenticazione e autorizzazione di Apigee, come descritto in API1 e API2.
  • Come vengono applicate le tue policy di accesso? Utilizza flussi e errori condizionali per convalidare il percorso dell'URL e il verbo di tutte le richieste API.

Figura: questo diagramma mostra come l'autorizzazione a livello di funzione verrebbe applicata in Apigee, utilizzando gli ambiti forniti all'interno di un token di accesso come diritti.

Segmentazione logica con proxy API, prodotti e app

Apigee fornisce un toolkit estremamente flessibile per consentire la segmentazione logica delle risorse API, consentendo di raggruppare i proxy API in un numero qualsiasi di prodotti API, che a loro volta vengono utilizzati dagli sviluppatori di app, che possono registrare app che utilizzano i tuoi prodotti API. Le policy di accesso possono essere definite a uno qualsiasi di questi livelli.

Prima di implementare l'autorizzazione e la segmentazione funzionali efficaci, è fondamentale definire una strategia per i prodotti API. Parte di questo processo essenziale e continuo è la definizione del "chi" e del "cosa" dei tuoi prodotti API, esaminando le risorse API dal punto di vista del cliente e dello sviluppatore e poi definendo a livello di risorsa di percorso e verbo HTTP esattamente i tipi di richieste che saranno consentiti.

Figura: le risorse API raggruppate in un prodotto API possono provenire da una o più API, quindi puoi combinare le risorse per creare livelli di consumo e limiti di autorizzazione.

Controllo dell'accesso a livello di funzione con ambiti OAuth e rivendicazioni JWT

Sebbene gli approcci di autorizzazione considerati in precedenza per API1:2019 Broken object authorization gestiscano il controllo dell'accesso granulare a livello di oggetto, è altrettanto importante gestire il controllo dell'accesso grossolano a livello di funzione. L'utente che invia la richiesta è autorizzato a richiedere questo percorso dell'URL? Questo tipo di norma viene spesso definito in base alla persona utente (cliente, dipendente, amministratore, sviluppatore interno o di terze parti).

Per ridurre il rischio di errori di configurazione, ti consigliamo di collaborare con il tuo team di sicurezza per assicurarti che le asserzioni sull'utente richiedente siano contenute nel token di accesso, tramite l'utilizzo di ambiti OAuth o rivendicazioni JWT.

Richiedere la convalida con flussi condizionali

A livello di base, una chiamata API REST è composta da:

  • Un endpoint
  • Una risorsa
  • Un verbo di azione
  • Un numero qualsiasi di attributi della richiesta aggiuntivi, ad esempio i parametri di ricerca

Il tipo di attacco descritto in questa minaccia è in genere causato dal filtraggio insufficiente di una richiesta API, consentendo così a un malintenzionato di eseguire azioni non autorizzate o accedere a una risorsa protetta. Oltre alla logica condizionale che consente di filtrare le richieste in base ai token di accesso o alle rivendicazioni, Apigee consente l'implementazione della logica di filtraggio in base alla richiesta stessa.

Una volta compresa e definita chiaramente la logica di business di un prodotto API, quali funzioni sono consentite dalle tue API, il passaggio successivo consiste nel limitare qualsiasi richiesta che non rientra in questo ambito tramite queste funzionalità del prodotto Apigee:

  • Logica condizionale e criteri Raise Fault per limitare i percorsi o i verbi delle risorse in qualsiasi passaggio di una configurazione del flusso proxy
  • Policy di protezione dalle minacce JSON e XML per proteggere dagli attacchi basati sui contenuti utilizzando payload di richieste JSON o XML non validi

API6:2019 Mass assignment

Descrizione minaccia

I dati non filtrati forniti tramite API alle app client consentono agli autori degli attacchi di indovinare le proprietà degli oggetti tramite richieste o di utilizzare le convenzioni di denominazione degli endpoint per trovare indizi su dove eseguire modifiche o accessi non autorizzati alle proprietà degli oggetti di dati archiviati nel backend.

Questa minaccia si verifica quando i dati non filtrati (in genere in formato JSON o XML) vengono inviati a un client, consentendo a un malintenzionato di indovinare i dettagli di implementazione sottostanti dei tuoi sistemi di backend, nonché i nomi delle proprietà degli elementi di dati riservati. Il risultato di questo tipo di attacco potrebbe potenzialmente concedere a un malintenzionato la possibilità di leggere o manipolare dati inappropriati oppure, nei casi peggiori, potrebbe abilitare vulnerabilità di esecuzione di codice da remoto.

In genere, per consentire questo tipo di minaccia sono coinvolti due aspetti:

  • La prospettiva di progettazione delle API. Non fare mai affidamento sulla logica dell'applicazione per eseguire il filtraggio dei dati lato client, poiché le app possono essere sfruttate dagli autori degli attacchi ed essere considerate attendibili. Progetta sempre lo schema dei dati dell'API in modo da esporre solo i dati minimi e necessari per abilitare un servizio API
  • La prospettiva di implementazione dell'API. Implementa il filtro dei dati e la convalida dello schema per impedire l'esposizione inavvertita di dati riservati a un'applicazione client

Dal punto di vista del prodotto Apigee, forniamo diverse funzionalità utili per garantire un'implementazione robusta del filtro dei dati delle tue API.

Policy di filtraggio delle specifiche OpenAPI

La policy OASValidation (convalida della specifica OpenAPI) consente di convalidare un messaggio di richiesta o risposta in entrata in base a una specifica OpenAPI 3.0 (JSON o YAML). Queste norme ti consentono di:

  1. Progetta la tua API creando una specifica OpenAPI (OAS)
  2. Implementa la logica di mediazione, sicurezza e memorizzazione nella cache necessaria per esporre in modo sicuro un prodotto API dal backend con Apigee
  3. Convalida le richieste in entrata in base allo schema dei dati definito nella specifica OAS, inclusi basepath, verb, request message policy e parameters

Policy SOAPMessageValidation

La policy di convalida dei messaggi SOAP consente di convalidare le richieste basate su XML convalidando un messaggio XML rispetto a uno schema XSD o un messaggio SOAP rispetto a una definizione WSDL. Inoltre, puoi utilizzare il criterio di convalida dei messaggi per verificare che il payload di un messaggio JSON o XML sia ben formato, il che include la verifica di quanto segue in un messaggio XML o JSON:

  • Esiste un singolo elemento radice
  • Non sono presenti caratteri non ammessi nei contenuti
  • Gli oggetti e i tag sono nidificati correttamente
  • I tag di inizio e di fine corrispondono

API7:2019 Configurazione errata della sicurezza

Descrizione minaccia

La configurazione errata della sicurezza è in genere il risultato di configurazioni predefinite non sicure, configurazioni incomplete o ad hoc, spazio di archiviazione cloud aperto, intestazioni HTTP configurate in modo errato, metodi HTTP non necessari, condivisione delle risorse cross-origin (CORS) permissiva e messaggi di errore dettagliati contenenti informazioni sensibili. Gli autori degli attacchi spesso tentano di trovare difetti non corretti, endpoint comuni o file e directory non protetti per ottenere l'accesso non autorizzato o la conoscenza del sistema che vogliono attaccare. Errori di configurazione della sicurezza possono non solo esporre dati sensibili degli utenti, ma anche dettagli del sistema che potrebbero portare alla compromissione completa del server. Inoltre, alcuni altri casi d'uso per le vulnerabilità per configurazioni errate della sicurezza possono includere:

  • TLS configurato in modo errato
  • Messaggi di errore con analisi dello stack
  • Sistemi senza patch
  • Pannelli di gestione di server o spazio di archiviazione esposti

Le organizzazioni possono adottare varie misure per affrontare e mitigare le sfide relative alle configurazioni errate di sicurezza, tra cui:

  1. Definizione e standardizzazione dei processi di hardening e applicazione di patch
  2. Sviluppare la governance intorno all'ecosistema API
  3. Limitare l'accesso amministrativo e attivare l'audit e gli avvisi

Flussi condivisi e hook di flusso

Apigee supporta il concetto di flusso condiviso, che consente agli sviluppatori di API di combinare criteri e risorse in un gruppo riutilizzabile. Acquisendo funzionalità riutilizzabili in un unico posto, un flusso condiviso ti aiuta a garantire la coerenza, ridurre i tempi di sviluppo e gestire più facilmente il codice. Puoi includere un flusso condiviso all'interno di singoli proxy API oppure puoi fare un ulteriore passo avanti e inserire flussi condivisi negli hook di flusso per eseguire automaticamente la logica del flusso condiviso per ogni proxy API di cui è stato eseguito il deployment nello stesso ambiente di un flusso condiviso.

Monitoraggio delle API

Apigee fornisce una piattaforma completa di monitoraggio delle API. Il monitoraggio delle API consente alle organizzazioni di rilevare in modo proattivo i problemi di traffico e prestazioni delle API. Apigee API Monitoring funziona in combinazione con Apigee Edge per Public Cloud per fornire approfondimenti contestuali in tempo reale sul rendimento delle API, aiuta a diagnosticare rapidamente i problemi e facilita le azioni correttive per la continuità aziendale.

Figura: Apigee API Monitoring fornisce un'ampia gamma di strumenti per monitorare, esaminare e intervenire in caso di problemi. Sfrutta le migliori funzionalità di intelligence di Google Cloud.

Apigee Sense

Apigee Sense aiuta a proteggere le API dal traffico di richieste indesiderato, inclusi gli attacchi di client dannosi. Apigee Sense analizza il traffico delle richieste API, identificando pattern che potrebbero rappresentare richieste indesiderate.

Utilizzando questa analisi, le organizzazioni possono identificare i client che effettuano richieste indesiderate, quindi intervenire per consentire, bloccare o contrassegnare queste richieste. Con Apigee Sense, è possibile proteggere le API da pattern di richieste che includono:

  • Comportamento automatizzato che si integra con il comportamento umano
  • Tentativi persistenti dallo stesso IP
  • Tassi di errore insoliti
  • Richieste client sospette
  • Scansione dei dati
  • Estrazione delle chiavi
  • Picchi di attività
  • Pattern geografici

API8:2019 Injection

Descrizione minaccia

L'inserimento non attendibile di dati, come SQL, NoSQL, analizzatori XML, ORM, LDAP, comandi del sistema operativo e JavaScript, nelle richieste API può comportare l'esecuzione di comandi non intenzionali o l'accesso non autorizzato ai dati. Gli autori degli attacchi alimenteranno l'API con dati dannosi tramite tutti i vettori di iniezione disponibili, come input diretti, parametri, servizi integrati e così via, aspettandosi che vengano inviati a un interprete. Gli autori degli attacchi possono scoprire facilmente questi difetti durante la revisione del codice sorgente utilizzando scanner di vulnerabilità e fuzzing. Un'iniezione riuscita può portare alla divulgazione di informazioni con conseguenze sulla riservatezza e sulla perdita di dati o, in alcuni casi, anche a un attacco DoS.

Le best practice per mitigare gli errori/attacchi di iniezione includono la definizione rigorosa dei dati di input, ad esempio schemi, tipi, pattern di stringhe, l'esecuzione della convalida dell'input, i controlli dei limiti e la loro applicazione in fase di runtime. La piattaforma Apigee consente di convalidare i dati in entrata utilizzando i filtri per consentire solo valori validi per ogni parametro di input.

Apigee Edge, che funge da server per le richieste API in entrata, verifica che la struttura del payload rientri in un intervallo accettabile, noto anche come controllo dei limiti. Puoi configurare un proxy API in modo che la routine di convalida dell'input trasformi l'input per rimuovere sequenze di caratteri rischiose e sostituirle con valori sicuri.

Policy di protezione delle espressioni regolari

Il criterio RegularExpressionProtection estrae informazioni da un messaggio (ad esempio, percorso URI, parametro di query, intestazione, parametro del modulo, variabile, payload XML o payload JSON) e valuta i contenuti in base a espressioni regolari predefinite. Se una delle espressioni regolari specificate restituisce il valore true, il messaggio viene considerato una minaccia e viene rifiutato. Un'espressione regolare, o regex in breve, è un insieme di stringhe che specificano un pattern in una stringa. Le espressioni regolari consentono di valutare i pattern dei contenuti in modo programmatico. Le espressioni regolari possono essere utilizzate, ad esempio, per valutare un indirizzo email per assicurarsi che sia strutturato correttamente.

L'utilizzo più comune di RegularExpressionProtection è la valutazione dei payload JSON e XML per contenuti dannosi.

Nessuna espressione regolare può eliminare tutti gli attacchi basati sui contenuti e devono essere combinati più meccanismi per consentire una difesa approfondita. Questa sezione descrive alcuni pattern consigliati per impedire l'accesso ai contenuti.

La piattaforma Apigee offre diversi altri approcci per la convalida dell'input:

Convalidare i tipi di contenuti

Il tipo di contenuti si riferisce ai contenuti di un file trasferito tramite HTTP e classificato in base a una struttura in due parti. Apigee consiglia di convalidare i tipi di contenuti per la richiesta e la risposta utilizzando la logica condizionale, come spiegato di seguito.

API9:2019 Gestione impropria degli asset

Descrizione minaccia

La gestione e la separazione insufficienti degli ambienti consentono agli aggressori di accedere a endpoint API non protetti. La mancanza di misure di salvaguardia della governance causa anche l'esposizione non necessaria di risorse deprecate.

Questa minaccia può essere affrontata sfruttando le funzionalità consolidate di Apigee per gestire l'intero ciclo di vita delle API, consentendoti di creare un modello di governance completo che consenta la collaborazione tra i team e, allo stesso tempo, applicare la separazione delle responsabilità tra gli stakeholder della sicurezza e gli sviluppatori di API. I confini e i controlli possono essere configurati e gestiti utilizzando:

Organizzazioni, ambienti e revisioni: guardrail virtuali e fisici che garantiscono l'isolamento e una procedura di promozione sicura tramite i contesti di runtime.

Controllo dell'accesso basato sui ruoli: solo le persone necessarie nei tuoi team API avranno le autorizzazioni per gestire le modifiche alla configurazione e anche la procedura di promozione.

Gestione dei segmenti di pubblico per la documentazione API: una volta pubblicata un'API nel portale per sviluppatori, puoi limitare la visibilità della documentazione gestendo i segmenti di pubblico di destinazione.

Hook di flusso: puoi applicare criteri e pattern globali che possono essere gestiti come guardrail privilegiati che non possono essere modificati dagli sviluppatori di API.

Organizzazioni e ambienti

Gli artefatti di configurazione, gli utenti e le funzionalità di Apigee possono essere limitati a organizzazioni e/o ambienti specifici. Ciò significa che la piattaforma dispone di misure di salvaguardia predefinite che possono essere posizionate intorno alle API e alla relativa configurazione di supporto.

Organizzazioni: Un'organizzazione è il tenant di primo livello in Apigee. Consente la completa separazione di traffico, configurazione e utenti. Come best practice di governance, ti consigliamo di avere organizzazioni di produzione e non di produzione separate. Questa pratica evita efficacemente di mescolare dati di produzione, utenti e traffico con ambienti di livello inferiore.

Ambienti: Le API in Apigee possono essere promosse in più stati di deployment; ogni stato è collegato a un contesto di esecuzione. Il contesto dell'ambiente non viene trasferito durante il processo di promozione, evitando così di esporre la configurazione sensibile a utenti senza privilegi.

Revisioni: Le revisioni consentono di promuovere API e singole funzionalità senza problemi negli ambienti.

Controllo dell'accesso basato sui ruoli

Per mitigare API9, è fondamentale avere definizioni chiare e una separazione dei compiti tra le parti interessate alla sicurezza e gli sviluppatori di API. Come indicato in precedenza in questo documento, Apigee dispone di funzionalità di controllo dell'accesso basato sui ruoli flessibili che consentono di assegnare autorizzazioni a ruoli personalizzati. Per questa minaccia specifica, i ruoli possono essere limitati per avere privilegi limitati per organizzazione, ambienti o autorizzazioni di configurazione più granulari. Come prassi consigliata, valuta la possibilità di limitare i privilegi per modificare lo stato di deployment delle API tramite gli ambienti e assicurati che gli sviluppatori non possano accedere o modificare le librerie di sicurezza globali (hook di flusso). Questi ruoli limitati impediranno modifiche non richieste alle policy di sicurezza globali che hanno un'ampia copertura sia sugli endpoint legacy sia su quelli pubblicati correnti.

Gestione dei segmenti di pubblico per la documentazione dell'API

Un portale per sviluppatori è un componente fondamentale per il successo della tua strategia API. Ti consente di mantenere un inventario completo di tutta la documentazione relativa alle tue API, inclusi host/endpoint, risorse, operazioni, schemi di payload e altro ancora. In Apigee puoi raggruppare le tue API utilizzando i costrutti dei prodotti API. I prodotti API sono definiti da bundle di risorse e operazioni che rientrano nello stesso contesto aziendale e di sicurezza (ad es. piano di servizio, dominio aziendale, categoria, gerarchia aziendale e così via).

Con il portale per sviluppatori integrato di Apigee puoi pubblicare prodotti API e limitare la visibilità dei contenuti pubblicati gestendo i segmenti di pubblico di destinazione. Questa funzionalità è conforme a una strategia di segmentazione dei contenuti che è in linea con i requisiti aziendali e di sicurezza.

Flow Hooks

Le procedure di promozione e rilascio delle API devono sempre includere procedure di conformità e certificazione della sicurezza. Per essere efficaci, i team API che utilizzano gli strumenti appropriati devono essere in grado di creare guardrail che garantiscano la separazione delle responsabilità e mantengano cicli di rilascio agili.

Apigee ti consente di elevare i compiti di governance della sicurezza applicando criteri globali tramite gli hook di flusso. Queste norme globali possono essere gestite come guardrail privilegiati che non possono essere modificati dagli sviluppatori di API, garantendo così la separazione delle responsabilità e promuovendo anche l'agilità applicando la sicurezza predefinita e, per estensione, fornendo la conformità alla sicurezza per tutte le API di cui è stato eseguito il deployment in un determinato ambiente di esecuzione.

Figura: le barriere di protezione privilegiate possono essere configurate in Apigee tramite Flow Hooks e flussi condivisi. Le parti interessate alla sicurezza sono responsabili della manutenzione delle policy globali correlate alla sicurezza. Queste funzionalità garantiscono la separazione delle responsabilità e promuovono cicli di vita di sviluppo agili.

API10:2019 Insufficient logging & monitoring

Descrizione minaccia

Logging, monitoraggio e avvisi insufficienti consentono agli attacchi in corso di passare inosservati e pertanto è necessaria una strategia per ottenere informazioni sugli eventi critici che hanno un impatto sulla tua attività.

Le strategie di gestione di eventi e logging per le API devono tenere conto delle seguenti best practice:

  • Norme di gestione dei log: documenta e applica regole per standardizzare e controllare la verbosità dei log, i livelli dei log, l'integrità dei log, il repository centralizzato e altro ancora
  • Policy di gestione degli eventi: garantisce che ogni evento sia riconducibile alla sua origine. Inoltre, gli eventi devono poter essere classificati in base alla criticità e all'impatto sull'attività.
  • Report e audit: gli stakeholder della sicurezza e delle operazioni devono essere in grado di accedere e reagire a log ed eventi in tempo reale. Inoltre, i cicli di rafforzamento possono essere eseguiti dagli stakeholder per modificare i pattern di rilevamento in base ai dati storici

Apigee fornisce gli strumenti necessari per creare una strategia completa di gestione di eventi e logging. Gli strumenti includono:

Norme di logging dei messaggi: crea flussi di log in base ai dati sul traffico o ai metadati del traffico API. Puoi decidere la verbosità del flusso sfruttando la logica condizionale e i modelli di messaggio.

Suite operativa di Google Cloud: sfrutta l'integrazione predefinita in strumenti di monitoraggio e logging altamente scalabili di Google.

Norme sui callout del servizio: aggiunge il supporto per i flussi di log che richiedono endpoint HTTP per l'invio di eventi.

Analytics: Accedi ai metadati storici sul traffico e analizzali tramite report predefiniti e/o personalizzati. Crea e gestisci avvisi basati sulle tendenze e comprendi le anomalie del traffico.

Monitoraggio delle API: come descritto in precedenza, questo strumento fornisce funzionalità di avviso che possono essere attivate in base a eventi critici. I log del traffico possono essere ulteriormente analizzati e utilizzati.