Condividi tramite

Raccomandazioni per attenuare le principali 10 minacce di Sicurezza API OWASP tramite Gestione API

  • Articolo

SI APPLICA A: Tutti i livelli di Gestione API

La fondazione Open Web Application Security Project (OWASP) lavora per migliorare la sicurezza del software tramite i progetti software open source guidati dalla community, centinaia di capitoli in tutto il mondo, decine di migliaia di membri e ospitando conferenze locali e globali.

Il progetto di sicurezza dell'API OWASP è incentrato su strategie e soluzioni per comprendere e attenuare le vulnerabilità e i rischi di sicurezza univoci delle API. In questo articolo verranno illustrati i suggerimenti per l'uso di Gestione API di Azure per attenuare le prime 10 minacce API identificate da OWASP.

Nota

Oltre a seguire i suggerimenti in questo articolo, è possibile abilitare Defender per le API, una funzionalità di Microsoft Defender per il Cloud, per informazioni dettagliate sulla sicurezza delle API, raccomandazioni e rilevamento delle minacce. Altre informazioni sull'uso di Defender per le API con Gestione API

Autorizzazione a livello di oggetto interrotta

Gli oggetti API che non sono protetti con il livello di autorizzazione appropriato possono essere vulnerabili alle perdite di dati e alla manipolazione non autorizzata dei dati tramite identificatori di accesso a oggetti deboli. Ad esempio, un utente malintenzionato potrebbe sfruttare un identificatore di oggetto integer, che può essere iterato.

Altre informazioni su questa minaccia: API1:2019 Autorizzazione a livello di oggetto interrotta

Consigli

  • Il posto migliore per implementare l'autorizzazione a livello di oggetto è all'interno dell'API back-end stessa. Nel back-end è possibile prendere le decisioni di autorizzazione corrette a livello di richiesta (o oggetto), se applicabile, usando la logica applicabile al dominio e all'API. Si considerino degli scenari in cui una determinata richiesta può produrre livelli di dettaglio diversi nella risposta, a seconda delle autorizzazioni e dell'autorizzazione del richiedente.

  • Se un'API vulnerabile corrente non può essere modificata nel back-end, Gestione API può essere usata come fallback. Ad esempio:

    • Usare un criterio personalizzato per implementare l'autorizzazione a livello di oggetto, se non è implementata nel back-end.

    • Implementare un criterio personalizzato per eseguire il mapping degli identificatori dalla richiesta al back-end e dal back-end al client, in modo che gli identificatori interni non vengano esposti.

      In questi casi, i criteri personalizzati possono essere un'espressione di criteri con una ricerca (ad esempio, un dizionario) o l'integrazione con un altro servizio tramite i criteri di invio della richiesta.

  • Per gli scenari GraphQL, applicare l'autorizzazione a livello di oggetto tramite i criteri di richiesta GraphQL convalidati usando l'elemento authorize.

Autenticazione utente interrotta

I meccanismi di autenticazione vengono spesso implementati in modo non corretto o mancante, consentendo agli utenti malintenzionati di sfruttare i difetti di implementazione per accedere ai dati.

Altre informazioni su questa minaccia: API2:2019 Autenticazione utente interrotta

Consigli

Usare Gestione API per l'autenticazione e l'autorizzazione degli utenti:

  • Autenticazione: Gestione API supporta i metodi di autenticazione seguenti:

    • Criteri di autenticazione di base - Credenziali nome utente e password.

    • Chiave di sottoscrizione: una chiave di sottoscrizione offre un livello di sicurezza simile all'autenticazione di base e potrebbe non essere sufficiente da sola. Se la chiave di sottoscrizione viene compromessa, un utente malintenzionato potrebbe ottenere accesso illimitato al sistema.

    • Criteri del certificato client: l'uso dei certificati client è più sicuro delle credenziali di base o della chiave di sottoscrizione, ma non consente la flessibilità offerta dai protocolli di autorizzazione basati su token, ad esempio OAuth 2.0.

  • Autorizzazione: Gestione API supporta un criterio JWT convalidato per verificare la validità di un token di accesso JWT OAuth 2.0 in ingresso in base alle informazioni ottenute dall'endpoint dei metadati del provider di identità OAuth. Configurare i criteri per controllare le attestazioni del token, il gruppo di destinatari e l'ora di scadenza pertinenti. Altre informazioni sulla protezione di un'API con l'autorizzazione OAuth 2.0 e l'ID Microsoft Entra.

