Le 10 principali minacce API di OWASP

Stai visualizzando la documentazione di Apigee Edge.
Vai alla 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 per le vulnerabilità OWASP Top 10 2021 su Google Cloud.

Introduzione

OWASP è una community aperta dedicata ad aiutare le organizzazioni a sviluppare, acquistare e gestire API e applicazioni attendibili. 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 affrontarli.

Questo documento illustra gli approcci per proteggersi dagli attacchi basati su API più comuni, come identificati dalla Top Ten delle minacce alla sicurezza delle API del 2019 di OWASP. Un tema comune tra le principali minacce evidenziate dall'elenco più recente è causato dal posizionamento improprio dei controlli di autenticazione e autorizzazione, ad esempio l'affidamento al filtro dei dati restituiti da una richiesta API all'interno delle app client, utilizzando l'anti-pattern di affidamento all'app client di destinazione per eseguire l'applicazione del controllo dell'accesso.

Con la crescita dell'ecosistema delle API che continua a un ritmo rapido, gli abusi e gli usi impropri delle API che comportano la esfiltrazione dei dati da parte degli utenti malintenzionati 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 generazione di report sulla sicurezza e di rilevamento delle anomalie. Tuttavia, è fondamentale progettare e implementare correttamente le funzionalità di sicurezza di Apigee per ridurre la probabilità di attacchi riusciti alle tue API.

Le applicazioni per consumatori devono essere considerate non attendibili o "pubbliche", in quanto non controlli la piattaforma su cui è in esecuzione l'app. Supponiamo che qualsiasi app pubblica possa e debba essere compromessa, pertanto non è possibile fare affidamento su di esse per applicare il controllo dell'accesso (API1, API5), filtrare i dati di risposta (API6) o archiviare in sicurezza i secret client (API2), come le chiavi API o i token di accesso. Ecco alcuni consigli che emergono dall'esame della Top 10 di OWASP 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. Per eseguire questa operazione, non fare mai affidamento sulla logica del codice dell'app a valle.
  • Filtra tutte le richieste di dati contenenti PII specifiche dell'utente in modo da consentire solo i dati del tuo backend appartenenti all'utente che effettua la richiesta.

API1:2019 Autorizzazione a livello di oggetto non funzionante

Descrizione minaccia

La convalida dell'autorizzazione insufficiente di una richiesta di accesso all'oggetto consente a un malintenzionato di eseguire un'azione non autorizzata riutilizzando un token di accesso. Questa minaccia è causata da una configurazione scorretta delle convalide di autorizzazione. Apigee fornisce criteri VerifyApiKey, OAuth e token JWT (JSON Web Token) che aiutano a proteggerti 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 delle applicazioni e di sicurezza collaborino strettamente. L'autorizzazione è per sua natura un argomento complesso e un'autorizzazione granulare efficace richiede una conoscenza approfondita della logica di business dell'applicazione.

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

  • 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 di uso comune.

I criteri di verifica dei token di accesso Apigee includono:

Applicazione del controllo dell'accesso

Una volta verificata la validità del token di accesso, è fondamentale implementare i criteri 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:

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

L'approccio interno (illustrato nella figura sopra) è consigliato quando il modello di controllo degli accessi è relativamente semplice. Ad esempio, se i claim estratti da un token di accesso possono essere utilizzati per valutare e autorizzare direttamente una richiesta di oggetto API.

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

L'approccio delegato (illustrato nella figura sopra) è consigliato quando i claim estratti da un token di accesso non possono essere utilizzati 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 il criterio di callout del servizio, è possibile richiedere una decisione relativa ai criteri di autorizzazione da un servizio di terze parti o ottenere ulteriori informazioni sul reclamo relative all'agente che effettua la richiesta per poi prendere una decisione di controllo dell'accesso utilizzando un flusso condizionale

API2:2019 Autenticazione utente non funzionante

Descrizione minaccia

