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

Panoramica

Gli ecosistemi API subiscono vari attacchi da client esterni e interni. L'offerta e l'utilizzo delle API creano enormi opportunità per i fornitori di servizi, ma comportano 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 open source dedicata ad aiutare le organizzazioni a sviluppare, acquistare e gestire applicazioni e API attendibili. Attraverso 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.

Con Apigee, il livello del proxy API può rilevare, bloccare e segnalare le richieste API non valide dal client prima che vengano elaborate sui sistemi di backend, riducendo così il rischio e proteggendo i tuoi servizi. Le richieste non valide possono includere qualsiasi componente che costituisce il protocollo a livello di applicazione HTTP:

  • URL
  • Intestazioni
  • Percorso
  • Payload

Le richieste API non valide 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 la maschera dei dati, il logging, l'amministrazione e così via.

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

Soluzioni Apigee per le 10 principali vulnerabilità OWASP del 2017

Esistono molti problemi di sicurezza quando si tratta di creare e proteggere le applicazioni web. OWASP ha pubblicato l'elenco delle 10 principali minacce alla sicurezza OWASP del 2017 per le applicazioni web. Sebbene un'applicazione web abbia molte parti, 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 le descrizioni di come potresti utilizzare Apigee per risolvere queste minacce.

A1:2017 - Iniezione

Per proteggerti dall'iniezione 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 fornisce diversi criteri di convalida dell'input per verificare che i valori forniti da un client corrispondano alle aspettative prima di consentire l'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 dei limiti. 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 - Autenticazione e gestione delle sessioni non valide

Gli aggressori possono accedere a password, token di sessione e chiavi per impersonare altri utenti sfruttando i difetti di implementazione nelle applicazioni. Si tratta più di un problema di implementazione che di un problema del prodotto. Apigee fornisce i criteri VerifyApiKey, OAuth e JSON Web Token (JWT), che aiutano a proteggerti da questa vulnerabilità.

Convalida delle chiavi API

La convalida delle chiavi API è la forma più semplice di sicurezza basata sulle 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 collegato a un proxy API, verifica che la chiave API sia in uno stato approvato per la risorsa richiesta.

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

Il termine "chiavi API" a volte può significare cose diverse. In Apigee, quando viene creata la relazione tra app e prodotto, Apigee genera un ID client e un client secret. Alcuni si riferiscono sia all' ID che al secret come chiave API. Alcuni si riferiscono solo all'ID client come chiave API. Nell'interfaccia utente di Edge, vedrai "chiave utente" e "secret utente".

Nel criterio VerifyAPIKey viene verificato solo l'ID client, o "chiave utente" . Gli sviluppatori ricevono una chiave utente quando registrano la loro app con Apigee e associano l'app a un prodotto API. Gli sviluppatori includono la chiave utente nelle chiamate che l'app effettua ai proxy API inclusi nel prodotto API.

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

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

OAuth 2.0

Il framework di autorizzazione OAuth 2.0 consente a un'applicazione di terze parti di ottenere un accesso limitato a un servizio HTTP, per conto di un proprietario della 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 forzata del token di accesso OAuth può essere eseguita utilizzando il criterio OAuthv2. Il consumatore deve essere registrato e avere un'app approvata che gli abbia concesso l'accesso all'API. In cambio, riceverà un ID client API e un client secret. Il consumatore deve eseguire una delle concessioni OAuth per essere autenticato, 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, sono di uso comune per condividere attestazioni o asserzioni tra applicazioni connesse. Apigee fornisce il supporto JWT utilizzando tre criteri.

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

A3:2017 - Esposizione di dati sensibili

Gli aggressori prendono di mira i dati sensibili come i dettagli della carta di credito, i numeri di previdenza sociale, le credenziali di accesso, le informazioni che consentono l'identificazione personale (PII) e gli ID fiscali per commettere furti di identità, furti di denaro, frodi e altri crimini. Le applicazioni web devono implementare la crittografia, sia a riposo che 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 link criptato tra un server web e un client web, come un browser o un' app. Apigee supporta sia TLS unidirezionale che bidirezionale.

TLS in entrata (client che si connette all'API che funge da server) è supportato tramite l'utilizzo di una configurazione dell'host virtuale. 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'utilizzo 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 forzata di TLS bidirezionale garantisce che il client utilizzi un certificato già integrato in Apigee. OWASP fornisce anche best practice TLS.

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

Di seguito sono riportate le linee guida per la protezione dei dati sensibili:

  • Utilizza una piattaforma che supporti TLS unidirezionale e bidirezionale, che proteggerà a livello di protocollo.
  • Utilizza criteri come AssignMessage e 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 maschera dei dati per mascherare i dati sensibili nello strumento di traccia di Edge.
  • Fai attenzione a non archiviare dati sensibili nella cache (o cripta i dati sensibili che sono archiviati nella cache). In Edge, puoi crittografare i dati sensibili a riposo in 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 i processori XML sono obsoleti o implementati in modo errato, gli aggressori possono hackerare i dati e utilizzarli per rubare informazioni o lanciare vari tipi di attacchi al sistema, come il denial of service.

Il criterio ExtractVariables di Apigee ti consente di estrarre i contenuti da una richiesta o una risposta e di assegnarli a una variabile. Puoi estrarre qualsiasi parte del messaggio, incluse 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, una volta trovata una corrispondenza, impostando una variabile con i contenuti del messaggio specificati.

Apigee include un parser XML integrato nella piattaforma che utilizza XPath per estrarre i dati. Dispone anche di un criterio XMLThreatProtection per proteggerti dai payload XML dannosi.

A5:2017 - Controllo degli accessi non valido

Dopo che gli utenti hanno eseguito l'accesso e ottenuto l'accesso a un sistema, è necessario implementare controlli di autorizzazione appropriati in modo che gli utenti possano vedere e fare solo ciò che è loro consentito. Senza controlli degli accessi efficaci, gli aggressori possono visualizzare dati non autorizzati e spesso sensibili o manipolare in modo dannoso i dati e il comportamento del sistema.

Apigee supporta un approccio a più livelli per implementare i controlli degli accessi per impedire agli attori malintenzionati di apportare modifiche non autorizzate o accedere al sistema.

Controlli degli accessi per l'interfaccia utente di Edge

Controlli degli accessi per il portale per sviluppatori Apigee

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

Controlli degli accessi per l'accesso all'API di runtime di Apigee

  • L'accesso alle API può essere applicato tramite chiavi API, token OAuth, ambiti OAuth, certificati, e altre tecniche.
  • Il provider 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 uno sviluppatore viene concesso l'accesso a un prodotto API, riceve un ID client e un secret che vengono 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 - Configurazione errata della sicurezza

Le configurazioni errate della sicurezza sono facili da trascurare, spesso perché amministratori e sviluppatori si fidano erroneamente che i sistemi che utilizzano siano intrinsecamente sicuri. La configurazione errata della sicurezza può avvenire in molti modi diversi, ad esempio affidandosi alle 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 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à. La patch del cloud pubblico Edge viene applicata automaticamente. I clienti di Edge for Private Cloud (on-premise) devono applicare autonomamente le patch del prodotto.

A7:2017 - Cross-site scripting (XSS)

Il cross-site scripting (XSS) consente agli aggressori 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 fornisce criteri di protezione dalle minacce che possono essere utilizzati per proteggerti da XSS nell'API. Utilizzando le espressioni regolari, con il criterio RegularExpressionProtection o il criterio JavaScript, controlla i valori dei payload e dei parametri per 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 criterio AssignMessage.

A8:2017 - Deserializzazione non sicura

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

Apigee non consiglia la deserializzazione. Tuttavia, i criteri JSONThreatProtection e RegularExpressionProtection possono aiutarti a proteggerti dai payload JSON dannosi. Il criterio JavaScript può essere utilizzato anche per analizzare i payload alla ricerca di contenuti dannosi. La cache e altri criteri possono essere utilizzati per proteggerti dagli attacchi di replay. A livello di infrastruttura, la piattaforma Apigee include anche misure di sicurezza integrate per proteggere i processi in esecuzione.

A9:2017 - Utilizzo di componenti con vulnerabilità note

Poiché framework, librerie e moduli vengono eseguiti con accesso completo di esecuzione e 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. La patch del cloud pubblico Apigee viene applicata 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 in modo adeguato il logging, il monitoraggio e la gestione degli incidenti nei tuoi sistemi, gli aggressori possono eseguire attacchi più profondi e prolungati a dati e software.

Apigee offre diversi modi per eseguire il logging, il monitoraggio, la gestione degli errori e l'audit log.

Logging

  • I messaggi di log possono essere inviati a Splunk o ad 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 for Private Cloud, puoi utilizzare il criterio MessageLogging per scrivere nei file di log locali. Sono disponibili anche i file di log di 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

Gestione degli errori

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

Audit log

La piattaforma Apigee conserva un audit log che tiene traccia delle modifiche apportate 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à dell'elenco del 2013 sono state escluse. Sono ancora minacce valide. Le sezioni seguenti descrivono come gestire queste minacce con Apigee.

A8:2013 - Falsificazione di richiesta cross-site (CSRF)

Le richieste di falsificazione cross-site consentono agli aggressori di inoltrare i dettagli di autenticazione, il cookie di 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 da parte dell'utente.

Linee guida:

  • Si tratta più di un problema del browser che di un problema del prodotto API. Puoi risolvere questa vulnerabilità con OpenID Connect, OAuth e altre tecniche.
  • Valuta la possibilità di utilizzare le tecniche HMAC, stato, hash, nonce o PKCE per impedire attacchi di falsificazione e replay attacchi.

A10:2013 - Reindirizzamenti e inoltri non convalidati

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

Linee guida:

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