Altre raccomandazioni:

  • Usare i criteri in Gestione API per aumentare la sicurezza. Ad esempio, la limitazione della frequenza delle chiamate rallenta gli attori malintenzionati usando attacchi di forza bruta per compromettere le credenziali.

  • Le API devono usare TLS/SSL (sicurezza del trasporto) per proteggere le credenziali o i token. Le credenziali e i token devono essere inviati nelle intestazioni della richiesta e non come parametri di query.

  • Nel portale per sviluppatori di Gestione API, configurare Microsoft Entra ID o Azure Active Directory B2C come provider di identità per aumentare la sicurezza dell'account. Il portale per sviluppatori usa CAPTCHA per attenuare gli attacchi di forza bruta.

Esposizione eccessiva dei dati

Una progettazione efficace dell'interfaccia API è complessa in modo ingannevole. Spesso, in particolare con le API legacy che si sono sviluppate nel tempo, le interfacce di richiesta e risposta contengono più campi dati rispetto alle applicazioni che utilizzano.

Un attore non valido potrebbe tentare di accedere direttamente all'API (ad esempio riproducendo una richiesta valida) o di leggere il traffico tra server e API. L'analisi delle azioni dell'API e dei dati disponibili potrebbe restituire dati sensibili all'utente malintenzionato, che non viene visualizzato o usato dall'applicazione front-end.

Altre informazioni su questa minaccia: API3:2019 Esposizione eccessiva dei dati

Consigli

  • L'approccio migliore per mitigare questa vulnerabilità consiste nel garantire che le interfacce esterne definite nell'API back-end siano progettate con attenzione e, idealmente, indipendentemente dalla persistenza dei dati. Devono contenere solo i campi richiesti dai consumer dell'API. Le API devono essere esaminate di frequente e i campi legacy sono deprecati, quindi rimossi.

    In Gestione API usare:

    • Revisioni per controllare correttamente le modifiche che non causano interruzioni, ad esempio l'aggiunta di un campo a un'interfaccia. È possibile usare revisioni insieme a un'implementazione del controllo delle versioni nel back-end.

    • Versioni per modifiche di rilievo, ad esempio la rimozione di un campo da un'interfaccia.

  • Se non è possibile modificare la progettazione dell'interfaccia back-end e i dati eccessivi sono un problema, usare i criteri di trasformazione Gestione API per riscrivere i payload delle risposte e mascherare o filtrare i dati. Ad esempio, rimuovere le proprietà JSON non richieste da un corpo della risposta.

  • La convalida del contenuto della risposta in Gestione API può essere usata con uno schema XML o JSON per bloccare le risposte con proprietà non documentate o valori non validi. Il criterio supporta anche il blocco delle risposte che superano una dimensione specificata.

  • Usare il criterio del codice di stato di convalida per bloccare le risposte con errori non definiti nello schema dell'API.

  • Usare il criterio convalida intestazioni per bloccare le risposte con intestazioni non definite nello schema o non conformi alla definizione nello schema. Rimuovere le intestazioni indesiderate con il criterio di intestazione set.

  • Per gli scenari GraphQL, usare i criteri di convalida della richiesta GraphQL per convalidare le richieste GraphQL, autorizzare l'accesso a percorsi di query specifici e limitare le dimensioni della risposta.

Mancanza di risorse e limitazione della frequenza

La mancanza di limitazione della frequenza può causare l'esfiltrazione dei dati o gli attacchi DDoS riusciti nei servizi back-end, causando un'interruzione per tutti i consumer.

Altre informazioni su questa minaccia: API4:2019 Mancanza di risorse e limitazione della frequenza

Consigli

  • Usare i criteri limite di frequenza (a breve termine) e limite di quota (a lungo termine) per controllare il numero consentito di chiamate API o larghezza di banda per consumer.

  • Definire le definizioni di oggetti richiesta strict e le relative proprietà nella definizione OpenAPI. Ad esempio, definire il valore massimo per i valori interi di paging, maxLength e l'espressione regolare (regex) per le stringhe. Applicare tali schemi con i criteri convalidare il contenuto e convalidare i parametri in Gestione API.

  • Applicare le dimensioni massime della richiesta con i criteri di convalida del contenuto.

  • Ottimizzare le prestazioni con la memorizzazione nella cache predefinita, riducendo così il consumo di risorse di CPU, memoria e rete per determinate operazioni.

  • Applicare l'autenticazione per le chiamate API (vedere Autenticazione utente interrotta). Revocare l'accesso per gli utenti offensivi. Ad esempio, disattivare la chiave di sottoscrizione, bloccare l'indirizzo IP con il criterio di limitazione degli indirizzi IP chiamanti o rifiutare le richieste per una determinata attestazione utente da un token JWT.

  • Applicare un criterio CORS per controllare i siti Web autorizzati a caricare le risorse gestite tramite l'API. Per evitare configurazioni eccessivamente permissive, non usare valori jolly (*) nei criteri CORS.

  • Ridurre al minimo il tempo necessario per rispondere a un servizio back-end. Più tempo impiega il servizio di backend a rispondere, più a lungo viene occupata la connessione in Gestione API, riducendo così il numero di richieste che possono essere gestite in un determinato intervallo di tempo.

  • Anche se Gestione API può proteggere i servizi back-end da attacchi DDoS, può essere vulnerabile a tali attacchi. Distribuire un servizio di protezione bot davanti a Gestione API (ad esempio, gateway applicazione di Azure, Frontdoor di Azure o Protezione DDoS di Azure) per una migliore protezione da attacchi DDoS. Quando si usa un WAF con il gateway applicazione di Azure o Frontdoor di Azure, è consigliabile usare Microsoft_BotManagerRuleSet_1.0.

