Vulnerabilità open source nello sviluppo web

Photo by Nahel Abdul Hadi on Unsplash

Hai appena ricevuto un'email: una delle tue web application è stata violata. I dati dei tuoi clienti sono trapelati e le chiavi crittografiche sono sparite. Le autorità stanno arrivando nella tua azienda. Sei pronto per il Messico? È in quel momento che ti svegli di colpo. Era solo un incubo, ma potrebbe diventare realtà. Quindi, se la tua web application è già in produzione, è arrivato il momento di un audit di sicurezza.

Esistono molte filosofie e pratiche per sviluppare una web application: il K.I.S.S. (Keep It Simple, Stupid), il Security-By-Design, il Privacy-By-Design e così via. Tutte queste strategie e pratiche sono state ideate per mantenerti concentrato durante la fase di sviluppo della web application.

Per esempio, l'arrivo del GDPR in Europa ha stravolto il processo di sviluppo e le pratiche di molti sviluppatori e aziende. Gli sviluppatori non si concentravano sempre su privacy e sicurezza, mentre ora questi principi vengono regolarmente considerati durante il processo di sviluppo.

In questo articolo parleremo dei diversi modi in cui puoi migliorare la sicurezza del tuo software. Discuteremo anche di strumenti e di come puoi usarli per progettare un framework di sicurezza più robusto nel tuo processo di sviluppo.

Le vulnerabilità sono dietro l'angolo

Esistono molti approcci per mettere in sicurezza una web application, anche senza un security engineer. A seconda delle tue risorse, puoi farlo in uno dei seguenti 5 modi. Puoi implementarli in qualche combinazione, oppure puoi adottarli tutti.

1. Design review: mentre progetti l'architettura dell'applicazione, dovresti considerare anche tutte le possibili minacce alla tua applicazione e progettare il sistema in modo che sia resiliente.
2. Whitebox security review (code review): a meno che tu non sia un security engineer e stia progettando e scrivendo il codice del tuo progetto completamente da solo, questo passo dovrebbe essere svolto in coppia, con un security engineer che cerca falle nel tuo codice. Anche se sei un security engineer, avere una seconda opinione non è una cattiva idea.
3. Blackbox security audit: prendi il tuo codice sorgente e mettilo da parte. Poi esegui la web application e verifica se è sicura durante l'uso. Puoi anche lasciare che lo faccia qualcun altro. Lasciare che siano altre persone a fare l'audit della tua applicazione migliorerà l'analisi, escludendo i bias inconsci che avrai durante i test.
4. Automated tooling: questo è uno dei miei preferiti. Esistono molti strumenti progettati per scansionare il tuo codice alla ricerca degli errori più comuni, di pattern o di problemi legati alla sicurezza, anche mentre stai sviluppando il tuo progetto.
5. Coordinated vulnerability platform: questo metodo è semplice ma potente. Una volta terminati i tuoi test e i tuoi audit, puoi pagare un'azienda altamente specializzata di hacker white-hat perché attacchi la tua web application e produca un report sui suoi bug, sulle sue falle e sui suoi problemi.

Ora sai quali passi puoi compiere per rendere sicuro il tuo software, ma cosa succede se vuoi provare a scrivere un "software con meno bug"?

La conoscenza è potere: risorse e strumenti

Approfondiamo per un attimo il primo passo, la fase di design. Durante la progettazione, puoi consultare alcune risorse famose come la OWASP (Open Web Application Security Project) Top Ten per sapere quali sono i rischi più comuni nella sicurezza delle web application. Per esempio, il primo rischio nella sicurezza delle web application, secondo la OWASP Foundation, sono le injection flaws.

Prendiamoci una pausa e analizziamo cosa sono le injection usando il linguaggio SQL. Secondo il sondaggio per sviluppatori StackOverflow del 2020, SQL è uno dei linguaggi di query più usati oggigiorno, il che lo rende il terzo linguaggio più usato in ambito professionale (statistiche estratte sulla base di 47.000 sviluppatori professionisti).

Considera uno snippet di codice come questo:

Dai un'occhiata a questo snippet di codice

Come puoi vedere, gli input vengono passati direttamente al motore SQL senza un binding o un escaping adeguati. Usando un attacco error-based, un attaccante può scoprire informazioni sensibili sull'architettura su cui gira il tuo codice oppure piazzare una reverse shell usando le procedure SQL per salvare file!

Questo è ovviamente lo scenario peggiore, ma non vuoi trovarti nemmeno vicino a una situazione del genere. Se non conoscevi questo tipo di injection, corri al primo terminale che hai a portata di mano e sistema tutto il più velocemente possibile!

Passiamo ora a un altro tipo di validazione. Diamo un'occhiata allo Static Application Security Testing (SAST), che rappresenta il quarto punto della nostra checklist. Questo metodo consiste nell'usare strumenti per testare la sicurezza del tuo codice o dell'intero progetto.

Vediamo qualche esempio. Se hai un progetto composer, puoi usare uno strumento come Local PHP Security Checker. È uno strumento a riga di comando che fa l'audit delle dipendenze della tua applicazione e verifica se qualcosa da cui dipendi è compromesso oppure ha falle o bug noti (non è sempre colpa tua, anche le tue dipendenze possono essere il tuo punto debole).

Oppure puoi usare qualcosa come Phan per fare l'audit della tua applicazione e verificare cose che vanno dalle deprecazioni agli accessi non sicuri. E se stai usando un framework, dovresti dare un'occhiata a strumenti specializzati come Larastan per Laravel.

Photo by Pankaj Patel on Unsplash

Se sei nel mondo del coding da abbastanza tempo, avrai probabilmente capito che tutto questo processo di validazione può diventare rapidamente un incubo su progetti grandi, dove più di 3 sviluppatori si parlano tra loro e usano gli stessi stili e convenzioni di codice. E anche se usi un repository git con una policy di commit rigida, questa può essere facilmente aggirata con un forced push che ignora gli hook.

Quindi, se non puoi controllare le policy in locale o spostare la policy altrove, puoi usare app gratuite come WhiteSource Bolt per scansionare il tuo codice push dopo push e aprire automaticamente una issue non appena spunta fuori un bug comune dal tuo codice. Bolt è uno strumento gratuito pensato per aiutarti a trovare e correggere le vulnerabilità open source. Gli sviluppatori poliglotti saranno probabilmente i più entusiasti di questo strumento, perché supporta un sacco di linguaggi.

Se sei uno sviluppatore di software embedded che scrive codice C di giorno e uno sviluppatore web che scrive codice PHP di notte, puoi usare un unico strumento e fare l'audit di tutti i tuoi repository.

Conclusione

Ora che conosci alcune delle best practice che puoi adottare per mettere in sicurezza la tua web application, tutto dipende da te. Ricorda: dedicare più tempo alla sicurezza durante il processo di sviluppo può ridurre in modo significativo il tempo che spenderai più avanti in produzione. Non perdere di vista i problemi che puoi affrontare non correggendo issue comuni che sono risolvibili con un analizzatore statico.

Metti sempre la sicurezza al primo posto quando progetti software, soprattutto web application, per te e per un internet migliore!