I criteri di autenticazione utente implementati male consentono agli attaccanti di rubare l'identità di utenti legittimi sfruttando i difetti di implementazione delle implementazioni di autenticazione. Ecco alcuni principi di autenticazione da tenere presenti quando si implementano approcci di autenticazione:

  • Autentica sempre sia l'agente utente (l'app) sia l'utente che effettua la richiesta
  • Utilizza pattern di autenticazione e autorizzazione delegati ed evita di trasmettere 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 impiegate abbiano una data di scadenza definita
  • Previeni gli attacchi di forza bruta impostando quote e utilizzando Apigee Sense per rilevare e rispondere agli attacchi di forza bruta basati su bot

In un paradigma dall'esterno verso l'interno, il design 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 per la progettazione di API per i consumatori esterni. I sistemi di backend non sono tradizionalmente progettati con implementazioni di autenticazione sufficientemente efficaci per l'esposizione alle reti pubbliche. È qui che Apigee, insieme a una soluzione di gestione delle identità e dell'accesso, può offrire soluzioni efficaci per proteggerti da questa minaccia.

Esistono alcuni elementi principali da considerare, che verranno affrontati nelle sezioni successive:

  • Design per la sicurezza: sfrutta al meglio le funzionalità di Apigee per implementare modelli di autenticazione
  • Governance: garantire che l'uso corretto dei pattern di autenticazione progettati sia utilizzato in modo coerente in tutti i prodotti API pubblicati
  • Sicurezza operativa: essere in grado di rilevare comportamenti sospetti o anomali e tentativi di aggirare o attaccare con forza bruta i proxy API autenticati

Progettazione di sicurezza

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

Le RFC OpenID Connect e OAuth forniscono un numero elevato 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 non funzionante sia una delle principali minacce alle API OWASP. Fornire un'introduzione completa all'implementazione corretta degli standard di identità non rientra nell'ambito di questo documento, ma Apigee offre molte risorse aggiuntive per comprendere meglio i flussi OAuth, come questo ebook, questo webcast e questo esempio di implementazione.

Criteri di autenticazione

I criteri 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 proteggersi dagli attacchi di forza bruta:

  • Il criterio Spike Arrest per impostare un limite di frequenza medio mobile complessivo su un proxy API
  • Criteri di quota per impostare limiti di frequenza granulari per i proxy API in base alle quote definite dalle chiavi app, dagli sviluppatori o dalle quote dei prodotti API
  • Criteri di memorizzazione nella cache per memorizzare nella cache i token di accesso archiviati in base alle relative scadenze definite, nonché la possibilità di invalidate le credenziali memorizzate nella cache (ad esempio in una situazione in cui un token di accesso valido è compromesso)

Governance

La sicurezza è un processo continuo, non un progetto "imposta e dimenticato", e una delle principali cause di violazioni della sicurezza è la configurazione errata. Una volta definiti i flussi di autenticazione, i pattern di integrazione dell'identità e i criteri di gestione del traffico relativi all'autenticazione, è 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 errata.

Controllo dell'accesso basato sui ruoli (RBAC)

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

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

Flussi condivisi

I flussi condivisi ti 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ù schemi di progettazione dell'autenticazione in base al tipo di app che utilizza un'API. Uno sviluppatore API non deve essere un esperto di identità per riutilizzarlo, deve semplicemente conoscere il flusso condiviso corretto da aggiungere alla configurazione del proxy API esistente utilizzando il criterio Callout flusso.

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

Report sulla sicurezza

Dopo aver verificato che solo le persone giuste della tua organizzazione possano modificare i pattern di autenticazione e aver definito i flussi di autenticazione condivisi, devi assicurarti che i proxy API sviluppati dai tuoi team API utilizzino questi pattern di autenticazione in modo coerente.

La nuova funzionalità Advanced API Ops di Apigee include report di sicurezza avanzati, che consentono ai team di operazioni e sicurezza di visualizzare facilmente i report su tutti i proxy API e si concentrano sul rispetto dei criteri di sicurezza, come l'utilizzo di flussi condivisi. I report, i log e gli avvisi sono un elemento chiave della sicurezza delle API, che verrà discusso più dettagliatamente in API10: logging insufficiente, ma dal punto di vista della prevenzione dei rischi di autenticazione non funzionante, sono estremamente utili per garantire l'adesione agli standard di autenticazione definiti implementati come flussi condivisi.

Sicurezza operativa

Una volta che le API sono in produzione e utilizzano i pattern di autenticazione corretti con la gestione del traffico di riferimento, il team di SecOps deve anche essere in grado di monitorare e rispondere alle attività sospette, che spesso iniziano con tentativi di compromettere le credenziali di autenticazione.

Apigee Sense

Apigee Sense protegge le tue API dal traffico di richieste indesiderate, inclusi gli attacchi di client malintenzionati. Apigee Sense analizza il traffico delle richieste API, identificando i pattern che potrebbero rappresentare richieste indesiderate. Grazie a questa analisi, puoi identificare i client che inviano richieste indesiderate e intervenire per consentire, bloccare o segnalare 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 automatico che si fonde con il comportamento umano
  • Tentativi persistenti dallo stesso IP
  • Tasso di errori insolito
  • Richieste client sospette
  • Scansione dei dati
  • Attacchi di forza bruta per il furto di chiavi e l'autenticazione
  • Picchi di attività
  • Modelli geografici

Operazioni API avanzate

Sebbene Sense sia stato progettato specificamente per rilevare e rispondere alle 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 (IA) e machine learning (ML) ai dati storici delle API. Il rilevamento delle anomalie può quindi inviare avvisi in tempo reale per scenari a cui non avevi nemmeno pensato per migliorare la produttività e ridurre il tempo medio di risoluzione (MTTR) dei problemi relativi alle API.

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

  • Avvisi sul traffico totali. Genera un avviso quando il traffico cambia in base a una percentuale specificata in un intervallo di tempo. Ad esempio, puoi generare un avviso quando il traffico aumenta del 5% o più per un'ora o diminuisce del 10% o più per una settimana
  • Avvisi di anomalie. Edge rileva i problemi di traffico e prestazioni, in modo da non doverli predeterminare autonomamente. 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, contando sull'app client per eseguire il filtering necessario. Se un malintenzionato esegue query direttamente sull'API sottostante, può accedere ai dati sensibili.

Uno dei principi di progettazione "dall'esterno verso l'interno" di Apigee per la progettazione di API è la parsimonia con i dati. Collabora con i designer UX e gli sviluppatori per esporre tramite API solo i dati necessari all'interno dell'interfaccia utente dell'app. I sistemi di backend non sono stati progettati per i pattern di utilizzo pubblico, pertanto una delle prime attività del design 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, fare affidamento su un'app per filtrare i dati forniti da un'API comporta la necessità di eseguire il porting della logica di filtro 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 alcun controllo. Abbiamo già esaminato in API1 e API2 l'importanza di implementare correttamente l'autenticazione e l'autorizzazione per evitare l'accesso non autorizzato ai dati.

Le sezioni seguenti illustrano come:

  • Riscrivere le richieste e le risposte ai servizi di backend per ridurre al minimo l'esposizione dei dati
  • Implementa la gestione degli errori per impedire che i messaggi di errore dettagliati espongano agli utenti malintenzionati informazioni sensibili sull'ambiente dei tuoi servizi di backend

Riscrivere risposte e richieste

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

A tal fine, Apigee utilizza tre criteri chiave:

  • Assegna messaggio
  • Callout di codice
  • Gestione degli errori

Assegna criterio messaggio

Il criterio Assegna messaggio modifica o crea nuovi messaggi di richiesta e risposta durante il flusso del proxy API. Le norme ti consentono di eseguire le seguenti azioni sui messaggi:

  • Aggiungere nuovi parametri di modulo, intestazioni o parametri di query a un messaggio
  • Copia le proprietà esistenti da un messaggio all'altro
  • Rimuovi intestazioni, parametri di query, parametri di 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 un target alternativo, come descritto in Creare messaggi di richiesta personalizzati.

Riscrivitura complessa con codice personalizzato

Per regole di gestione e riscrittura dei dati complesse la cui complessità supera le capacità del criterio Assegna messaggio, puoi utilizzare linguaggi procedurali come JavaScript, Java o Python. Puoi aggiungere codice personalizzato a un proxy API e poi chiamarlo dai criteri aggiunti 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 richieste e risposte.

Con il codice procedurale puoi:

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

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

Gestione degli errori

Apigee ti consente di eseguire la gestione delle eccezioni personalizzate utilizzando un criterio di tipo Raise Fault. Il criterio Rileva errore, che è una variante del criterio Assegna messaggio, consente di generare una risposta di errore personalizzata in risposta a una condizione di errore.

Flussi condivisi

I flussi condivisi possono essere utilizzati per applicare la standardizzazione dei messaggi di errore. Ad esempio, gli stessi criteri configurati che rilevano un codice di errore HTTP specifico dal backend possono essere utilizzati per riscrivere la risposta di errore in modo da restituire un messaggio di errore generico.

API4:2019 Mancanza di risorse e limitazione di frequenza

Descrizione minaccia

Se non vengono implementati criteri di limitazione della frequenza, gli aggressori possono sopraffare il backend con attacchi di tipo denial-of-service.

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

  • Criteri di quote e arresto picchi come controlli preventivi per applicare 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 per le API come controlli di rilevamento per ricevere avvisi su attacchi DDoS in corso

Limitazione di frequenza con quote e criteri di arresto picco

Apigee fornisce due criteri per la limitazione di frequenza:

  • Spike arrest (Arresto picco) fornisce un criterio generale, definito 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 criteri granulare per l'applicazione di criteri di quota a livello di proxy API o di prodotto API

Arresto picco

Il criterio Spike Arrest protegge dai picchi di traffico. Questo criterio limita il numero di richieste elaborate da un proxy API e inviate a un backend, proteggendo da ritardi nel rendimento e tempi di riposo, utilizzando un valore medio mobile definibile all'interno del criterio.

Quote

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

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

Questo criterio è più granulare dell'arresto picco e in genere deve essere utilizzato contemporaneamente.

Rilevamento di bot con Apigee Sense

Con Apigee Sense, puoi intervenire per consentire, bloccare o segnalare esplicitamente le richieste provenienti da client, intervalli IP o organizzazioni di sistemi autonomi specifici in base a client o località che presentano comportamenti dannosi o sospetti. Apigee Edge applica queste azioni alle richieste prima che i proxy API le elaborino. Ad esempio, è possibile rilevare un intervallo IP o un client specifico che presenta un comportamento di "attacco di forza bruta", quindi bloccarlo o segnalarlo.

Rilevamento delle minacce con il monitoraggio di Advanced API Ops

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

API5:2019 Autorizzazione a livello di funzione non funzionante

Descrizione minaccia

Questa minaccia è una variante dell'API1 ed è anche una vulnerabilità di autorizzazione. Con questa minaccia, un malintenzionato è in grado di eseguire azioni inviando richieste a funzioni a cui non ha l'autorizzazione di accesso. Ad esempio, un malintenzionato potrebbe essere in grado di modificare o eliminare i dati di cui ha l'autorizzazione di lettura solo se un endpoint API non convalida il verbo della richiesta HTTP, sostituendo un GET con un PUT o un DELETE. In alternativa, se non viene implementato un controllo dell'accesso sufficientemente restrittivo sul percorso URI di una 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 mette in evidenza il valore dell'utilizzo di Apigee come livello di mediazione e astrazione, in quanto molti sistemi di backend, non progettati per l'accesso pubblico, potrebbero fornire per impostazione predefinita un singolo endpoint per l'esecuzione di più funzioni di logica aziendale, incluse funzionalità amministrative ad alto rischio.

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

  • Che cosa viene protetto? Pianifica la tua strategia di prodotto API e implementa la segmentazione logica delle funzionalità quando utilizzi le best practice RESTful per progettare i percorsi e le risorse esposti dalle funzionalità di app, prodotti e proxy API di Apigee.
  • Chi accede alle risorse della tua API? Definisci i profili di alto livello e implementa i diritti di accesso predefiniti "con il minor privilegio" utilizzando alcune delle funzionalità di autenticazione e autorizzazione di Apigee, come descritto in API1 e API2.
  • In che modo vengono applicati i criteri di accesso? Utilizza flussi e errori condizionali per convalidare il percorso e il verbo dell'URL di tutte le richieste API.

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

Segmentazione logica con proxy, prodotti e app API

Apigee fornisce un toolkit altamente flessibile per abilitare 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, in grado di registrare le app che utilizzano i tuoi prodotti API. I criteri di accesso possono essere definiti a qualsiasi di questi livelli.

Tuttavia, per implementare un'autorizzazione e una segmentazione funzionale efficaci, è fondamentale definire una strategia di prodotto API. Parte di questa procedura essenziale e continua è la definizione di "chi" e "cosa" dei tuoi prodotti API, esaminando le risorse API dal punto di vista dei clienti e degli sviluppatori, per poi definire esattamente a livello di risorsa percorso e verbo HTTP quali tipi di richieste 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 claim JWT

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

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

Convalida delle richieste con flussi condizionali

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

  • Un endpoint
  • Una risorsa
  • Un verbo d'azione
  • Qualsiasi numero di attributi di richiesta aggiuntivi, ad esempio i parametri di query

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 ai claim, Apigee consente l'implementazione della logica di filtro 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 le richieste che non rientrano in queste funzionalità del prodotto Apigee:

  • Logica condizionale e criteri di generazione di errori per limitare i verbi o i percorsi delle risorse in qualsiasi passaggio di una configurazione del flusso proxy
  • Criteri di protezione dalle minacce per JSON e XML per proteggerti dagli attacchi basati sui contenuti che utilizzano payload di richieste JSON o XML con formato non corretto

API6:2019 Mass assignment

Descrizione minaccia

I dati non filtrati forniti tramite API alle app client consentono agli attaccanti di indovinare le proprietà degli oggetti tramite richieste o di utilizzare convenzioni di denominazione degli endpoint per avere indizi su dove eseguire modifiche o accedere a proprietà non autorizzate sugli oggetti dati archiviati nel backend.

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

In genere, sono coinvolti due aspetti che consentono questo tipo di minaccia:

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

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

Criterio di filtro delle specifiche OpenAPI

Il criterio 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 l'API creando una specifica OpenAPI (OAS)
  2. Implementa la logica di mediazione, sicurezza e memorizzazione nella cache necessaria per esporre in sicurezza un prodotto API dal tuo backend con Apigee
  3. Convalida le richieste in arrivo in base allo schema di dati definito nella specifica OAS, inclusi basepath, verb, request message policy e parameters.

Norme di convalida dei messaggi SOAP

Il Regolamento per la convalida dei messaggi SOAP ti consente di convalidare le richieste basate su XML convalidando un messaggio XML in base a uno schema XSD o un messaggio SOAP in base a una definizione WSDL. Inoltre, puoi utilizzare il criterio di convalida dei messaggi per confermare 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 solo elemento principale
  • I contenuti non contengono caratteri non ammessi
  • Gli oggetti e i tag sono nidificati correttamente
  • Corrispondenza dei tag di inizio e di fine

API7:2019 Security misconfiguration

Descrizione minaccia

La configurazione errata della sicurezza è in genere il risultato di configurazioni predefinite non sicure, configurazioni ad hoc incomplete o , archiviazione cloud aperta, intestazioni HTTP configurate in modo errato, metodi HTTP non necessari, condivisione di risorse cross-origin (CORS) permissiva e messaggi di errore dettagliati contenenti informazioni sensibili. Gli aggressori spesso cercano 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. Le configurazioni errate della sicurezza possono non solo esporre dati utente sensibili, ma anche dettagli di sistema che possono portare alla compromissione completa del server. Inoltre, alcuni altri casi d'uso per le vulnerabilità per le configurazioni errate della sicurezza possono includere:

  • TLS configurato in modo errato
  • Messaggi di errore con tracce dello stack
  • Sistemi non sottoposti a patch
  • Riquadri di gestione dello spazio di archiviazione o del server esposti

