È davvero così difficile scrivere un codice sicuro? Probabilmente ti stai ponendo questa domanda ogni volta che ricevi notizie su un’altra vulnerabilità di alto profilo. Tutti parlano dell’importanza della sicurezza delle informazioni e tuttavia i ricercatori della sicurezza continuano a trovare le stesse vulnerabilità, come la recente vulnerabilità di scripting cross-site in Facebook. Abbiamo test di penetrazione, abbiamo SAST, abbiamo DAST – quindi perché esistono ancora le vulnerabilità delle applicazioni web?

Perché non testare solo manualmente?

Chiunque si stia lamentando di un codice insicuro nelle applicazioni di oggi, in realtà, sta ponendo la domanda sbagliata. Sì, scrivere codice sorgente sicuro è difficile, ma è solo una parte di un puzzle molto più grande. La domanda corretta da porsi sarebbe: è davvero così difficile proteggere un’applicazione web? Per molte organizzazioni, la risposta è ancora sì, principalmente perché le vulnerabilità possono apparire in tutte le fasi di sviluppo e implementazione. La sicurezza efficace delle applicazioni Web non riguarda le caselle di spunta, ma deve essere parte integrante del ciclo di vita dello sviluppo del software.
Prima dell’era del dominio del web e dello sviluppo agile, la sicurezza apparteneva alla fase di test, insieme ai test funzionali, ai test di accettazione degli utenti e così via. Questa visione tradizionale della sicurezza del software come un’altra cosa da testare porta a inefficienze che rendono molto più difficile ottenere risultati e correggere realmente le vulnerabilità della sicurezza. Ciò è particolarmente vero negli ambienti DevOps, in cui i processi di sviluppo e operativi sono altamente integrati e automatizzati. Il semplice aggancio a un processo di test di sicurezza convenzionale lo rende un collo di bottiglia delle prestazioni, quindi l’idea di integrare la sicurezza nei flussi di lavoro DevOps, chiamati DevSecOps (o SecDevOps, se si vuole davvero mettere al primo posto la sicurezza).
Oggi vediamo applicazioni web complesse che sono in continuo sviluppo, hanno milioni di utenti e sono costantemente sotto attacco da parte dei criminali informatici. Approcci di sviluppo agili come l’integrazione continua / implementazione continua (CI/CD) vengono utilizzati per tenere il passo con i requisiti in rapida evoluzione, ma i test di sicurezza sono spesso ancora manuali e qualsiasi problema di sicurezza può reggere l’intero processo di distribuzione. Le grandi organizzazioni possono avere dozzine o addirittura centinaia di siti Web e applicazioni Web, rendendo i test di penetrazione manuale troppo lenti e costosi per essere efficaci su vasta scala. Piaccia o no, gli strumenti di sicurezza automatizzati sono la strada da percorrere.

Sicurezza dall’interno: SAST

Il test statico di sicurezza delle applicazioni (SAST) si concentra sull’aiutare gli sviluppatori a scrivere codice sorgente sicuro. Si chiama anche test white-box perché gli strumenti hanno accesso al codice interno. Gli strumenti SAST verificano la vulnerabilità del codice prima che esca dall’ambiente di sviluppo. Quindi, se SAST protegge il codice sorgente, tutti dovrebbero semplicemente usarlo nel processo di sviluppo e non ci sarebbero più vulnerabilità, perché tutto il codice dell’applicazione Web sarebbe sicuro, giusto? Bene, i venditori di utensili SAST vorrebbero sicuramente che tu lo pensassi, ma nel mondo reale le cose sono molto più complicate.

A partire dall’ovvio test di sicurezza del codice sorgente richiede l’accesso al codice sorgente e ciò non è sempre possibile. Le aziende che sviluppano le proprie applicazioni sono solo una parte del mercato del software e ci sono molti casi in cui gli sviluppatori otterranno moduli o librerie esterne senza il codice sorgente. Ad esempio, pensa agli integratori che scrivono codice che interconnette prodotti di terze parti: potrebbero utilizzare strumenti di analisi statica sul proprio codice, ma non avranno accesso (o autorizzazione) per verificare i moduli che stanno integrando.

e soluzioni SAST analizzano il codice sorgente (e / o il codice byte, a seconda dello strumento e della lingua) per trovare costrutti non sicuri che possono portare a vulnerabilità. Tuttavia, poiché lavorano su modelli astratti di flussi di dati e logica applicativa, gli strumenti di analisi statica possono generare molti falsi positivi. Ciò significa lavoro extra per gli sviluppatori, che devono ricontrollare tutti i problemi segnalati, inclusi i falsi allarmi. Sono inoltre necessari strumenti separati per ciascun linguaggio di programmazione. Le moderne applicazioni Web utilizzano spesso più di una lingua, quindi in un’organizzazione con più applicazioni gli strumenti possono diventare molto complicati e costosi.

