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

Nota

Questo articolo è stato aggiornato per riflettere l'elenco top 10 della sicurezza delle API OWASP più recente 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. In questo articolo vengono illustrati i suggerimenti più recenti per attenuare le prime 10 minacce api identificate da OWASP nell'elenco 2023 usando Azure Gestione API.

Anche se Gestione API 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 interrotto

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 send-request.

  • Per gli scenari GraphQL, applicare l'autorizzazione a livello di oggetto tramite i criteri validate-graphql-request , usando l'elemento authorize .

Autenticazione interrotta

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

Altre informazioni su questa minaccia: API2:2023 Autenticazione interrotta

Consigli

  • Usare Microsoft Entra per implementare l'autenticazione API. Microsoft Entra fornisce automaticamente endpoint di accesso protetti, resilienti e distribuiti geograficamente. Usare i criteri validate-azure-ad-token per convalidare i token di Microsoft Entra nelle richieste API in ingresso.
  • Se è necessaria l'autenticazione, Gestione API supporta la convalida di token OAuth 2, autenticazione di base, certificati client e chiavi API.
    • Verificare la configurazione corretta dei metodi di autenticazione. Ad esempio, impostare require-expiration-time e require-signed-tokens su true quando si convalidano i token OAuth2 usando il criterio validate-jwt .
  • La limitazione della frequenza può essere usata per ridurre l'efficacia degli attacchi di forza bruta.
  • Il filtro IP client può essere usato per ridurre la superficie di attacco. I gruppi di sicurezza di rete possono essere applicati alle reti virtuali integrate con Gestione API.
  • Se possibile, eseguire l'autenticazione ai back-end da Gestione API tramite protocolli sicuri e gestione delle identità gestite o delle credenziali per l'autenticazione ai back-end.
  • Assicurarsi che i token o le chiavi vengano passati nelle intestazioni e non negli URL per le richieste in ingresso a Gestione API e richieste in uscita ai back-end.
  • Usare Microsoft Entra per proteggere l'accesso al portale per sviluppatori di Gestione API.

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 sviluppate nel tempo, le interfacce di richiesta e risposta contengono più campi dati rispetto alle applicazioni che utilizzano, abilitando gli attacchi di inserimento dei dati. Gli utenti malintenzionati possono anche individuare interfacce non documentate. Queste vulnerabilità potrebbero restituire dati sensibili all'utente malintenzionato.

Altre informazioni su questa minaccia: API3:2023 Broken Object Property Level Authorization

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 interna. 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 Gestione API può essere usata con uno schema XML o JSON per bloccare le risposte con proprietà non documentate o valori non validi. 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 validate-content supportano anche il blocco delle risposte che superano una dimensione specificata.
  • Usare il criterio validate-status-code per bloccare le risposte con errori non definiti nello schema dell'API.
  • Usare il criterio validate-headers per bloccare le risposte con intestazioni non definite nello schema o non conformi alla definizione nello schema. Rimuovere le intestazioni indesiderate con il criterio set-header .
  • Per gli scenari GraphQL, usare i criteri validate-graphql-request 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 in base alla richiesta). L'applicazione dei limiti consente di proteggere le API da un consumo eccessivo di risorse.

Altre informazioni su questa minaccia: API4:2023 Unrestricted Resource Consumption

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 agli endpoint sensibili, ad esempio la reimpostazione della password, l'accesso o le operazioni di iscrizione o gli endpoint che utilizzano risorse significative.
  • Usare i criteri 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 nei criteri validate-content per applicare la dimensione massima delle richieste e delle 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-parameters e validate-headers per applicare tali schemi per le richieste e le risposte.
    • Usare i criteri validate-graphql-request per le API GraphQL e configurare max-depth e max-size parametri.
    • Configurare gli avvisi in Monitoraggio di Azure per un consumo eccessivo di dati da parte degli utenti.
  • Per le API di intelligenza artificiale generative:
    • Usare la memorizzazione nella cache semantica per ridurre il carico nei back-end.
    • Usare la limitazione dei token per controllare il consumo e i costi.
    • Generare metriche relative all'utilizzo dei token per monitorare l'utilizzo dei token e configurare gli avvisi.
  • Ridurre al minimo il tempo necessario per rispondere a un servizio back-end. Più tempo il servizio back-end richiede di rispondere, maggiore è la quantità di connessione occupata in Gestione API, 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 jolly (*) nei criteri CORS.
  • Sebbene Azure disponga sia della protezione a livello di piattaforma che della protezione avanzata dagli attacchi DDoS (Distributed Denial of Service), la protezione delle applicazioni (livello 7) per le API può essere migliorata distribuendo un servizio di protezione bot davanti a Gestione API, ad esempio app Azure lication Gateway, Azure Frontdoor o Protezione DDoS di Azure. Quando si usano criteri web application firewall (WAF) con app Azure lication Gateway 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 poco 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: AUTORIZZAZIONE a livello di funzione interrotta API5:2023

Consigli

  • Per impostazione predefinita, proteggere tutti gli endpoint API in Gestione API 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 Microsoft Entra. Specificare tutte le attestazioni necessarie e, se applicabile, specificare 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.
    • Monitorare ed esaminare le 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 dagli indirizzi IP autorizzati.
  • Usare i criteri validate-client-certificate per applicare che un certificato presentato da un client a un'istanza di Gestione API corrisponda alle regole di convalida e alle attestazioni specificate.

Accesso illimitato ai flussi aziendali sensibili

Le API possono esporre un'ampia gamma di funzionalità all'applicazione che usa. È importante che gli autori di API comprendano i flussi aziendali forniti dall'API e la sensibilità 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 di business sensibili

Consigli

  • Ridurre o bloccare l'accesso in base alle impronte digitali del client. Ad esempio, usare i criteri 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 Gestione API con app Azure lication Gateway o il servizio Protezione DDoS di Azure per rilevare e bloccare il traffico del bot.

Richiesta lato server falsi

Una vulnerabilità di richiesta lato 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: API7:2023 Richiesta lato server Forgery

Consigli

  • Se possibile, non usare gli URL forniti nei payload del client, ad esempio come parametri per GLI URL back-end, i criteri send-request o rewrite-url .
  • Se Gestione API o i servizi back-end usano gli URL forniti nel payload della richiesta per la logica di business, definire e applicare un elenco limitato di nomi host, porte, tipi di supporti o altri attributi con criteri in Gestione API, ad esempio le espressioni di criteri e criteri di scelta.
  • Definire l'attributo timeout nei criteri forward-request e send-request .
  • Convalidare e purificare i dati delle richieste e delle risposte 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à non 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, il criterio validate-azure-ad-token offre un modo più completo e semplice per convalidare i token di sicurezza.
    • 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 negli 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 validate-client-certificate. 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 validate-graphQL-request . 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 Azure 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.
  • Assicurarsi che le API richiedano chiavi di sottoscrizione, anche se tutti i prodotti sono configurati per richiedere chiavi di sottoscrizione. Ulteriori informazioni
  • Richiedere l'approvazione della sottoscrizione per tutti i prodotti ed esaminare attentamente tutte le richieste di sottoscrizione.
  • Usare l'integrazione di Key Vault per gestire tutti i certificati. Questo consente di centralizzare la gestione dei certificati e 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.
  • 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 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.

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 Gestione API per gestire le modifiche dell'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. Assicurarsi che i controlli di sicurezza siano implementati in tutte le versioni API disponibili.
  • Separare gli ambienti, ad esempio sviluppo, test e produzione, con diversi servizi di Gestione API. Assicurarsi che ogni servizio 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.
  • 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 per l'utilizzo 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.
  • Usare il Centro API di Azure per gestire un inventario completo e centralizzato di API, versioni e distribuzioni, anche se le API non sono gestite in Azure Gestione API.

Uso non sicuro delle API

Le risorse ottenute tramite integrazioni downstream tendono a essere più attendibili rispetto all'input dell'API del chiamante o dell'utente finale. Se non vengono applicati gli standard di pulizia 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 Uso non sicuro delle API

Consigli

  • È consigliabile usare Gestione API per fungere da facciata per le dipendenze downstream integrate dalle API back-end.
  • Se le dipendenze downstream vengono front-end con Gestione API o se le dipendenze downstream vengono utilizzate con un criterio di richiesta di invio in Gestione API, usare le raccomandazioni di altre sezioni di questa documentazione per garantire il consumo sicuro e controllato, tra cui:
    • Assicurarsi 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 conformi alla specifica API usando i criteri validate-content e validate-header
    • Trasformare le risposte con i criteri set-body, ad esempio per rimuovere informazioni non necessarie o riservate
    • Configurare timeout e limitare la concorrenza

Contenuto correlato

Altre informazioni su: