Condividi tramite

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

SI APPLICA A: tutti i livelli di Gestione API

Note

Questo articolo è stato aggiornato per riflettere l'elenco più recente della sicurezza dell'API OWASP top 10 per il 2023.

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. Questo articolo illustra le raccomandazioni più recenti per attenuare le prime 10 minacce api identificate da OWASP nell'elenco 2023 usando Azure API Management.

Anche se API Management fornisce controlli completi per la sicurezza delle API, altri servizi Microsoft forniscono funzionalità complementari per rilevare o proteggere dalle minacce dell'API OWASP:

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:2023 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 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 interrotta

Il meccanismo di autenticazione per un sito o un'API è particolarmente vulnerabile perché è aperto a utenti anonimi. Gli asset e gli endpoint necessari per l'autenticazione, inclusi i flussi di password dimenticati o di reimpostazione delle password, devono essere protetti per impedire lo sfruttamento.

Altre informazioni su questa minaccia: API2:2023 Broken Authentication

Consigli

Autorizzazione a livello di proprietà dell'oggetto interrotta

Una progettazione efficace dell'interfaccia API è complessa in modo ingannevole. Spesso, in particolare con le API legacy che si sono evolute nel tempo, le interfacce di richiesta e risposta contengono più campi dati di quelli richiesti dalle applicazioni di utilizzo, consentendo attacchi di tipo data injection. Gli utenti malintenzionati possono anche individuare interfacce non documentate. Queste vulnerabilità potrebbero produrre dati sensibili all'utente malintenzionato.

Altre informazioni su questa minaccia: API3:2023 - Autorizzazione a livello di proprietà oggetto interrotto

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 le revisioni per controllare correttamente le modifiche che non causano interruzioni, ad esempio l'aggiunta di un campo a un'interfaccia, e le versioni per implementare modifiche di rilievo. È anche consigliabile usare interfacce back-end di versione, che in genere hanno un ciclo di vita diverso rispetto alle API rivolte agli utenti.
  • Separare le interfacce API esterne dall'implementazione dei dati interni. Evitare l'associazione di contratti API direttamente ai contratti dati nei servizi back-end.
  • 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. La convalida del contenuto in API Management può essere usata con uno schema XML o JSON per bloccare le risposte con proprietà non documentate o valori non corretti. Ad esempio, rimuovere le proprietà JSON non richieste da un corpo della risposta. 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. I criteri di convalida del contenuto supportano anche il blocco delle risposte che superano le dimensioni specificate.
  • 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.

Consumo di risorse senza restrizioni

Le API richiedono l'esecuzione di risorse, ad esempio memoria o CPU, e possono includere integrazioni downstream che rappresentano un costo operativo (ad esempio, servizi con pagamento per richiesta). L'applicazione di limiti consente di proteggere le API da un utilizzo eccessivo delle risorse.

Altre informazioni su questa minaccia: API4:2023 Consumo di risorse senza restrizioni

Consigli

  • Usare i criteri rate-limit-by-key o rate-limit per applicare la limitazione alle finestre temporali più brevi. Applicare criteri di limitazione della frequenza più rigorosi per gli endpoint sensibili, ad esempio la reimpostazione della password, le operazioni di accesso o di iscrizione o gli endpoint che utilizzano risorse significative.
  • Usare i criteri di quota per chiave o limite di quota per controllare il numero consentito di chiamate API o larghezza di banda per intervalli di tempo più lunghi.
  • Ottimizzare le prestazioni con la memorizzazione nella cache predefinita, riducendo così il consumo di risorse di CPU, memoria e rete per determinate operazioni.
  • Applicare i criteri di convalida.
    • Usare l'attributo max-size nel criterio validate-content per applicare le dimensioni massime di richieste e risposte
    • Definire schemi e proprietà, ad esempio la lunghezza della stringa o la dimensione massima della matrice, nella specifica API. Usare i criteri validate-content, validate-parameterse validate-headers per applicare tali schemi per richieste e risposte.
    • Usare il criterio validate-graphql-request per le API GraphQL e configurare i parametri max-depth e max-size.
    • Configurare gli avvisi in Monitoraggio di Azure per un consumo eccessivo di dati da parte degli utenti.
  • Per le API di intelligenza artificiale generative:
  • Ridurre al minimo il tempo necessario per rispondere a un servizio back-end. Più tempo il servizio back-end richiede per rispondere, più a lungo la connessione viene occupata in API Management, riducendo quindi il numero di richieste che possono essere gestite in un determinato intervallo di tempo.
  • 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 con caratteri jolly (*) nei criteri CORS.
  • Anche se Azure offre protezione a livello di piattaforma e protezione avanzata da attacchi DDoS (Distributed Denial of Service), la protezione dell'applicazione (livello 7) per le API può essere migliorata distribuendo un servizio di protezione bot davanti a API Management, ad esempio gateway applicazione di Azure, Frontdoor di Azure o Protezione DDoS di Azure. Quando si usa un criterio Web application firewall (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:2023 Autorizzazione a livello di funzione interrotta

Consigli

  • Per impostazione predefinita, proteggere tutti gli endpoint API in API Management con chiavi di sottoscrizione o criteri di autorizzazione a livello di api. Se applicabile, definire altri criteri di autorizzazione per api o operazioni API specifiche.
  • Convalidare i token OAuth usando i criteri.
    • Usare i criteri validate-azure-ad-token per convalidare i token di Microsoft Entra. Specificare tutte le attestazioni necessarie e, se applicabile, le applicazioni autorizzate.
    • Per convalidare i token non emessi da Microsoft Entra, definire un criterio validate-jwt e applicare le attestazioni di token necessarie. Se possibile, richiedere l'ora di scadenza.
    • Se possibile, usare token crittografati o elencare applicazioni specifiche per l'accesso.
    • Monitoraggio e revisione delle richieste rifiutate a causa della mancanza di autorizzazione.
  • 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.
  • Se gli INDIRIZZI IP client sono noti, usare un criterio di filtro IP per consentire il traffico solo da indirizzi IP autorizzati.
  • Usare i criteri validate-client-certificate per imporre che un certificato presentato da un client a un'istanza di API Management corrisponda alle regole di convalida e alle attestazioni specificate.

Accesso senza restrizioni ai flussi aziendali sensibili

Le API possono esporre un'ampia gamma di funzionalità all'applicazione che utilizza. È importante che gli autori di API comprendano i flussi aziendali forniti dall'API e la riservatezza associata. Esiste un rischio maggiore per l'azienda se le API che espongono flussi sensibili non implementano protezioni appropriate.

Altre informazioni su questa minaccia: API6:2023 Accesso senza restrizioni ai flussi aziendali sensibili

Consigli

  • Ridurre o bloccare l'accesso in base alle impronte digitali del client. Ad esempio, usare il criterio return-response con il criterio choose per bloccare il traffico dai browser headless in base all'intestazione User-Agent o alla coerenza di altre intestazioni.
  • Usare i criteri validate-parameters per imporre che le intestazioni della richiesta corrispondano alla specifica dell'API.
  • Usare i criteri di filtro IP per consentire le richieste solo da indirizzi IP noti o negare l'accesso da indirizzi IP specifici.
  • Usare le funzionalità di rete privata per limitare la connettività esterna alle API interne.
  • Usare i criteri rate-limit-by-key per limitare i picchi di utilizzo delle API in base all'identità utente, all'indirizzo IP o a un altro valore.
  • Front API Management con gateway applicazione di Azure o Protezione DDoS di Azure servizio per rilevare e bloccare il traffico del bot.

Richiesta lato server falsa

Una vulnerabilità di una richiesta dal lato del server può verificarsi quando l'API recupera una risorsa downstream in base al valore di un URL passato dal chiamante API senza controlli di convalida appropriati.

Altre informazioni su questa minaccia: Richiesta lato server API7:2023

Consigli

  • Se possibile, non usare gli URL forniti nei payload del client, ad esempio come parametri per gli URL back-end, i criteri di invio-richiesta o i criteri rewrite-url.
  • Se la Gestione API o i servizi back-end utilizzano gli URL forniti nel payload della richiesta per la logica di business, definire e applicare un elenco limitato di nomi host, porte, tipi di supporto o altri attributi con criteri in Gestione API, come ad esempio i criteri di scelta e le espressioni di criteri.
  • Definire l'attributo timeout nei criteri forward-request e send-request.
  • Convalidare e purificare i dati di richiesta e risposta con i criteri di convalida. Se necessario, usare i criteri set-body per elaborare la risposta ed evitare di restituire dati non elaborati.
  • Usare la rete privata per limitare la connettività. Ad esempio, se l'API non deve essere pubblica, limitare la connettività da Internet per ridurre la superficie di attacco.

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 inutilmente
  • Connessioni di rete inutilmente aperte a Internet
  • Uso di protocolli o crittografie deboli

Altre informazioni su questa minaccia: Configurazione errata della sicurezza API8:2023

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. È possibile controllare e applicare questa impostazione usando Criteri di Azure.
  • 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 validate-jwt per verificare l'esistenza e la validità del token 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. Se si usa Microsoft Entra, i criteri validate-azure-ad-token offrono un modo più completo e semplice per convalidare i token di sicurezza.
    • Configurare il criterio CORS e non usare caratteri jolly * per le opzioni di configurazione. Elencare invece in modo esplicito i valori consentiti.
    • Impostare i criteri di convalida negli ambienti di produzione per convalidare gli schemi JSON e XML, le intestazioni, i parametri di query e i codici di stato e per 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 valori denominati di Gestione API o recuperare i segreti in fase di runtime usando espressioni di criteri personalizzate. I valori denominati devono essere integrati con Azure Key Vault o crittografati all'interno di API Management contrassegnandoli come "segreti". 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.
  • Assicurarsi che le API richiedano chiavi di sottoscrizione, anche se tutti i prodotti sono configurati per richiedere le chiavi di sottoscrizione. Altre informazioni
  • Richiedere l'approvazione della sottoscrizione per tutti i prodotti ed esaminare attentamente tutte le richieste di sottoscrizione.
  • Usare l'integrazione Key Vault per gestire tutti i certificati. Questa operazione centralizza la gestione dei certificati e consente di semplificare le attività di gestione delle operazioni, ad esempio il rinnovo o la revoca dei certificati. Usare l'identità gestita per eseguire l'autenticazione agli insiemi di credenziali delle chiavi.
  • 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.
  • Assicurarsi che i back-end siano protetti da attacchi di attraversamento del percorso (attraversamento della directory). API Management può inoltrare le richieste contenenti ..%2f nel percorso dell'URL a un back-end. Se il back-end lo decodifica in ../, potrebbe essere soggetto a un attacco di attraversamento del percorso. È anche possibile applicare criteri in Gestione API per rilevare e bloccare le richieste, ad esempio quelle che contengono ..%2f nel percorso.
  • Se possibile, usare gestione credenziali o identità gestita per eseguire l'autenticazione nei servizi back-end.
  • 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 Microsoft Entra External ID per l'iscrizione e l'accesso dell'utente. 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.

Gestione dell'inventario 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:2023 Gestione dell'inventario 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 API Management per gestire le modifiche alle 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 API precedenti, spesso meno sicure. Assicurarsi che i controlli di sicurezza siano implementati in tutte le versioni api disponibili.
  • Separare gli ambienti, ad esempio sviluppo, test e produzione, con servizi di API Management diversi. Assicurarsi che ogni servizio API Management 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.
  • Isolare le autorizzazioni amministrative per le API e le risorse correlate usando le aree di lavoro.
  • Usare i tag per organizzare API e prodotti e raggrupparli per la pubblicazione.
  • Pubblicare API da usare tramite un portale per sviluppatori. 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.
  • Usa il Centro API di Azure per mantenere un inventario completo e centralizzato di API, versioni e distribuzioni, anche se le API non sono gestite in Azure API Management.

Uso non sicuro delle API

Le risorse ottenute tramite integrazioni downstream tendono a essere più attendibili dell'input API del chiamante o dell'utente finale. Se non vengono applicati gli standard di sanificazione e sicurezza appropriati, l'API potrebbe essere vulnerabile, anche se l'integrazione viene fornita tramite un servizio attendibile.

Altre informazioni su questa minaccia: API10:2023 Utilizzo non sicuro delle API

Consigli

  • È consigliabile usare API Management per fungere da facciata per le dipendenze downstream con cui si integrano le API back-end.
  • Se le dipendenze downstream vengono gestite tramite Gestione API o se le dipendenze downstream vengono consumate con un criterio di invio richiesta in Gestione API, fare riferimento alle raccomandazioni di altre sezioni della presente documentazione per garantire il consumo sicuro e controllato, tra cui:
    • Verificare che il trasporto sicuro sia abilitato e applicare la configurazione TLS/SSL
    • Se possibile, eseguire l'autenticazione con gestione credenziali o identità gestita
    • Controllare il consumo con criteri rate-limit-by-key e quota-limit-by-key
    • Registrare o bloccare le risposte non conformi alla specifica API usando i criteri validate-content e validate-header
    • Trasformare le risposte con il criterio set-body, ad esempio per rimuovere informazioni non necessarie o riservate
    • Configurare timeout e limitare la concorrenza

Contenuti correlati

Altre informazioni su:

  • Last updated on