Le 10 principali minacce Web 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.

Panoramica

Gli ecosistemi API subiscono vari attacchi da parte di clienti esterni e interni. Offrire e utilizzare API crea enormi opportunità per i fornitori di servizi, ma comporta anche alcuni rischi per la sicurezza. Gli sviluppatori devono essere consapevoli di queste sfide e risolverle quando creano e utilizzano le API.

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.

Con Apigee, il livello del proxy API può rilevare, bloccare e segnalare le richieste API con formato non corretto inviate dal client prima che vengano elaborate nei sistemi di backend, mitigando così il rischio e proteggendo i tuoi servizi. Le richieste con formato non valido possono includere qualsiasi componente che compone il protocollo HTTP a livello di applicazione:

  • URL
  • Intestazioni
  • Percorso
  • Payload

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

La piattaforma di gestione delle API intelligente di Apigee ti consente di risolvere facilmente le principali vulnerabilità di sicurezza delle API OWASP adottando un approccio incentrato sul consumo per progettare le API e collegarle ai sistemi di backend. Di seguito è riportato un elenco di criteri/configurazioni consigliati da Apigee per le principali minacce OWASP REST.

Soluzioni Apigee per i rischi OWASP Top 10 del 2017

Esistono molti problemi di sicurezza per quanto riguarda la creazione e la protezione delle applicazioni web. OWASP ha pubblicato il suo elenco delle 10 principali minacce alla sicurezza OWASP del 2017 per le applicazioni web.  Sebbene un'applicazione web sia composta da molti componenti, la maggior parte delle app web moderne si basa fortemente sulle API REST.  Apigee non è progettato 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 utilizzare Apigee per affrontarle.

A1:2017 - Iniezione

Per proteggerti dall'inserimento di dati non attendibili come SQL, NoSQL, LDAP e JavaScript, che può comportare l'esecuzione di comandi indesiderati o l'accesso non autorizzato ai dati, Apigee fornisce diversi criteri di convalida dell'input per verificare che i valori forniti da un client corrispondano alle aspettative prima di consentire un'ulteriore elaborazione. 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 le sequenze di caratteri rischiose e sostituirle con valori sicuri.

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

Convalida i tipi di contenuti:

A2:2017 - Gestione delle sessioni e dell'autenticazione non funzionante

Gli utenti malintenzionati possono accedere a password, token di sessione e chiavi per rubare l'identità di altri utenti sfruttando i difetti di implementazione delle applicazioni. Si tratta più di un problema di implementazione e non di un problema del prodotto.  Apigee fornisce criteri VerifyApiKey, OAuth e JSON Web Token (JWT), che aiutano a proteggersi 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 relativa richiesta, quindi Apigee Edge, tramite un criterio associato a un proxy API, controlla che la chiave API sia in uno 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 segreto quando viene creata e approvata un'app per sviluppatori collegata a uno o più prodotti API.

A volte il termine "chiavi API" può avere significati diversi. In Apigee, quando viene creato il rapporto 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. Nell'interfaccia utente di Edge, vedrai "consumer key" e "consumer secret".

Nel criterio VerifyAPIKey, viene verificato solo l'ID cliente o la "chiave consumer". Gli sviluppatori ricevono una chiave consumer quando registrano la propria app su Apigee e la associano a un prodotto API. Gli sviluppatori includono la chiave consumer nelle chiamate effettuate dall'app ai proxy API inclusi nel prodotto API.

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

Per i tipi di concessione 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 di una risorsa orchestrando un'interazione di approvazione tra il proprietario della risorsa e il servizio HTTP oppure consentendo all'applicazione di terze parti di ottenere l'accesso per proprio conto.

I criteri OAuth 2.0 di Apigee ti consentono di implementare e personalizzare i quattro tipi di concessione OAuth 2.0. L'applicazione del token di accesso OAuth può essere eseguita utilizzando i criteri OAuth 2.0. Il consumatore deve essere registrato e avere un'app approvata che gli ha concesso l'accesso all'API. In cambio, riceveranno un ID client e un client secret dell'API. Il consumatore deve eseguire una delle autorizzazioni OAuth per essere autenticato, ottenendo 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 rivendicazioni o affermazioni tra applicazioni collegate. Apigee fornisce il supporto JWT utilizzando tre criteri.

  • Token GenerateJWT (supporta la firma HS256 e RS256)
  • Token ValidateJWT
  • Decodificare i token JWT senza convalidarli

