Le API (Application Programming Interface) rappresentano una parte fondamentale dello sviluppo del software moderno. Consentono infatti alle applicazioni e ai servizi di comunicare tra loro, fornendo un sistema per far interagire tra loro diverse parti del software. Attraverso le API, un singolo servizio di backend è in grado di servire un gran numero di client, inclusi siti Web, applicazioni mobili e persino altri server. Secondo un recente studio di Cloudflare, il tema delle API è diventato talmente rilevante da alimentare una parte significativa di tutto il traffico Web.

Tuttavia, come ogni componente software, le API sono vulnerabili alle minacce per la sicurezza. Secondo il report “The 2022 API Security Trends Report”, realizzato da 451 Research su commissione di Noname Security, il 41% delle organizzazioni ha avuto un incidente di sicurezza legato alle API nel 2022. Di questi incidenti, il 63% ha comportato una violazione o una perdita di dati. Gli hacker possono sfruttare le vulnerabilità delle API per accedere a dati sensibili, interrompere servizi o addirittura assumere il controllo di un intero sistema. Pertanto, è indispensabile predisporre efficaci misure di sicurezza delle API per proteggerle da tali minacce.

La maggior parte delle organizzazioni ha l’esigenza di predisporre una strategia di sicurezza delle applicazioni ma, in realtà, si tratta di un compito più facile a dirsi che a farsi. È sempre più difficile reperire sul mercato persone competenti in tema di sicurezza e, pertanto, le aziende devono spesso provvedere in modo autonomo a formare le risorse sul posto di lavoro. Rendere la sicurezza dei vostri prodotti più visibile agli sviluppatori significa aiutarli, indipendentemente da quale sia il loro livello di competenza. Ogni volta che una vulnerabilità viene individuata, è importante focalizzarsi su come trasformare questo evento in un’opportunità di apprendimento anziché sulla ricerca di responsabilità. Perché, per esempio, non pensare di visualizzare i risultati delle ultime scansioni di sicurezza su uno schermo collocato nell’area break?

Di seguito vengono descritti 4 step per portare la sicurezza delle vostre API a un livello superiore.

1 – Fare un inventario

Partiamo dall’inizio: fare un inventario. Questo aspetto è più importante nel caso delle API rispetto ad altre risorse, perché le API sono spesso nascoste. Come sempre, non si può proteggere ciò che non si sa di avere. E non è sempre scontato che un’API venga utilizzata per fornire funzionalità a un utente finale! Può persino capitare che rimangano endpoint lasciati dal processo di sviluppo, che qualcuno si è dimenticato di rimuovere. L’inventario dovrebbe, pertanto, rappresentare una parte fondamentale di qualsiasi processo di business e l’utilizzo di strumenti per l’individuazione automatica delle API può essere di grande aiuto.

2 – Acquisire familiarità con OWASP Foundation e ASVS

Un’importante risorsa per la sicurezza delle applicazioni è la OWASP Foundation che, tra le altre cose, mantiene costantemente aggiornato OWASP Top 10, un documento standard di “awareness” sulla sicurezza delle applicazioni Web. Questo documento rappresenta una lettura essenziale per tutti gli sviluppatori Web, ma ne esiste anche una versione omologa, meno conosciuta, che riguarda la sicurezza delle API. Questi elenchi delle vulnerabilità più diffuse sono importanti da comprendere perché includono gli errori più comuni che si ripetono continuamente nel settore, indipendentemente dal framework e dal linguaggio utilizzati. Fondamentalmente, questi elenchi evidenziano come la sicurezza sia piuttosto noiosa, a prescindere da ciò che dicono i titoli dei giornali. Prevenire, rilevare e bloccare gli attacchi, infatti, ha più a che fare con una corretta igiene della sicurezza (le cose noiose) che con l’ultima vulnerabilità citata dai titoli dei giornali. Gli elenchi Top 10 sono utili strumenti di apprendimento, ma non sono sfruttabili dai team di sviluppo. A tal fine, bisogna indirizzarsi verso un altro progetto OWASP: l’Application Security Verification Standard (ASVS). Questo progetto fornisce agli sviluppatori diversi criteri “pass/fail” rispetto ai quali poter confrontare le proprie API.

L’ASVS può anche adattarsi a diverse esigenze, a seconda del livello di sicurezza desiderato dell’applicazione:

• Livello 1, associato a un basso livello di sicurezza per fornire protezione dagli attacchi di base;
• Livello 2, quello più comune, che richiede la predisposizione di controlli di sicurezza efficaci;
• Livello 3, riservato alle applicazioni più critiche e che richiede test più approfonditi rispetto ai livelli inferiori.

3 – Integrare il “penetration testing”