Autorizzazione a livello di funzione interrotta

I criteri di controllo di accesso complessi con gerarchie, gruppi e ruoli diversi e una separazione non chiara tra funzioni amministrative e regolari comportano errori di autorizzazione. Sfruttando questi problemi, gli utenti malintenzionati ottengono l'accesso alle risorse o alle funzioni amministrative di altri utenti.

Altre informazioni su questa minaccia: API5:2019 Autorizzazione a livello di funzione interrotta

Consigli

  • Per impostazione predefinita, proteggere tutti gli endpoint API in Gestione API con chiavi di sottoscrizione.

  • Definire un criterio convalida JWT e applicare le attestazioni di token necessarie. Se alcune operazioni richiedono un'imposizione più rigorosa delle attestazioni, definire criteri validate-jwt aggiuntivi solo per tali operazioni.

  • Usare una rete virtuale di Azure o un collegamento privato per nascondere gli endpoint API da Internet. Altre informazioni sulle opzioni di rete virtuale con Gestione API.

  • Non definire le operazioni API con caratteri jolly, ovvero le API "catch-all" con * come percorso. Assicurarsi che Gestione API gestisca solo le richieste per gli endpoint definiti in modo esplicito e che le richieste agli endpoint non definiti vengano rifiutate.

  • Non pubblicare API con prodotti aperti che non richiedono una sottoscrizione.

Assegnazione di massa

Se un'API offre più campi rispetto al client necessario per una determinata azione, un utente malintenzionato potrebbe inserire proprietà eccessive per eseguire operazioni non autorizzate sui dati. Gli utenti malintenzionati possono individuare proprietà non documentate controllando il formato delle richieste e delle risposte o altre API, o individuandole. Questa vulnerabilità è particolarmente applicabile se non si usano linguaggi di programmazione fortemente tipizzati.

Altre informazioni su questa minaccia: API6:2019 Assegnazione di massa

Consigli

  • Le interfacce API esterne devono essere separate dall'implementazione interna dei dati. Evitare l'associazione di contratti API direttamente ai contratti dati nei servizi back-end. Esaminare spesso la progettazione dell'API e deprecare e rimuovere le proprietà legacy usando il controllo delle versioni in Gestione API.

  • Definire con precisione i contratti XML e JSON nello schema dell'API e usare convalidare il contenuto e convalidare i criteri dei parametri per bloccare le richieste e le risposte con proprietà non documentate. Il blocco delle richieste con proprietà non documentate riduce gli attacchi, mentre il blocco delle risposte con proprietà non documentate rende più difficile il reverse engineer dei potenziali vettori di attacco.

  • Se l'interfaccia back-end non può essere modificata, usare i criteri di trasformazione per riscrivere i payload di richiesta e risposta e separare i contratti API dai contratti back-end. Ad esempio, mascherare o filtrare i dati o rimuovere le proprietà JSON non richieste.

Configurazione errata della sicurezza

Gli utenti malintenzionati possono tentare di sfruttare vulnerabilità di configurazione errata della sicurezza, ad esempio:

  • Protezione avanzata della sicurezza mancante
  • Funzionalità abilitate non necessarie
  • Connessioni di rete inutilmente aperte a Internet
  • Uso di protocolli o crittografie deboli
  • Altre impostazioni o endpoint che possono consentire l'accesso non autorizzato al sistema

Altre informazioni su questa minaccia: API7:2019 Errori di configurazione della sicurezza

