Ogni pull request L'aggiunta o la modifica di un endpoint altera la superficie di attacco della tua API. La maggior parte degli strumenti di sicurezza delle API non se ne accorge finché l'endpoint non è attivo e non inizia a ricevere traffico. A quel punto, la soluzione non è più una semplice modifica di una riga di codice durante una revisione, ma richiede un'intera discussione in sede di risposta agli incidenti.
La sicurezza delle API è la pratica di individuare e neutralizzare i rischi relativi al modo in cui un'applicazione espone i propri endpoint: chi può richiamarli, quali dati restituiscono e se effettivamente svolgono la funzione descritta nella documentazione.
La maggior parte degli strumenti sviluppati per risolvere questo problema testa l'API in fase di esecuzione, dall'esterno, nello stesso modo in cui farebbe un attaccante. Questo approccio funziona, ma solo dopo che l'API è stata distribuita. Xygeni segue il percorso precedente: legge il codice sorgente e le specifiche dell'API prima ancora che una singola richiesta raggiunga l'endpoint.
I quattro modi per testare un'API e a cosa risponde ciascuno di essi
La maggior parte dei programmi maturi ne utilizza più di uno:
- Prova statica Analizza il codice sorgente e le specifiche API prima della distribuzione. Risponde alla domanda "cosa abbiamo appena esposto?". Questo è l'approccio su cui si concentra questo articolo.
- Test dinamici (DAST) Invia traffico reale a un'API in esecuzione e osserva come risponde. Risponde alla domanda: "Cosa è effettivamente raggiungibile e sfruttabile in questo momento?"
- fuzzing Invia input non validi o inattesi agli endpoint per far emergere arresti anomali e guasti in casi limite. Risponde alla domanda "cosa si rompe con un input che non avevamo previsto?"
- Test di penetrazione manuale Aggiunge il giudizio umano per individuare falle logiche che gli strumenti automatizzati non rilevano. Risponde alla domanda: "Quali azioni concatenarebbe un attaccante esperto?"
Nessuno di questi sostituisce gli altri. Rispondono a domande diverse in momenti diversi del ciclo di vita, e la lacuna che la maggior parte dei programmi presenta riguarda proprio la prima.
Perché la maggior parte degli strumenti di sicurezza delle API individua il rischio troppo tardi
I test di sicurezza delle API in fase di esecuzione inviano traffico a un'applicazione in produzione e ne osservano la risposta. Si tratta di un livello di sicurezza legittimo e necessario. Tuttavia, per sua stessa natura, è anche un indicatore ritardato: un endpoint deve esistere, essere distribuito ed essere raggiungibile prima che uno scanner in fase di esecuzione possa fornire informazioni al riguardo. Qualsiasi vulnerabilità rilevata era già esposta per tutto il tempo necessario all'esecuzione della scansione.
C'è una seconda lacuna alla base di questo problema di tempistica. Gli strumenti di runtime possono testare solo ciò che sanno esistere. Se un endpoint non è mai stato documentato, o se le specifiche OpenAPI sono diventate obsolete nel momento stesso in cui qualcuno ha rilasciato una nuova rotta, uno scanner di runtime non ha modo di sapere che esiste. Testa la mappa, non il territorio.
Il test di sicurezza statico delle API colma entrambe le lacune spostando il controllo dove è definito l'endpoint: nel tuo codice e nella tua specifica API, prima della distribuzione. Lo stesso pull request che introduce un punto finale è il pull request che mette in luce il suo rischio.
Cosa significa realmente la sicurezza statica delle API
Xygeni crea il tuo inventario API a partire da due fonti: il codice sorgente della tua applicazione e le specifiche API, inclusi OpenAPI e Swagger.
Un inventario basato solo sulle specifiche mostra gli endpoint che qualcuno si è ricordato di documentare. Un inventario basato solo sul codice mostra ciò che esiste, ma non necessariamente come avrebbe dovuto essere utilizzato. Leggere entrambi fornisce un quadro completo: gli endpoint documentati dai vostri team e quelli che nessuno ha documentato.
Quell'inventario è il fondamento su cui si basa tutto il resto:
- API totali scoperte e risorse a rischio misurate rispetto a una linea di base
- Endpoint suddivisi per metodo HTTP
- Problemi raggruppati per servizio
- Ogni endpoint con il relativo metodo, percorso, servizio, modulo, stato di autenticazione e punteggio di rischio.
I vostri responsabili tecnici possono visualizzare la struttura della vostra API senza dover aprire un singolo ticket.
Ogni endpoint trovato da Xygeni, con il relativo metodo, stato di autenticazione e punteggio di rischio, è stato ricostruito a partire dal codice e dalle specifiche.
Production note Ritaglia il pannello di triage AI da qualsiasi screenshot di API Security.
Mappato alla Top 10 di sicurezza delle API di OWASP
I risultati rispecchiano il framework già utilizzato dai vostri team di sicurezza e dai vostri revisori. Xygeni rileva i rischi in tutta la sicurezza delle API OWASP. Primi 10 (2023):
Una categoria è volutamente assente. L'API6, Accesso illimitato ai flussi aziendali sensibili, richiede la comprensione di ciò che un processo aziendale dovrebbe consentire, e nessun analizzatore statico lo rileva in modo credibile. Qualsiasi fornitore che affermi il contrario vi sta vendendo una casella da spuntare. Questa rimane di competenza del vostro threat modeling e dei vostri penetration tester.
Non tutti i risultati sono uguali: sensibilità dei dati e combinazioni tossiche
Un elenco generico di risultati tratta un endpoint di controllo dello stato di salute non autenticato allo stesso modo di un endpoint non autenticato che restituisce i dati dei clienti. Non si tratta dello stesso problema e un modello di prioritizzazione che li valuta in modo identico abitua i team a ignorare l'elenco.
Xygeni classifica i dati gestiti da ciascun endpoint, contrassegnando PII, PCI e PHI nei parametri di richiesta e nelle risposte, e li associa allo stato di autenticazione dell'endpoint.
Inoltre, correla i risultati che si verificano sullo stesso endpoint e ne aumenta la gravità quando si sommano. Una fuga di dati personali in una risposta è di per sé un problema grave. La stessa fuga di dati su un endpoint che non richiede autenticazione è critica e la piattaforma la classifica di conseguenza, anziché lasciare che la connessione venga rilevata manualmente.
Endpoint zombie e orfani: la deriva tra codice e specifiche
Poiché Xygeni legge il tuo codice e la specifica API in parallelo, individua le discrepanze. Queste discrepanze si manifestano attraverso tre schemi riconoscibili:
- Endpoint non documentati. Risiedono nel codice e non sono mai stati aggiunti alle specifiche.
- Endpoint zombie. Sono contrassegnati come obsoleti o ritirati, ma sono comunque raggiungibili.
- Endpoint orfani. Nessuno dei membri attuali del team ne è il proprietario.
Nessuno di questi elementi compare in un inventario basato solo sulle specifiche, perché le specifiche indicano esattamente ciò che manca.
Prove su cui agire, non un pretesto per avviare un'indagine.
Ogni rilevamento indica con precisione il gestore responsabile: il file, la classe, il metodo e la riga specifica che ha introdotto la vulnerabilità, con il codice incriminato visualizzato accanto. Ciascuno riporta anche il suo livello di gravità, la categoria OWASP API Security Top 10, il codice CWE, lo stato di autenticazione dell'endpoint e la classificazione di sensibilità dei dati coinvolti.
Un problema che si limita a indicare un endpoint costringe uno sviluppatore a scandagliare il codice prima ancora di poter iniziare a correggere qualcosa. Un problema che indica la riga di codice lo porta immediatamente al punto in cui intervenire.
I risultati vengono esportati come JSON, CSV, Markdown e SARIF 2.1.0, quindi finiscono nel tstrumenti che i vostri team già utilizzano.
Il gestore, la riga e il codice che hanno causato l'esposizione. Non un ticket da indagare.
Perché questo prodotto è disponibile su un'unica piattaforma e non su un'altra console.
Xygeni esegue API Security insieme SAST, SCA, Sicurezza dei segreti, IaC and DAST all'interno di un'unica piattaforma, correlata attraverso ASPM, invece di spedirlo come strumento separato con il suo login e il suo arretrato.
Questo è importante perché i risultati statici e quelli in tempo reale rispondono a domande diverse sullo stesso endpoint e sono più utili insieme che separatamente. L'analisi statica indica se un endpoint è rischioso prima del rilascio. DAST conferma cosa è effettivamente raggiungibile e sfruttabile una volta che è in esecuzione.
Dividendo il problema su due console, il rischio correlato si trasforma in due backlog non correlati. Nessuno li unisce e l'endpoint, che non è documentato né autenticato, non finisce in nessuna delle due code.
Visualizza la reale superficie di attacco delle tue API. La sicurezza API è disponibile come Enterprise Si tratta di un componente aggiuntivo per la piattaforma Xygeni, che esegue una scansione dei repository all'interno della propria infrastruttura.
FAQ
È in grado di individuare quali endpoint gestiscono dati sensibili?
Sì. Xygeni segnala PII, PCI e PHI nei parametri e nelle risposte degli endpoint e utilizza tale classificazione per classificare i risultati in base all'esposizione reale.
Può funzionare su ogni pull request?
Sì. La scansione incrementale analizza solo gli endpoint che sono cambiati e il manifesto che produce può focalizzare una successiva scansione DAST su quegli stessi endpoint, in modo che i test statici e in tempo reale rimangano allineati a ciò che è stato effettivamente modificato.
Il mio codice esce dal mio ambiente?
No. Le scansioni vengono eseguite nella vostra infrastruttura. Solo i risultati vengono caricati, protetti durante il trasferimento e a riposo.
Come posso ottenere la sicurezza API?
La sicurezza API è disponibile come Enterprise Componente aggiuntivo. Richiedi una prova di concetto (PoC) e la definiremo insieme a te.
