API e sicurezza: quali sono le vulnerabilità più comuni?

Una API, Application Programming Interface, fornisce a sviluppatori e proprietari di siti web codice sorgente da applicazioni già esistenti: molto semplicemente li aiuta a velocizzare il proprio lavoro, poiché consente di riutilizzare lo stesso codice per esigenze specifiche, integrandolo nelle funzioni aziendali e nei siti web esistenti per migliorare l'esperienza dell'utente, anziché doverlo scrivere da zero. 

Essendo strumenti ormai essenziali per ogni business online sono divenuti, come ogni cosa essenziale, un bersaglio privilegiato per i cyber attaccanti. Disporre del codice necessario per attaccare e violare una API è molto profittevole per un cyber attaccante, perché molto probabilmente potrà eseguire lo stesso attacco in tutti i siti o applicativi che utilizzano quella data API. Ma quali sono le più comuni vulnerabilità presenti nelle API e le modalità con cui solitamente sono attaccate? Quali rischi corrono gli utenti che utilizzano siti web o web app contenenti API?

Code Injection
Questo è uno dei sistemi di attacco contro le API più usato in assoluto, per "requisire" una API e fargli fare ciò che si vuole.  Tra i "code injection" più comuni troviamo SQl, XML, RegEX: pezzi di codice sono iniettati nell'API al fine di far eseguire operazioni dannose come  la condivisione dei dati sensibili degli utenti, credenziali e password, ma anche per installare malware e spyware sui dispositivi. Solitamente, la presenza della funzione base64_decode all'inizio di uno script è un comune segnale di script injection. 

Fonte: https://www.hackread.com

La sicurezza di una API di fronte ad attacchi di questo tipo è verificabile tramite test manuale e controlli intensivi delle query. 

Replay Request Attack
Questa vulnerabilità riguarda in modo specifico quelle API che permettono di effettuare richieste a ripetizione e ciò avviene quando un'API non è progettata per proibire ulteriori richieste effettuate dopo che è già stata rifiutata una prima richiesta inaffidabile o insicura. E' in realtà molto comune che le API siano così disegnate: sono si capaci di negare con successo una prima, sospetta richiesta, ma non sono in grado di impedire ad un eventuale attore malintenzionato di effettuare continue e differenti richieste.

Questa tipologia di attacchi di brute-forcing è comunemente usata per sondare le vulnerabilità. E' possibile mitigare i rischi utilizzando l'autenticazione HMAC, usando l'autenticazione a più fattori o usando token di accesso OAuth di minor durata. 

Falsa richiesta cross-site (CSRF o XSRF)
Questa tipologia di attacco si verifica quando un attaccante tenta di usare una applicazione web autenticata (come una API) per operazioni quali l'alterazione di un indirizzo email o per l'invio di denaro da un account bancario ad un altro senza che l'utente ne possa venire a conoscenza. 

E' una tipologia di attacco ad oggi meno usata, ma che è stata molto popolare per anni: hanno fatto storia gli attacchi Cross-Site Request Forgery (CSRF) contro ING Direct, Youtube, New York Times ecc... accaduti nell'arco di poco tempo, misero gli attaccanti perfino nella condizione di trasferire liberamente soldi. 

La modalità più comune tramite la quale le API sono prese di mira con attacchi CSRF prevede l'uso di token generati dal server che vengono inseriti nel codice HTML come "campi nascosti". Questi sono restituiti al server ogni volta che viene effettuata una richiesta, così il server può determinare se una determinata richiesta provenga da una fonte affidabile o meno. 

Broken User Authentication
Purtroppo spesso, coloro che creano le API non si preoccupano di assicurarsi del fatto che i meccanismi di autenticazione funzionino correttamente: è strano a dirsi, ma molto spesso le API sono vulnerabili proprio perché viene posta scarsa attenzione al momento dell'autenticazione dell'utente. Al che è gioco facile, per un attaccante, assumere l'identità di un utente autenticato. Ovviamente il protocollo di autenticazione OAuth è molto utile per mitigare i rischi, ma c'è anche un'altra soluzione che viene spessissimo utilizzata dagli sviluppatori, ovvero l'uso del timestamp delle richieste.

Questo può essere aggiunto in un header HTTP personalizzato in ogni richiesta API, obbligando poi il server a comparare il timestamp corrente e quello della richiesta. L'autenticazione sarà valida solo se il server concluderà che entrambi  timestamp sono entro un paio di minuti l'uno dall'altro.