Consigli

  • Configurare correttamente TLS del gateway. Non usare protocolli vulnerabili (ad esempio TLS 1.0, 1.1) o crittografie.

  • Configurare le API per accettare solo il traffico crittografato, ad esempio tramite protocolli HTTPS o WSS.

  • Valutare la possibilità di distribuire Gestione API dietro un endpoint privato o collegato a una rete virtuale distribuita in modalità interna. Nelle reti interne, l'accesso può essere controllato dall'interno della rete privata (tramite firewall o gruppi di sicurezza di rete) e da Internet (tramite un proxy inverso).

  • Usare i criteri di Gestione API di Azure:

    • Ereditare sempre i criteri padre tramite il tag <base>.

    • Quando si usa OAuth 2.0, configurare e testare i criteri di convalida JWT per verificare l'esistenza e la validità del token JWT prima che raggiunga il back-end. Controllare automaticamente l'ora di scadenza del token, la firma del token e l'autorità di certificazione. Applicare attestazioni, gruppi di destinatari, scadenza del token e firma del token tramite le impostazioni dei criteri.

    • Configurare i criteri CORS e non usare caratteri jolly * per alcuna opzione di configurazione. Elencare invece in modo esplicito i valori consentiti.

    • Impostare i criteri di convalida su prevent in ambienti di produzione per convalidare JSON e XML Schema, intestazioni, parametri di query e codici di stato e applicare le dimensioni massime per la richiesta o la risposta.

    • Se Gestione API non è al di fuori di un limite di rete, la convalida IP del client è comunque possibile usando il criterio di limitazione degli indirizzi IP del chiamante. Assicurarsi che usi un elenco di elementi consentiti, non un elenco di blocchi.

    • Se i certificati client vengono usati tra il chiamante e Gestione API, usare i criteri di convalida del certificato client. Assicurarsi che gli attributi validate-revocation, validate-trust, validate-not-before e validate-not-after siano tutti impostati su true.

      • I certificati client (TLS reciproco) possono essere applicati anche tra Gestione API e back-end. Il back-end deve:

        • Disporre delle credenziali di autorizzazione configurate

        • Convalidare la catena di certificati, se applicabile

        • Convalidare il nome del certificato, se applicabile

  • Per gli scenari GraphQL, usare i criteri di richiesta GraphQL convalidati. Verificare che l'elemento authorization, e gli attributi max-size e max-depth siano impostati.

  • Non archiviare segreti nei file dei criteri o nel controllo del codice sorgente. Usare sempre denominati valori di Gestione API o recuperare i segreti in fase di esecuzione usando espressioni di criteri personalizzate.

    • I valori denominati devono essere integrati con Key Vault o crittografati all'interno di Gestione API contrassegnandoli come "segreto". Non archiviare mai segreti in valori denominati in testo normale.

  • Pubblicare API tramite prodotti che richiedono sottoscrizioni. Non usare prodotti aperti che non richiedono una sottoscrizione.

  • Usare l'integrazione di Key Vault per gestire tutti i certificati, cosa che centralizza la gestione dei certificati e consente di semplificare le attività di gestione delle operazioni, ad esempio il rinnovo o la revoca dei certificati.

  • Quando si usa il gateway self-hosted, assicurarsi che sia presente un processo per aggiornare periodicamente l'immagine alla versione più recente.

  • Rappresentare i servizi back-end come entità back-end. Configurare le credenziali di autorizzazione, la convalida della catena di certificati e la convalida del nome del certificato, se applicabile.

  • Quando si usa il portale per sviluppatori:

    • Se si sceglie di ospitare autonomamente il portale per sviluppatori, assicurarsi che sia disponibile un processo per aggiornare periodicamente il portale self-hosted alla versione più recente. Gli aggiornamenti per la versione gestita predefinita sono automatici.

    • Usare Microsoft Entra ID o Azure Active Directory B2C per l'iscrizione e l'accesso degli utenti. Disabilitare l'autenticazione predefinita di nome utente e password, meno sicura.

    • Assegnare gruppi di utenti ai prodotti per controllare la visibilità delle API nel portale.

  • Usare Criteri di Azure per applicare le autorizzazioni di configurazione a livello di risorsa e controllo degli accessi in base al ruolo di Gestione API per controllare l'accesso alle risorse. Concedere privilegi minimi necessari a ogni utente.

  • Usare un processo DevOps e un approccio di infrastruttura come codice all'esterno di un ambiente di sviluppo per garantire la coerenza delle modifiche al contenuto e alla configurazione di Gestione API e per ridurre al minimo gli errori umani.

  • Non usare funzionalità deprecate.

Injection