Esistono vari passaggi che le organizzazioni possono intraprendere per risolvere e mitigare le sfide relative alle configurazioni errate della sicurezza, tra cui:

  1. Definizione e standardizzazione delle procedure di hardening e applicazione di patch
  2. Sviluppo della governance per l'ecosistema API
  3. Limitare l'accesso amministrativo e attivare il controllo 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 consente di 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 passo avanti e inserire i 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 come flusso condiviso.

Report sulla sicurezza delle API

Mentre le organizzazioni si sforzano di sviluppare un framework di governance, Apigee fornisce funzionalità per i report sulla sicurezza delle API che aiutano i team operativi a ottenere la visibilità necessaria per gli attributi di sicurezza delle API al fine di:

  • Garantire il rispetto dei criteri di sicurezza e dei requisiti di configurazione
  • Proteggere i dati sensibili da comportamenti illeciti interni ed esterni
  • Identifica, diagnostica e risolvi in modo proattivo gli incidenti di sicurezza

I report sulla sicurezza di Apigee forniscono approfondimenti approfonditi per consentire ai team operativi di garantire la conformità ai criteri e ai requisiti di configurazione, proteggere le API da abusi interni ed esterni e identificare e risolvere rapidamente gli incidenti di sicurezza.

Con i report sulla sicurezza, gli amministratori della sicurezza possono comprendere rapidamente come sono configurati i proxy API per la sicurezza, nonché le condizioni di runtime che potrebbero influire sulla sicurezza dei proxy. Utilizzando queste informazioni, puoi modificare la configurazione per assicurarti di avere il livello di sicurezza appropriato per ogni proxy.

Monitoraggio delle API

Apigee fornisce una piattaforma di monitoraggio delle API completa che integra le funzionalità di generazione di report sulla sicurezza. Il monitoraggio delle API consente alle organizzazioni di rilevare in modo proattivo i problemi di traffico e prestazioni delle API. La soluzione di monitoraggio delle API Apigee lavora in combinazione con Apigee Edge per il cloud pubblico per fornire informazioni contestuali in tempo reale sul rendimento delle API, aiuta a diagnosticare rapidamente i problemi e facilita le azioni correttive per la continuità aziendale.

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

Apigee Sense

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

Grazie a questa analisi, le organizzazioni possono identificare i client che inviano richieste indesiderate e intervenire per consentire, bloccare o segnalare queste richieste. Con Apigee Sense è possibile proteggere le API da schemi di richieste che includono:

  • Comportamento automatico che si fonde con il comportamento umano
  • Tentativi persistenti dallo stesso IP
  • Tasso di errori insolito
  • Richieste client sospette
  • Scansione dei dati
  • Raccolta di chiavi
  • Picchi di attività
  • Modelli geografici

API8:2019 Injection

Descrizione minaccia

L'iniezione di dati non attendibili, come SQL, NoSQL, analizzatori XML, ORM, LDAP, comandi OS e JavaScript, nelle richieste API può comportare l'esecuzione di comandi indesiderati o l'accesso non autorizzato ai dati. Gli attaccanti forniranno all'API dati dannosi tramite qualsiasi vettore di attacco disponibile, come input diretti, parametri, servizi integrati e così via, aspettandosi che vengano inviati a un interprete. Gli attaccanti possono scoprire facilmente questi difetti quando esaminano il codice sorgente utilizzando scanner di vulnerabilità e fuzzer. Un'iniezione riuscita può comportare la divulgazione di informazioni che influiscono sulla riservatezza e sulla perdita di dati o, in alcuni casi, può anche comportare un attacco DoS.

Le best practice per mitigare gli errori/gli attacchi di attacco di iniezione includono la definizione rigorosa dei dati di input, come schemi, tipi, pattern di stringhe, l'esecuzione della convalida dell'input, i controlli dei limiti e l'applicazione di questi controlli in fase di esecuzione. La piattaforma Apigee consente di convalidare i dati in entrata utilizzando 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 limite. 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.

Criterio di protezione delle espressioni regolari

Il criterio RegularExpressionProtection estrae le informazioni da un messaggio (ad esempio, percorso URI, parametro di query, intestazione, parametro di modulo, variabile, payload XML o payload JSON) e valuta i contenuti in base a espressioni regolari predefinite. Se una delle espressioni regolari specificate restituisce 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 contenuti in modo programmatico per rilevare pattern. 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 rilevare contenuti dannosi.

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

Esistono diversi altri approcci per convalidare gli input disponibili con la piattaforma Apigee:

Convalidare i tipi di contenuti

Il tipo di contenuto 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.

Report sulla sicurezza delle API

Mentre le organizzazioni si sforzano di sviluppare un framework di governance, Apigee fornisce funzionalità di report sulla sicurezza delle API, che aiutano e forniscono ai team operativi la visibilità necessaria per proteggere le API fornendo ai team operativi la visibilità necessaria per gli attributi di sicurezza delle API per:

  • Assicurati di rispettare i criteri di sicurezza e i requisiti di configurazione.
  • Protezione dei dati sensibili da comportamenti illeciti interni ed esterni.
  • Identificazione, diagnosi e risoluzione proattiva degli incidenti di sicurezza.

API9:2019 Gestione non corretta degli asset

Descrizione della minaccia

La gestione e la segregazione dell'ambiente insufficienti consentono agli attaccanti di accedere agli endpoint API con scarsa sicurezza. La mancanza di misure di salvaguardia della governance causa anche un'esposizione non necessaria delle risorse ritirate.

Questa minaccia può essere affrontata sfruttando le funzionalità mature di Apigee per gestire l'intero ciclo di vita delle API, in modo da creare un modello di governance completo che consenta la collaborazione tra i team e, al contempo, applichi la separazione delle responsabilità tra gli stakeholder della sicurezza e gli sviluppatori di API. I limiti e i controlli possono essere configurati e gestiti utilizzando:

Organizzazioni, ambienti e revisioni: linee guida virtuali e fisiche che garantiscono l'isolamento e un processo di promozione sicuro tramite i contesti di runtime.

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

Gestione del pubblico per la documentazione dell'API: dopo aver pubblicato 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 linee guida privilegiate che non possono essere modificate dagli sviluppatori di API.

Report sulla sicurezza: gli stakeholder della sicurezza hanno visibilità end-to-end delle API pubblicate e della relativa configurazione di supporto. La conformità alle norme di sicurezza globali può essere verificata e valutata in base al profilo di rischio di ogni endpoint API pubblicato.

Organizzazioni e ambienti

Gli elementi di configurazione, gli utenti e le funzionalità in Apigee possono essere limitati a organizzazioni e/o ambienti specifici. Ciò significa che la piattaforma dispone di guardrail predefiniti che possono essere posizionati intorno alle API e alla relativa configurazione di supporto.

Organizzazioni: un'organizzazione è l'tenant di primo livello in Apigee. Ti consente di avere una separazione completa per traffico, configurazione e utenti. Come best practice per la 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 inferiori.

Ambienti: le API in Apigee possono essere promosse attraverso più stati di implementazione; ogni stato è collegato a un contesto di esecuzione. Il contesto dell'ambiente non viene mantenuto durante la procedura di promozione, evitando così di esporre la configurazione sensibile a utenti non privilegiati.

Revisioni: le revisioni consentono di promuovere API e singole funzionalità in modo semplice tra gli ambienti.

Controllo dell'accesso basato sui ruoli

Per mitigare il rischio API9, è fondamentale avere definizioni chiare e una separazione delle responsabilità tra gli stakeholder della sicurezza e gli sviluppatori di API. Come affermato in precedenza in questo documento, Apigee dispone di funzionalità flessibili di controllo dell'accesso basato sui ruoli che ti consentono di assegnare autorizzazioni ai ruoli personalizzati. Per questa minaccia specifica, i ruoli possono essere limitati in modo da avere privilegi limitati per organizzazione, ambienti o autorizzazioni di configurazione più granulari. Come prassi preferita, ti consigliamo di limitare i privilegi per modificare lo stato di implementazione delle API tramite gli ambienti e anche per assicurarti che gli sviluppatori non possano accedere o modificare le librerie di sicurezza globali (hook di flusso). Questi ruoli limitati impediranno modifiche non richieste ai criteri di sicurezza globali che hanno una copertura ampia sia sugli endpoint precedenti che su quelli pubblicati attualmente.

Documentazione della gestione dei segmenti di pubblico per le 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 pacchetti 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 si allinea ai requisiti aziendali e di sicurezza.

Ganci per il flusso

I processi di promozione e rilascio delle API devono sempre includere procedimenti di conformità e certificazione per la sicurezza. Per essere efficaci, i team API che utilizzano gli strumenti appropriati devono essere in grado di creare linee guida che garantiscano la separazione delle responsabilità, mantenendo al contempo i cicli di rilascio agili.

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

Figura: i guardrail con privilegi possono essere configurati in Apigee tramite hook dei flussi e flussi condivisi. Gli stakeholder della sicurezza sono responsabili della gestione delle norme globali relative alla sicurezza. Queste funzionalità garantiscono la separazione delle responsabilità e promuovono i cicli di vita dello sviluppo agile.

Report sulla sicurezza

I controlli di sicurezza hanno lo scopo di valutare e testare i criteri di sicurezza volti a proteggere i dati e gli obiettivi commerciali della tua organizzazione. Le API sono interfacce pubbliche o private standardizzate che devono essere protette da un modello di governance della sicurezza completo e, al contempo, verificabile.

In Apigee hai accesso a report sulla sicurezza specializzati che contribuiscono a garantire l'adesione a criteri definiti e consentono ai tuoi team di sicurezza di intervenire in base a informazioni complete su:

Traffico runtime: una visualizzazione completa per informazioni sul traffico delle API su: server di destinazione, host virtuali, configurazione TLS, variazioni del traffico per ambiente e altro ancora.

Configurazione: funzionalità di controllo per la configurazione dei proxy API che fornisce una visibilità end-to-end su tutti i criteri applicati a livello di proxy API, nonché lo spettro di applicazione dei flussi condivisi collegati a livello di organizzazione o proxy.

Attività utente: monitora le operazioni sensibili eseguite dagli utenti della piattaforma. Analizza le attività sospette visualizzando i dettagli.

API10:2019 Monitoraggio e logging insufficienti

Descrizione della minaccia

La registrazione, il monitoraggio e gli avvisi insufficienti consentono agli attacchi in corso di non essere rilevati e quindi è necessaria una strategia per ottenere informazioni sugli eventi critici che influiscono sulla tua attività.

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

  • Criterio di gestione dei log: documenta e applica regole per standardizzare e controllare la complessità, i livelli, l'integrità, il repository centralizzato e altro ancora dei log
  • Criteri di gestione degli eventi: garantisce che ogni evento sia tracciabile alla relativa fonte. Inoltre, gli eventi devono essere classificabili in base a criticità e impatto sull'attività
  • Report e controlli: gli stakeholder della sicurezza e delle operazioni devono essere in grado di accedere e reagire a log ed eventi in tempo reale. Inoltre, gli stakeholder possono eseguire cicli di rinforzo per regolare i pattern di rilevamento in base ai dati storici.

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

Norme di logging dei messaggi: crea stream di log in base ai dati sul traffico o ai metadati del traffico della tua API. Hai la possibilità di decidere la complessità dello stream sfruttando la logica condizionale e i modelli di messaggio.

Suite operativa di Google Cloud: sfrutta l'integrazione immediata negli strumenti di monitoraggio e logging di Google, altamente scalabili.

Norme per i callout del servizio: aggiunge il supporto per gli stream di log che richiedono endpoint HTTP per inviare gli eventi.

Analytics: accedi e analizza i metadati del traffico storico tramite report predefiniti e/o personalizzati. Crea e gestisci gli avvisi in base alle 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 analizzati ulteriormente e sottoposti ad azioni.