L’ASVS ci porta direttamente al prossimo elemento essenziale della sicurezza delle API: i penetration test. L’intervento di un esperto consente di svolgere un’analisi approfondita e di scoprire problemi difficili da individuare in altri modi. L’ASVS incoraggia fortemente l’uso di strumenti automatizzati, ma anche questo non basta. I diversi livelli impongono requisiti differenti per le fasi di test. In teoria, un’applicazione ASVS di Livello 1 può essere testata in modo “black box”, mentre gli altri livelli richiedono maggiori informazioni, quali documentazione, codice sorgente, configurazione e così via. In ogni caso, è sempre raccomandabile eseguire i test con il maggior numero di risorse possibile. Inoltre, il valore di un penetration test dipende dal modo in cui viene gestito. Bisogna chiedersi, per esempio, se ai tester viene assegnato l’ambito corretto, se hanno a disposizione un tempo sufficiente per completare i test e se dispongono di tutta la documentazione necessaria.

4 – Utilizzare strumenti di scansione della sicurezza statica e dinamica (SAST e DAST)

La raccomandazione finale è quella di utilizzare strumenti per la scansione della sicurezza. Un’API è definita attraverso uno Schema, ovvero un file di testo leggibile dalla macchina che descrive tutti gli endpoint, quali metodi supportano, quali dati si aspettano e come questi vengono restituiti. Questo Schema può essere definito prima dello sviluppo dell’applicazione oppure generato a posteriori. In ogni caso, se studiate lo Schema, potreste imparare cose che non sapevate sulla vostra applicazione. Forse ci sono alcuni endpoint che vi sono sfuggiti nella fase di inventario oppure noterete che un codice di stato è impostato sul valore sbagliato. Queste sono solo alcune delle scoperte relative alla sicurezza che si possono fare. Studiare lo Schema manualmente può essere noioso ed è, pertanto, utile sapere che esistono strumenti che possono aiutare gli sviluppatori a lavorare in modo più efficiente.

Dopo lo studio dello Schema è il momento di eseguire la scansione della sicurezza ed è consigliabile iniziare con un test statico di sicurezza delle applicazioni (SAST). Si tratta di un test dall’interno all’esterno (inside-out) che analizza il codice sorgente e che aiuta a garantire che i metodi siano chiamati nel modo giusto, che il framework sia configurato correttamente e che sia possibile controllare i flussi di dati interni. Il SAST può e deve essere eseguito fin dall’inizio: è consigliabile iniziare quando si scrive la prima riga di codice. Testando in anticipo, si individuano i bug quando sono facili da correggere e non si è ancora consolidata completamente l’architettura. Il SAST è particolarmente indicato per individuare gli attacchi di tipo “injection”.

Non appena l’applicazione è in grado di operare autonomamente è necessario aggiungere un test di sicurezza dinamico (DAST). Questo è un test che opera dall’esterno verso l’interno (outside-in) inviando all’API richieste create appositamente e verificando la risposta, simulando così diversi tipi di attacco. Il DAST è un test olistico che interviene su tutto l’ecosistema, che permette di individuare i bug di autenticazione presenti sia nella OWASP Top 10 sia nella API Top 10. Va tenuto presente che uno scanner DAST necessita dello Schema API di cui abbiamo parlato in precedenza, per cui è bene accertarsi di averlo pronto per poter avviare la scansione.

Non bisogna, infine, dimenticare di sfruttare tutti gli strumenti esistenti. Per esempio, se le vostre API sono fornite da un cloud provider è utile utilizzare le funzioni di sicurezza già disponibili: la limitazione al numero di tentativi autenticazione falliti, i firewall per applicazioni Web, la registrazione degli audit, l’autenticazione forte e altre ancora.

I penetration test offrono il miglior livello di protezione ma sono costosi e richiedono molto tempo. Pertanto, è importante che i tester si concentrino sulla parte più importante dell’applicazione. Le scansioni di sicurezza automatizzate permettono di individuare e risolvere la maggior parte dei problemi prima ancora che il penetration test abbia inizio.

Gli scanner di alta qualità permettono anche di integrare SAST e DAST all’interno dell’ambiente IDE, consentendo di ottenere un feedback immediato mentre viene scritto il codice, migliorandone la sicurezza.

Ricordate: nessuno strumento può sostituire completamente un penetration test, ma potrebbe consentirvi di eseguire test completi meno spesso e di risparmiare denaro.

In sintesi

Garantire la sicurezza delle API può essere un processo lungo, ma il modo migliore per iniziare è quello di compiere il primo passo.

Abbiamo esaminato molti punti di partenza da prendere in considerazione. Sapete quali API avete e chi le possiede? State seguendo una metodologia come l’ASVS e state eseguendo correttamente i test di penetrazione?

Strumenti sofisticati di scansione della sicurezza come quelli presenti nel portafoglio Fortify di OpenText vi aiuteranno a eseguire test automatizzati e a integrarvi facilmente in un flusso di lavoro DevSecOps, consentendovi di effettuare rilasci rapidi e frequenti in assoluta sicurezza.

Se volete saperne di più scaricate gratuitamente la Guida alla sicurezza delle API per gli sviluppatori

A cura di Stefano Di Capua, Presales Manager, OpenText Cybersecurity

https://www.ictsecuritymagazine.com/notizie/i-4-step-per-portare-la-sicurezza-api-a-un-livello-superiore/