Qualsiasi endpoint che accetta i dati utente è potenzialmente vulnerabile a un exploit injection. Gli esempi includono, ma non sono limitati a:

  • Command injection, in cui un attore non valido tenta di modificare la richiesta API per eseguire comandi nel sistema operativo che ospita l'API

  • SQL injection, in cui un attore non valido tenta di modificare la richiesta API per eseguire comandi e query sul database da cui dipende un'API

Altre informazioni su questa minaccia: API8:2019 Injection

Consigli

  • I criteri moderni di Web Application Firewall (WAF) coprono molte vulnerabilità comuni di inserimento. Anche se Gestione API non dispone di un componente WAF predefinito, è consigliabile distribuire un WAF upstream (in primo piano) dell'istanza di Gestione API. Ad esempio, usare gateway applicazione di Azure o Frontdoor di Azure.

    Importante

    Assicurarsi che un attore non valido non possa ignorare il gateway che ospita WAF e connettersi direttamente al gateway di Gestione API o all'API back-end stessa. Le possibili mitigazioni includono: ACL di rete, uso dei criteri di Gestione API per limitare il traffico in ingresso dall'IP client, rimuovendo l'accesso pubblico, se non necessario, e l'autenticazione del certificato client (nota anche come TLS reciproco o mTLS).

  • Usare i criteri di convalida dello schema e dei parametri, se applicabile, per vincolare e convalidare ulteriormente la richiesta prima di raggiungere il servizio API back-end.

    Lo schema fornito con la definizione API deve avere un vincolo di pattern regex applicato ai campi vulnerabili. Ogni espressione regolare deve essere testata per assicurarsi che vincola sufficientemente il campo per attenuare i tentativi di inserimento comuni.

Gestione degli asset non corretta

Le vulnerabilità correlate alla gestione degli asset non corretta includono:

  • Mancanza di documentazione o informazioni sulla proprietà dell'API appropriate

  • Numero eccessivo di versioni precedenti dell'API, che potrebbero essere prive di correzioni di sicurezza

Altre informazioni su questa minaccia: API9:2019 Gestione degli asset non corretta

Consigli

  • Usare una specifica OpenAPI ben definita come origine per l'importazione di API REST. La specifica consente l'incapsulamento della definizione dell'API, inclusi i metadati autodocumentati.

    • Usare interfacce API con percorsi precisi, schemi di dati, intestazioni, parametri di query e codici di stato. Evitare operazioni con caratteri jolly. Fornire descrizioni per ogni API e operazione e includere le informazioni di contatto e licenza.

    • Evitare endpoint che non contribuiscono direttamente all'obiettivo aziendale. Aumentano inutilmente la superficie di attacco e rendono più difficile l'evoluzione dell'API.

  • Usare revisioni e versioni in Gestione API per gestire e controllare gli endpoint API. Disporre di una strategia di controllo delle versioni back-end avanzata ed eseguire il commit in un numero massimo di versioni API supportate (ad esempio, 2 o 3 versioni precedenti). Pianificare rapidamente la deprecazione e infine rimuovere versioni precedenti, spesso meno sicure e API.

  • Usare un'istanza di Gestione API per ogni ambiente, ad esempio sviluppo, test e produzione. Assicurarsi che ogni istanza di Gestione API si connetta alle relative dipendenze nello stesso ambiente. Nell'ambiente di test, ad esempio, la risorsa gestione API di test deve connettersi a una risorsa di Azure Key Vault di test e alle versioni di test dei servizi back-end. Usare l'automazione DevOps e le procedure di infrastruttura come codice per mantenere la coerenza e l'accuratezza tra gli ambienti e ridurre gli errori umani.

  • Usare i tag per organizzare API e prodotti e raggrupparli per la pubblicazione.

  • Pubblicare API per l'utilizzo tramite il portale per sviluppatori predefinito. Assicurarsi che la documentazione dell'API sia aggiornata.

  • Individuare le API non documentate o non gestite ed esporle tramite Gestione API per un controllo migliore.

Registrazione e monitoraggio insufficienti

Registrazione e monitoraggio insufficienti, insieme all'integrazione mancante o inefficace con la risposta agli eventi imprevisti, consente agli utenti malintenzionati di continuare ad attaccare i sistemi, mantenere la persistenza, trasformare tramite Pivot più sistemi da manomettere, ed estrarre o distruggere i dati. La maggior parte degli studi sulle violazioni dimostra che il tempo necessario per rilevare una violazione è superiore a 200 giorni, in genere rilevato da parti esterne anziché da processi interni o monitoraggio.

Altre informazioni su questa minaccia: API10:2019 Registrazione e monitoraggio insufficienti

Consigli

Passaggi successivi

Altre informazioni su: