Le 10 principali minacce Web OWASP

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

Questo documento descrive i vari approcci che puoi utilizzare all'interno di Apigee per risolvere le vulnerabilità di sicurezza identificate da OWASP. Per ulteriori approcci documentati per Apigee, consulta OWASP Top 10 2021 mitigation options on Google Cloud.

Panoramica

Gli ecosistemi API subiscono vari attacchi da parte di client esterni e interni. L'offerta e l'utilizzo delle API crea enormi opportunità per i provider di servizi, ma comporta anche alcuni rischi per la sicurezza. Gli sviluppatori devono essere consapevoli di queste sfide e affrontarle quando creano e utilizzano le API.

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

Con Apigee, il livello proxy API può rilevare, bloccare e segnalare richieste API non formattate dal client prima che vengano elaborate nei sistemi di backend, riducendo così i rischi e proteggendo i servizi. Le richieste in formato non valido possono includere qualsiasi componente che costituisce il protocollo a livello di applicazione HTTP:

  • URL
  • Intestazioni
  • Percorso
  • Payload

Le richieste API errate possono provenire da client noti o sconosciuti sviluppati da sviluppatori esterni, interni o bot dannosi. Questi tipi di richieste costituiscono la maggior parte delle minacce OWASP, ma esistono componenti aggiuntivi del livello proxy API sottostante che possono mitigare i rischi, come il mascheramento dei dati, il logging, l'amministrazione e così via.

La piattaforma di gestione intelligente delle API di Apigee ti consente di risolvere senza problemi le principali vulnerabilità di sicurezza delle API OWASP, adottando un approccio incentrato sul consumo per la progettazione delle tue API e la loro connessione ai tuoi sistemi di backend. Di seguito è riportato un elenco di criteri/configurazione consigliati da Apigee per le principali minacce REST OWASP.

Soluzioni Apigee per OWASP Top 10 2017

Quando si tratta di creare e proteggere le applicazioni web, sono presenti molti problemi di sicurezza. OWASP ha pubblicato l'elenco delle 10 principali minacce alla sicurezza OWASP del 2017 per le applicazioni web. Un'applicazione web è composta da molte parti, ma la maggior parte delle app web moderne si basa in larga misura sulle API REST. Apigee non è pensato per gestire tutte le esigenze di sicurezza di un'applicazione web, ma può svolgere un ruolo fondamentale nella protezione delle API REST. Di seguito sono riportate le principali minacce alla sicurezza OWASP con descrizioni di come potresti utilizzare Apigee per contribuire a risolvere queste minacce.

A1:2017 - Iniezione

Per garantire protezione dall'inserimento di dati non attendibili come SQL, NoSQL, LDAP e JavaScript, che può comportare l'esecuzione di comandi non intenzionali o l'accesso non autorizzato ai dati, Apigee offre diversi criteri di convalida dell'input per verificare che i valori forniti da un client corrispondano alle aspettative prima di consentire ulteriori elaborazioni. Apigee Edge, agendo come 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 in modo da rimuovere sequenze di caratteri rischiose e sostituirle con valori sicuri.

Esistono diversi approcci per convalidare l'input con la piattaforma Apigee:

Convalida dei tipi di contenuti:

A2:2017 - Autenticazione inaccessibile e gestione delle sessioni

Gli utenti malintenzionati possono accedere a password, token di sessione e chiavi per rubare l'identità di altri utenti sfruttando i difetti di implementazione nelle applicazioni. Si tratta più di un problema di implementazione che di un problema relativo al prodotto. Apigee fornisce i criteri VerificationApiKey, OAuth e JSON Web Token (JWT), che aiutano a proteggere da questa vulnerabilità.

Convalida delle chiavi API

La convalida delle chiavi API è la forma più semplice di sicurezza basata su app che può essere configurata per un'API. Un'app client presenta semplicemente una chiave API con la sua richiesta, quindi Apigee Edge, tramite un criterio associato a un proxy API, controlla che la chiave API sia in stato approvato per la risorsa richiesta.

Apigee fornisce assistenza per la generazione e la convalida delle chiavi API. Apigee genera una chiave API e un secret quando viene creata e approvata un'app dello sviluppatore collegata a uno o più prodotti API.

Il termine "chiavi API" può avere significati diversi. In Apigee, quando si crea la relazione tra app e prodotto, Apigee genera un ID client e un client secret. Alcuni fanno riferimento sia all'ID sia al secret come chiave API. Alcuni fanno riferimento solo all'ID client come chiave API. Nella UI di Edge, vedrai "chiave utente" e "segreto utente".

Nel criterio di VerificationAPIKey viene verificato solo l'ID client o la "chiave utente". Gli sviluppatori ricevono una chiave utente quando registrano la propria app con Apigee e associano l'app a un prodotto API. Gli sviluppatori includono la chiave utente nelle chiamate effettuate dall'app ai proxy API integrati nel prodotto API.

Apigee supporta anche la possibilità di importare chiavi API esistenti da origini esterne.

Per i tipi di autorizzazione con OAuth, vengono utilizzati sia l'ID client sia il secret.

OAuth 2.0

Il framework di autorizzazione OAuth 2.0 consente a un'applicazione di terze parti di ottenere l'accesso limitato a un servizio HTTP per conto del proprietario della risorsa orchestrando un'interazione di approvazione tra il proprietario della risorsa e il servizio HTTP o consentendo all'applicazione di terze parti di ottenere l'accesso per suo conto.

I criteri OAuth 2.0 di Apigee consentono di implementare e personalizzare i quattro tipi di autorizzazione OAuth 2.0. L'applicazione forzata del token di accesso OAuth può essere eseguita utilizzando il criterio OAuthv2. Il consumer deve essere registrato e avere un'app approvata che gli abbia concesso l'accesso all'API. In cambio, riceveranno un ID client API e un client secret. Per autenticarsi, il consumatore deve passare attraverso una delle concessioni OAuth, che gli concede un token di accesso opaco. Questo token può essere utilizzato per controllare l'accesso all'API.

JWT

I token web JSON, o JWT, vengono comunemente utilizzati per condividere attestazioni o asserzioni tra applicazioni collegate. Apigee fornisce il supporto JWT utilizzando tre criteri.

  • Genera token JWT (supporta la firma HS256 e RS256)
  • Convalida token JWT
  • Decodificare i token JWT senza convalidarli

A3:2017 - Esposizione di dati sensibili

Gli utenti malintenzionati prendono di mira dati sensibili come i dettagli della carta di credito, il codice fiscale, le credenziali di accesso, le informazioni che consentono l'identificazione personale (PII) e gli ID fiscali per commettere furti di identità, furti di denaro, attività fraudolente e altri reati. Le applicazioni web devono implementare la crittografia, sia quando sono inattivi sia in transito, e altre strategie per garantire la protezione dei dati sensibili.

TLS (Transport Layer Security, il cui predecessore è SSL) è la tecnologia di sicurezza standard per stabilire un collegamento criptato tra un server web e un client web, come un browser o un'app. Apigee supporta TLS unidirezionale e bidirezionale.

Il protocollo TLS (client che si connette al nord) (client che si connette all'API che agisce come server) è supportato tramite l'utilizzo di una configurazione dell'host virtuale. Un host virtuale può essere configurato per TLS unidirezionale o bidirezionale.

Il protocollo TLS diretto a sud (Apigee come client che si connette al servizio di backend) è supportato tramite l'utilizzo di una configurazione di un server di destinazione. Un server di destinazione può essere configurato per TLS unidirezionale o bidirezionale.

Apigee supporta molte opzioni di configurazione TLS.

L'applicazione del TLS a due vie assicura che il client utilizzi un certificato già inserito in Apigee. OWASP fornisce anche best practice per TLS.

In Apigee hybrid, TLS è disponibile in entrata tramite un alias host, che è un concetto simile a un host virtuale.

Di seguito sono riportate le linee guida per proteggere i dati sensibili:

  • Usare una piattaforma che supporta TLS unidirezionale e bidirezionale, che protegge a livello di protocollo.
  • Utilizza criteri come i criteri AttributionMessage e i criteri JavaScript per rimuovere i dati sensibili prima che vengano restituiti al client.
  • Utilizza le tecniche OAuth standard e valuta la possibilità di aggiungere HMAC, hash, stato, nonce, PKCE o altre tecniche per migliorare il livello di autenticazione per ogni richiesta.
  • Utilizza le impostazioni di mascheramento dei dati per mascherare i dati sensibili nello strumento Edge Trace.
  • Presta attenzione all'archiviazione di tutti i dati sensibili nella cache (o cripta i dati sensibili archiviati nella cache). In Edge, puoi criptare i dati sensibili at-rest nelle mappe chiave-valore.

A4:2017 - Entità esterne XML

I sistemi o le applicazioni che elaborano il linguaggio XML devono gestire i "riferimenti di entità esterne" in XML, ovvero i riferimenti a file o dati che vengono sostituiti con i dati effettivi durante l'elaborazione XML. Se le applicazioni o i processori XML sono obsoleti o implementati male, gli utenti malintenzionati possono compromettere i dati e utilizzarli per rubare informazioni o lanciare vari tipi di attacchi al sistema, ad esempio il denial of service.

Il criterio ExtractVariables di Apigee ti consente di estrarre i contenuti da una richiesta o risposta e assegnarli a una variabile. Puoi estrarre qualsiasi parte del messaggio, tra cui intestazioni, percorsi URI, payload JSON/XML, parametri del modulo e parametri di query. Il criterio funziona applicando un pattern di testo ai contenuti del messaggio e, dopo aver trovato una corrispondenza, impostando una variabile con i contenuti del messaggio specificati.

Apigee dispone di un parser XML integrato nella piattaforma che utilizza XPath per estrarre i dati. Inoltre, ha un criterio XMLThreatProtection per proteggere da payload XML dannosi.

A5:2017 - Controllo dell'accesso inaccessibile

Dopo che gli utenti effettuano l'accesso e hanno ottenuto l'accesso a un sistema, devono essere implementati adeguati controlli di autorizzazione in modo che gli utenti possano vedere e fare solo ciò che sono autorizzati a fare. Senza controlli dell'accesso efficaci, i malintenzionati possono visualizzare dati non autorizzati e spesso sensibili o manipolare male i dati e il comportamento del sistema.

Apigee supporta un approccio a più livelli per implementare i controlli dell'accesso in modo da impedire ai malintenzionati di apportare modifiche non autorizzate o di accedere al sistema.

Controlli di accesso per l'UI Edge

Controlli di accesso per il portale per gli sviluppatori Apigee

  • Configura il Single Sign-On con il provider di identità della tua azienda.
  • Configura il controllo dell'accesso basato sui ruoli (RBAC) per consentire agli utenti di accedere solo alla funzionalità e alla configurazione di cui hanno bisogno sui portali per gli sviluppatori basati su Drupal.
  • Configura i portali per gli sviluppatori per mostrare prodotti API specifici in base al ruolo utente.
  • Configura il portale per mostrare o nascondere contenuti in base al ruolo utente.

Controlli dell'accesso per l'accesso all'API di runtime Apigee

  • L'accesso alle API può essere applicato tramite chiavi API, token OAuth, ambiti OAuth, certificati e altre tecniche.
  • Il provider di API configura le risorse disponibili definendo un prodotto API. L'accesso viene concesso manualmente nell'interfaccia utente, tramite l'API di gestione o tramite il portale per gli sviluppatori. Quando all'app di uno sviluppatore viene concesso l'accesso a un prodotto API, riceve un ID client e un secret utilizzati nel processo di autenticazione.
  • Apigee può integrarsi con qualsiasi provider di identità per eseguire OAuth.
  • Apigee può generare token JWT o altre tecniche per inviare l'identità utente ai servizi di destinazione. I servizi di destinazione possono utilizzare questa identità per limitare l'accesso a servizi e dati in base alle esigenze.

A6:2017-Errori di configurazione della sicurezza

Gli errori di configurazione della sicurezza sono facili da ignorare, spesso perché amministratori e sviluppatori confidano erroneamente che i sistemi che utilizzano siano intrinsecamente sicuri. La configurazione errata della sicurezza può verificarsi in molti modi diversi, ad esempio utilizzando l'attendibilità delle configurazioni predefinite o la creazione di configurazioni parziali che potrebbero non essere sicure, permettendo che i messaggi di errore contengano dettagli sensibili, l'archiviazione dei dati nel cloud senza controlli di sicurezza adeguati, la configurazione errata delle intestazioni HTTP e così via. La piattaforma Apigee fornisce una serie di meccanismi per consentirti di controllare, gestire e monitorare le configurazioni di sicurezza, tra cui i flussi condivisi riutilizzabili.

Un flusso condiviso 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 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 in più e inserire flussi condivisi in hook di flusso per eseguire automaticamente la logica di flusso condiviso per ogni proxy API di cui è stato eseguito il deployment nello stesso ambiente di un flusso condiviso.

Le release dei prodotti Apigee assicurano la protezione contro librerie con vulnerabilità. Apigee potrebbe rilasciare patch o aggiornamenti aggiuntivi se vengono rilevate nuove vulnerabilità. Al cloud pubblico perimetrale viene applicata automaticamente la patch. I clienti di Edge per Cloud privato (on-premise) devono applicare autonomamente le patch del prodotto.

A7:2017-Cross-Site Scripting (XSS)

Il cross-site scripting (XSS) consente ai malintenzionati di eseguire script nei browser web degli utenti per controllare le sessioni utente, manipolare i siti web o influire in modo dannoso sugli utenti in altri modi. I problemi XSS non sono necessariamente correlati alle API, ma Apigee offre criteri di protezione dalle minacce che possono essere utilizzati per proteggersi dagli XSS nell'API. Utilizzando espressioni regolari, con il criterio RegularExpressionProtection o il criterio JavaScript, verifica i valori dei payload e dei parametri per individuare eventuali attacchi relativi a JavaScript e altri attacchi di tipo injection.

CORS, una delle soluzioni comunemente implementate per il criterio della stessa origine applicato da tutti i browser, può essere implementato utilizzando il criterioAssignMessage.

A8:2017 - Deserializzazione non sicura

Gli aggressori possono utilizzare i difetti nella deserializzazione per diversi tipi di attacchi, come riproduzioni, escalation dei privilegi e iniezione. La deserializzazione non sicura può anche consentire l'esecuzione di codice remoto.

Apigee non consiglia la deserializzazione. Tuttavia, il criterio JSONThreatProtection e il criterio RegularExpressionProtection possono contribuire a proteggerti da payload JSON dannosi. Le norme JavaScript possono essere utilizzate anche per analizzare i payload alla ricerca di contenuti dannosi. La cache e altri criteri possono essere usati per proteggerti dagli attacchi di ripetizione. A livello di infrastruttura, la piattaforma Apigee dispone inoltre di sistemi di protezione integrati per proteggere i processi in esecuzione.

A9:2017 - Utilizzo di componenti con vulnerabilità note

Poiché framework, librerie e moduli vengono eseguiti con esecuzione completa e accesso CRUD, i malintenzionati possono sfruttare le vulnerabilità dei componenti per attaccare i sistemi.

Le release regolari dei prodotti Apigee assicurano protezione contro le vulnerabilità dei componenti, soprattutto quando vengono rilevate vulnerabilità specifiche. Al cloud pubblico di Apigee vengono applicate automaticamente le patch e Apigee notifica Edge per i clienti del cloud privato quando le patch on-premise sono disponibili per l'installazione.

A10:2017 - Logging e monitoraggio insufficienti

Se non esegui in modo adeguato il logging, il monitoraggio e la gestione degli incidenti nei tuoi sistemi, i malintenzionati possono eseguire attacchi più profondi e prolungati ai dati e al software.

Apigee offre diversi modi per eseguire logging, monitoraggio, gestione degli errori e audit logging.

Logging

  • I messaggi di log possono essere inviati a Splunk o altri endpoint syslog utilizzando il criterio MessageLogging.
  • I dati di analisi delle API possono essere estratti tramite l'API Analytics e importati o esportati in altri sistemi.
  • In Edge per cloud privato, puoi utilizzare il criterio MessageLogging per scrivere nei file di log locali. Sono disponibili anche i file di log da ciascuno dei componenti in esecuzione.
  • Il criterio JavaScript può essere utilizzato per inviare messaggi di log a un endpoint di logging REST in modo sincrono o asincrono.

Monitoraggio

  • Utilizza la UI o l'API di monitoraggio delle API per monitorare regolarmente le API e i backend e gli alet di trigger.
  • Utilizza il monitoraggio dello stato di integrità per monitorare regolarmente i backend dei server di destinazione.
  • Apigee fornisce consigli per il monitoraggio di Edge per il cloud privato.
  • Apigee fornisce anche best practice che il tuo team può sfruttare per monitorare il tuo programma API.

Gestione degli errori

Apigee offre un meccanismo di gestione dei guasti potente e versatile per i proxy API. In modo simile a come un programma Java rilevi le eccezioni, i proxy API possono rilevare gli errori e determinare come restituire le risposte appropriate ai client. La gestione degli errori personalizzata di Apigee consente di aggiungere funzionalità come il logging dei messaggi ogni volta che si verifica un errore.

Audit log

La piattaforma Apigee tiene un audit log che tiene traccia delle modifiche ai proxy API, ai prodotti e alla cronologia dell'organizzazione. Questo log è disponibile tramite l'interfaccia utente o tramite l'API Audits.

Soluzioni Apigee per le vulnerabilità OWASP del 2013

Quando OWASP ha aggiornato l'elenco per il 2017, alcune vulnerabilità di questo elenco sono state tralasciate. Sono ancora minacce valide. Le sezioni seguenti descrivono come gestire queste minacce con Apigee.

A8:2013 - Falsificazione di richieste tra siti (CSRF)

Le richieste di contraffazione tra siti consentono ai malintenzionati di inoltrare i dettagli di autenticazione, il cookie di sessione e altri dati di un utente a un'applicazione web vulnerabile tramite HTTP, inducendo con l'inganno l'applicazione web a credere che le richieste siano richieste legittime da parte dell'utente.

Linee guida:

  • Si tratta più di un problema del browser, non di un prodotto API. Puoi risolvere questa vulnerabilità con OpenID Connect, OAuth e altre tecniche.
  • Prendi in considerazione l'utilizzo di tecniche HMAC, di stato, di hash, nonce o PKCE per prevenire attacchi di falsificazione e di riproduzione.

A10:2013 - Reindirizzamenti e inoltri non convalidati

Se un'applicazione web esegue reindirizzamenti, ma non verifica che questi reindirizzino gli utenti a siti web previsti e attendibili, i malintenzionati possono indirizzare gli utenti a destinazioni dannose per svolgere attività di phishing, esecuzione di malware e altri attacchi.

Linee guida:

  • Utilizza OAuth e applica la convalida a ogni richiesta.
  • Previeni i reindirizzamenti 302 imprevisti controllando i codici di risposta nella logica del proxy API e gestendo i reindirizzamenti in modo appropriato.