Spesso mi vengono rivolte domande sulle API ombra e sui parametri API ombra, anche da persone con molta esperienza nello sviluppo di API. Ciò non sorprende più di tanto, perché le API ombra non sono in genere un rischio a cui si pensa nel corso del normale sviluppo di un'API. In realtà, alcuni sono convinti che le API ombra siano in realtà solo una tattica di paura utilizzata dai fornitori di sicurezza per vendere i loro strumenti.
In realtà, però, le API ombra sono relativamente facili da costruire e da usare. Qual è il modo migliore per capirle meglio? Osservando gli esempi del mondo reale! Ecco cosa tratteremo in questo post.
Cosa sono le API ombra?
Cominciamo con questo esempio di richiesta API in cui mi sono imbattuto:
Si tratta di una richiesta a un'API GraphQL per generare la one-time password (OTP) utilizzata per l'autenticazione di un servizio web. Se non si guarda con attenzione, il problema potrebbe non essere individuato, perciò l'ho contrassegnato con una grande freccia rossa. Questo otpDigit Il parametro è in realtà un problema importante.
Ho scoperto che questo parametro è in realtà modificabile tramite l'API. Modificandolo, è possibile regolare la lunghezza della password unica richiesta per l'autenticazione. Quali sono le implicazioni? Sono riuscito a modificare il valore fino a 1. In questo modo il numero di possibilità per la password è passato da un milione a solo 10!
Comprensibilmente, il team di sviluppo si è allarmato quando gli ho detto di questo parametro e l'ha subito corretto. Tuttavia, questo è un esempio perfetto di API ombra e dei loro parametri. Molto probabilmente, questo parametro era una comodità iniziale degli sviluppatori, utilizzata per la prototipazione o il test. Quando l'API è entrata in produzione, il supporto per il parametro non è mai stato rimosso ed è diventato un parametro API ombra.
Senza che qualcuno sondasse questo particolare endpoint per capire cosa si potesse fare con un parametro non documentato, questa grave vulnerabilità non sarebbe stata scoperta. E soprattutto, un team di sviluppo non cercherà con attenzione questo problema finché non gli verrà presentata la vulnerabilità.
Questo esempio getta le basi per una linea guida operativa sugli endpoint e i parametri API ombra: Tutti gli endpoint o i parametri API che non sono direttamente sotto i riflettori dell'attenzione degli sviluppatori esistono nell'ombra e rappresentano un rischio perché il team di sicurezza probabilmente li trascurerà.
Cosa posso fare con le API ombra?
Ora che sapete quali sono gli endpoint e i parametri API ombra, la domanda successiva è cosa potete fare al riguardo. Ovviamente, non si può semplicemente dire al team di sicurezza di essere più vigile, soprattutto per quanto riguarda gli elementi che gli sviluppatori non evidenziano nemmeno nel loro lavoro attivo.
Molto probabilmente avrete bisogno di uno strumento o di un processo che vi aiuti a valutare la sicurezza delle vostre API. Il tipo di strumento necessario dipende dalle dimensioni dell'azienda e dal numero di API distribuite. I gateway API o anche gli strumenti per la sicurezza delle API possono aiutarvi a raggiungere il livello di sicurezza necessario, ma potrebbero essere più di quanto vi serve. Se avete solo alcuni endpoint disponibili per i consumatori di API, l'implementazione di un robusto set di strumenti che tracciano il traffico attraverso il vostro stack e vi avvisano di attività sospette è decisamente eccessiva.
Un approccio più semplice consiste nell'assicurarsi che le API siano ben documentate. Anche questo è un ottimo punto di partenza. Iniziate adottando lo standard OpenAPI per documentare le vostre API. Ricordate che le API ombra nascono quando non si presta attenzione agli endpoint e ai parametri. Lo scopo dello standard OpenAPI è quello di fornire un modello per specificare, e quindi conoscere, ogni endpoint e parametro della vostra API.
Da qui, si può anche richiedere agli sviluppatori di fornire la documentazione dell'API al team di sicurezza al momento della distribuzione. Il team di sicurezza verifica poi l'API rispetto alla documentazione, per individuare eventuali imprecisioni o lacune. In questo modo si eviteranno eventuali punti oscuri.
Conclusione
Le cose non si nascondono nell'ombra se si fa luce in quegli spazi. In fin dei conti, se conoscete i dettagli delle API che avete implementato, le API ombra non possono esistere. Anche se forse non è il compito più entusiasmante del mondo, documentare le API vi aiuterà a evitare di aprirle a malintenzionati.
Ci auguriamo che questo post vi abbia illuminato sulla definizione e sui pericoli delle API ombra. Go fate luce sugli angoli oscuri della vostra infrastruttura API per prevenire le violazioni della sicurezza!
Commenti