Se usi gli strumenti SAST dalla prima riga di codice in un progetto greenfield e ti assicuri che tutto il tuo codice funzioni bene con loro, è probabile che tu ottenga ottimi risultati. Ma, ancora una volta, nel mondo reale, molti nuovi progetti software devono integrare routine, librerie o moduli esistenti che potrebbero richiedere molto lavoro per prepararsi all’analisi statica. E se si dispone di applicazioni esistenti e si desidera introdurre test di sicurezza delle applicazioni statiche nei processi di sviluppo attuali, è probabile che si verifichino le stesse sfide su una scala molto più ampia.

Oltre al codice sorgente, un’applicazione Web in esecuzione spesso utilizza librerie o moduli esterni caricati dinamicamente. Questi vengono caricati solo in fase di esecuzione, quindi non possono essere controllati utilizzando strumenti di analisi statica. Molti problemi di sicurezza sono anche causati da errate configurazioni – ancora una volta, qualcosa che può essere rilevato solo in fase di esecuzione.

Se riesci a farlo funzionare, SAST è ottimo per ridurre il numero di vulnerabilità fin dalla fase di programmazione. Vale la pena utilizzare tutto ciò che migliora la sicurezza delle applicazioni Web e ogni toolkit di sviluppo dovrebbe includere almeno strumenti rudimentali per eseguire controlli di sicurezza del codice. Ma stiamo parlando del mondo reale, dove le vulnerabilità si insinueranno nel codice di produzione e nelle distribuzioni delle applicazioni prima o poi. Nel frenetico mondo delle applicazioni Web, l’analisi del codice statico non è sufficiente.

Frugando in una scatola nera: DAST

Il test dinamico di sicurezza delle applicazioni (DAST) viene eseguito su un’applicazione in esecuzione senza accesso al codice sorgente, quindi viene anche chiamato test black-box o test esterno. Il grande vantaggio di DAST è che i test sono indipendenti dai dettagli di implementazione interni: basta scansionare tutto ciò che è accessibile dal web. Ciò è importante perché le moderne applicazioni Web sono miscele estremamente complesse di più tecnologie Web, framework, librerie e risorse. In un’applicazione di grandi dimensioni, pochi sviluppatori (se presenti) conosceranno l’intera base di codice e tutte le dipendenze. Le librerie e i framework open source sono anche ampiamente utilizzati per rendere lo sviluppo di applicazioni più semplice, rapido ed economico, ma cosa succede se hanno vulnerabilità proprie?

L’unico modo realistico per testare completamente la sicurezza di un’applicazione complessa è dall’esterno utilizzando gli strumenti DAST per la scansione automatizzata. Con i test dinamici sulla sicurezza delle applicazioni, non è necessario conoscere i dettagli di implementazione e distribuzione, quindi anche se non si sviluppano le proprie applicazioni, è comunque possibile eseguirne la scansione alla ricerca di vulnerabilità. Questo è anche l’unico approccio per testare le API Web: il back-end di innumerevoli servizi Web e applicazioni mobili.

Nelle grandi organizzazioni con centinaia di siti Web, fare affidamento sui test manuali spesso significa che solo una manciata di siti critici vengono regolarmente testati e mantenuti. Se si prende sul serio la sicurezza delle applicazioni Web su larga scala, la scansione automatica è l’unica soluzione pratica. I professionisti della sicurezza sono spesso diffidenti nei confronti degli strumenti automatizzati perché molti dei primi scanner di vulnerabilità erano imprecisi, segnalando molti falsi positivi o non trovando vulnerabilità esistenti (ovvero generando falsi negativi). Senza risultati affidabili, non è possibile automatizzare i test di sicurezza, perché anche se si automatizza la scansione, qualcuno deve comunque sedersi e controllare manualmente i risultati della scansione.

È qui che Netsparker è in una categoria a sé stante, con la sua tecnologia Proof-Based Scanning™ che fornisce report di vulnerabilità verificati che possono essere risolti direttamente dagli sviluppatori. Quando si ha la prova che le vulnerabilità segnalate sono reali e non falsi positivi, è possibile automatizzare e integrare in modo sicuro strumenti di test dinamici della sicurezza delle applicazioni nel proprio SDLC.

Soluzioni dal mondo reale alle sfide della vita reale

In un mondo perfetto, tutti avrebbero le competenze, il tempo e le risorse per creare software impeccabile. Ma nel mondo reale, dove c’è un software, ci sono dei bug, inclusi i problemi di sicurezza. Con informazioni limitate disponibili in tutte le fasi del ciclo di vita dello sviluppo, l’unico modo pratico per testare la sicurezza di un’intera applicazione Web è dall’esterno.

Il test del codice statico è un ottimo modo per ridurre al minimo il numero di vulnerabilità introdotte nel nuovo codice, ma una volta che un’applicazione di grandi dimensioni è attiva e in esecuzione con tutti i suoi moduli, dipendenze e parametri di configurazione, nessuno può essere completamente sicuro di ciò che sta accadendo all’interno. Le applicazioni web complesse sono scatole nere – motivo per cui i test di sicurezza di queste sono una necessità pratica.

Tratto dall’articolo di Zbigniew Banach dal blog di Netsparker (premi QUI per l’articolo originale)