A3:2017 - Esposizione di dati sensibili

Gli aggressori prendono di mira dati sensibili come dati della carta di credito, numeri di previdenza sociale, credenziali di accesso, informazioni che consentono l'identificazione personale (PII) e documenti di identità fiscali per commettere furto d'identità, furto di denaro, attività fraudolenta e altri reati. Le applicazioni web devono implementare la crittografia, sia at-rest 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, ad esempio un browser o un'app. Apigee supporta TLS sia in un'unica direzione sia in entrambe le direzioni.

TLS in uscita (client che si connette all'API come server) è supportato tramite l'utilizzo di una configurazione Virtual Host. Un host virtuale può essere configurato per TLS unidirezionale o bidirezionale.

TLS in uscita (Apigee come client che si connette al servizio di backend) è supportato tramite l'uso di una configurazione del 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 protocollo TLS bidirezionale garantisce che il client utilizzi un certificato già eseguito in Apigee. OWASP fornisce inoltre best practice per TLS.

In Apigee Hybrid, TLS è disponibile all'ingresso tramite un alias host, un concetto simile a un host virtuale.

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

  • Utilizza una piattaforma che supporta TLS unidirezionale e bidirezionale, che fornirà protezione a livello di protocollo.
  • Utilizza criteri come Criterio AssignMessage e Criterio 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.
  • Fai attenzione a non archiviare dati sensibili nella cache (o a criptare 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 XML devono gestire i "riferimenti a 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 gli elaboratori XML sono obsoleti o implementati in modo inadeguato, i malintenzionati possono pirateria informatica i dati e utilizzarli per rubare informazioni o lanciare vari tipi di attacchi al sistema, come il denial of service.

Le norme relative a ExtractVariables di Apigee ti consentono di estrarre i contenuti da una richiesta o una risposta e assegnarli a una variabile. Puoi estrarre qualsiasi parte del messaggio, tra cui intestazioni, percorsi URI, payload JSON/XML, parametri di modulo e parametri di query. Il criterio funziona applicando un pattern di testo ai contenuti del messaggio e, quando viene trovata una corrispondenza, imposta 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, possiede un criterio XMLThreatProtection per proteggerti dai payload XML dannosi.

A5:2017 - Controllo degli accessi non funzionante

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

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

Controlli di accesso per l'interfaccia utente di 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 alle funzionalità e alla configurazione di cui hanno bisogno sui portali per sviluppatori basati su Drupal.
  • Configura i portali per sviluppatori in modo da mostrare prodotti API specifici in base al ruolo dell'utente.
  • Configura il portale in modo da mostrare o nascondere i contenuti in base al ruolo dell'utente.

Controlli di accesso per l'accesso alle API di runtime Apigee

  • L'accesso alle API può essere applicato tramite chiavi API, token OAuth, ambiti OAuth, certificati e altre tecniche.
  • Il fornitore dell'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 sviluppatori. Quando all'app di un sviluppatore viene concesso l'accesso a un prodotto API, lo sviluppatore riceve un ID cliente e un client secret che vengono utilizzati nella procedura 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 target. I servizi target possono utilizzare questa identità per limitare l'accesso a servizi e dati, se necessario.

A6:2017-Security Misconfiguration

Le configurazioni errate della sicurezza sono facili da trascurare, spesso perché amministratori e sviluppatori si affidano erroneamente al fatto che i sistemi che utilizzano siano intrinsecamente sicuri. La configurazione errata della sicurezza può verificarsi in molti modi diversi, ad esempio fidandosi delle configurazioni predefinite o effettuando configurazioni parziali che potrebbero non essere sicure, consentendo ai messaggi di errore di contenere dettagli sensibili, archiviando i dati nel cloud senza controlli di sicurezza adeguati, configurando in modo errato le intestazioni HTTP e così via. La piattaforma Apigee fornisce una serie di meccanismi per controllare, gestire e monitorare le configurazioni di sicurezza, inclusi 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 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 di un flusso condiviso.

Le release dei prodotti Apigee garantiscono la protezione dalle librerie con vulnerabilità. Apigee potrebbe rilasciare patch o aggiornamenti aggiuntivi se vengono rilevate nuove vulnerabilità. Il cloud pubblico Edge viene sottoposto a patch automaticamente. I clienti di Edge for Private Cloud (on-premise) devono applicare autonomamente le patch dei prodotti.

A7:2017-Cross-Site Scripting (XSS)

Il cross-site scripting (XSS) consente agli utenti malintenzionati di eseguire script nei browser web degli utenti per controllare le sessioni degli utenti, 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 fornisce criteri di protezione dalle minacce che possono essere sfruttati per proteggersi dagli attacchi XSS nell'API.  Utilizzando le espressioni regolari, con il criterio RegularExpressionProtection o il criterio JavaScript, controlla i valori del payload e dei parametri per JavaScript e altri attacchi di tipo injection.

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

A8:2017 - Deserializzazione non sicura

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

Apigee sconsiglia la deserializzazione. Tuttavia, il criterio JSONThreatProtection e il criterio RegularExpressionProtection possono aiutarti a proteggerti dai payload JSON dannosi. Le norme JavaScript possono essere utilizzate anche per eseguire la scansione dei payload alla ricerca di contenuti dannosi. La cache e altri criteri possono essere utilizzati per proteggersi dagli attacchi di replay. A livello di infrastruttura, la piattaforma Apigee dispone anche di guardrail integrati per proteggere i processi in esecuzione.

A9:2017 - Utilizzo di componenti con vulnerabilità note

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

Le release regolari dei prodotti Apigee garantiscono la protezione dalle vulnerabilità dei componenti, soprattutto quando vengono rilevate vulnerabilità specifiche. Il cloud pubblico Apigee viene sottoposto a patch automaticamente e Apigee invia una notifica ai clienti di Edge for Private Cloud quando sono disponibili patch on-premise per l'installazione.

A10:2017 - Logging e monitoraggio insufficienti

Se non esegui adeguatamente il logging, il monitoraggio e la gestione degli incidenti nei tuoi sistemi, gli attaccanti possono eseguire attacchi più profondi e prolungati su dati e software.

Apigee offre diversi modi per eseguire il logging, il monitoraggio, la gestione degli errori e il logging di controllo.

Logging

  • I messaggi di log possono essere inviati a Splunk o a un altro endpoint syslog utilizzando il criterio di registrazione dei messaggi.
  • I dati di analisi dell'API possono essere estratti tramite l'API di analisi e importati o esportati in altri sistemi.
  • In Edge for Private Cloud, puoi utilizzare il criterio di logging dei messaggi per scrivere nei file di log locali. Sono disponibili anche i file di log di ciascun componente in esecuzione.
  • Il criterio JavaScript può essere utilizzato per inviare messaggi di log a un endpoint di registrazione REST in modo sincrono o asincrono.

Monitoraggio

  • Utilizza l'API o la UI di Monitoraggio API per monitorare regolarmente le API e i backend e attivare gli avvisi.
  • Utilizza il monitoraggio dell'integrità per monitorare regolarmente i backend del server di destinazione.
  • Apigee fornisce consigli per monitorare Edge for Private Cloud.
  • Apigee fornisce inoltre best practice che il tuo team può sfruttare per monitorare il tuo programma API.

Gestione degli errori

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

Audit log

La piattaforma Apigee mantiene un log di controllo che monitora le 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 l'OWASP ha aggiornato il proprio elenco per il 2017, alcune vulnerabilità dell'elenco del 2 2013 non sono state incluse. Tuttavia, rimangono minacce valide. Le sezioni seguenti descrivono come gestire queste minacce con Apigee.

A8:2013 - Cross-Site Request Forgery (CSRF)

Le richieste di contraffazione tra siti consentono agli attaccanti di inoltrare i dati di autenticazione, il cookie della sessione e altri dati di un utente a un'applicazione web vulnerabile tramite HTTP, inducendo l'applicazione web a credere che le richieste siano legittime.

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.
  • Valuta la possibilità di utilizzare tecniche HMAC, state, hash, nonce o PKCE per evitare attacchi di contraffazione e di replay.

A10:2013 - Reindirizzamenti e inoltri non convalidati

Se un'applicazione web esegue reindirizzamenti, ma non convalida che i reindirizzamenti indirizzino gli utenti a siti web attendibili e previsti, gli utenti possono essere reindirizzati a destinazioni dannose per eseguire phishing, esecuzione di malware e altri attacchi.

Linee guida:

  • Utilizza OAuth e applica la convalida a ogni richiesta.
  • Per evitare reindirizzamenti 302 imprevisti, controlla la presenza di codici di risposta nella logica del proxy API e gestisci i reindirizzamenti in modo appropriato.