10 regole per scoprire se le tue applicazioni web sono sicure

Trainer Secure Coding

L’applicazione è finalmente pronta, tutti i bug funzionali sono stati risolti, il caricamento delle pagine è rapido e gli sviluppatori sono riusciti ad inserire tutte le feature richieste.

Evviva!

Tuttavia, a distanza di qualche settimana arriva la brutta notizia: siete stati hackerati.

Le informazioni sensibili dei vostri utenti, segreti aziendali e personali vengono resi pubblici: il danno economico e di immagine è enorme.

Questo scenario, che un tempo poteva sembrare fantascienza, è al giorno d’oggi una comune e dura realtà: secondo un report di Gartner, il 66% delle applicazioni web sono vulnerabili.

Tra le aziende che hanno subito attacchi informatici negli anni recenti, è possibile trovare nomi illustri quali Google, Facebook, Yahoo, PayPal e tante altre importanti società del settore.

Il problema non è se la vostra applicazione verrà attaccata, ma quando!

Sebbene in fase di testing finale dell’applicazione sia sempre consigliabile l’esecuzione di un penetration test da parte di un gruppo esterno di ethical hacker, esistono alcune linee guida che possono essere applicate dal team di sviluppo per minimizzare il rischio di un attacco o mitigarne il relativo impatto.

Esse sono basate in parte sulla OWASP Top 10, che rappresenta una lista delle 10 vulnerabilità di sicurezza più comunemente presenti nelle applicazioni, e dovrebbero essere implementate da parte degli sviluppatori nelle fasi iniziali di SDLC (Software Development Life Cycle).

LE 10 REGOLE

1. Verificare di non utilizzare l’input utente per la costruzione di comandi o query

Rientrano in questa casistica attacchi di tipo SQL Injection, tramite i quali potrebbe essere possibile per un attaccante eseguire query arbitrarie sul database: la soluzione più efficace da adottare in questo caso è quella dell’utilizzo di query parametrizzate (prepared statements). Una mancata verifica dell’input utente potrebbe inoltre consentire l’esecuzione di comandi arbitrari eseguiti da altri interpreti, quali il sistema operativo, sistemi LDAP e parser XML.

2. Salvare le credenziali in modo sicuro e non consentire l’utilizzo di password deboli

È preferibile effettuare l’hashing delle password prima del loro salvataggio, utilizzando algoritmi “lenti” quali PBKDF2, Bcrypt e Scrypt in modo da rallentare il tentativo da parte di un attaccante di effettuare il brute force delle credenziali. È consigliabile inoltre aggiungere alla password da hashare un “salt”, ovvero una sequenza casuale di bit che è in grado di complicare attacchi di tipo dizionario. L’utilizzo di algoritmi quali MD5 e SHA1 è inoltre da evitare, in quanto ormai deprecati poiché non sufficientemente sicuri. Non dovrebbe essere inoltre consentito l’utilizzo di password deboli o con caratteristiche di sicurezza non sufficientemente robuste.

3. Utilizzare il protocollo HTTPS per tutte le comunicazioni in transito tra client e server

È importante che tutte le richieste e risposte in transito tra client e server siano cifrate in modo da prevenire attacchi di tipo Man-In-The-Middle che potrebbero consentire ad un attaccante di intercettare le relative comunicazioni. È attualmente possibile ottenere un certificato trusted a zero costi e in tempi rapidi tramite Let’s EncryptÈ consigliabile inoltre verificare la robustezza delle suite di cifratura utilizzate dal web server tramite SSL Labs.

4. Verificare la corretta applicazione dei permessi autorizzativi per ogni utente e risorsa

Assicurarsi che le risorse pubbliche accessibili senza autenticazione siano quelle effettivamente previste in fase di design dell’applicazione. Verificare inoltre che i permessi autorizzativi, per le risorse accessibili solo in seguito ad autenticazione, siano implementati in modo corretto.

5. Prevenire l’esecuzione di codice arbitrario lato client (Cross-Site Scripting)

L’impatto di un Cross-Site Scripting (XSS) può consistere nell’esecuzione di codice remoto sul browser della vittima e, ad esempio, nel furto della relativa sessione; ciò potrebbe consentire ad un attaccante di impersonare l’utente attaccato. La remediation suggerita è quella di applicare meccanismi di output encoding al fine di convertire dati non-trusted inseriti dall’utente in forme che vengano renderizzate in sicurezza sul browser.

6. Verificare la sicurezza delle componenti di terze parti utilizzate dall’applicazione

La sicurezza della propria applicazione dipende anche dalla sicurezza delle librerie o framework di terze parti utilizzati al suo interno. Si consiglia l’utilizzo di tool quali Retire.js per l’individuazione di librerie JavaScript non sicure, e OWASP Dependency Check per la verifica di eventuali vulnerabilità pubbliche e note sulle dipendenze utilizzate dal progetto.

7. Implementare un robusto meccanismo Anti-CSRF

Il Cross-site Request Forgery (CSRF) è una vulnerabilità a cui sono esposte le applicazioni web quando sono progettate per ricevere richieste da un client senza meccanismi per controllare se la richiesta sia stata inviata intenzionalmente oppure no. La tecnica di difesa primaria consiste nell’utilizzo di un token randomico, tipicamente fisso per sessione, da inviare insieme ad ogni richiesta di modifica di stato in modo che venga confrontato con il valore previsto lato server.

8. Non rivelare informazioni interne sull’infrastruttura in seguito ad errori

Gli errori generati dall’applicazione in seguito ad operazioni non gestite potrebbero rivelare informazioni potenzialmente utili ad un attaccante, il quale potrebbe sfruttarle per eseguire attacchi più mirati sull’infrastruttura precisa in uso. È consigliabile configurare il web server e l’applicazione in modo da gestire tali situazioni presentando pagine di errore custom contenenti semplici messaggi generici.

9. Disabilitare la risoluzione delle XML external entities

Lo standard XML prevede la possibilità di inserire nel documento le cosiddette external entities, ovvero riferimenti a risorse esterne. Qualora tale feature non venga disabilitata sul parser XML in utilizzo, potrebbero verificarsi attacchi di tipo XXE tramite i quali un attaccante sarebbe in grado di leggere file arbitrari sul server oppure causare un’interruzione di servizio tramite attacchi di tipo Denial of Service (DoS).

10. Implementare la logica di business dell’applicazione esclusivamente lato server

È di fondamentale importanza che la logica dell’applicazione venga implementata e verificata esclusivamente lato server, in particolare per quanto riguarda le sue operazioni critiche. Si noti infatti che il codice presente lato client può essere interamente manipolato dall’attaccante, il quale potrebbe bypassare gli eventuali controlli di sicurezza presenti.

Conclusioni

La lista precedente, pur non essendo in alcun modo esaustiva, può essere utilizzata come riferimento per avere un’idea del livello di maturità della propria applicazione, relativamente alla sicurezza. Si consiglia di approfondire tali concetti tramite corsi di Secure Coding, come quelli offerti da EC-Council tramite le certificazioni CASE per il framework .NET e per il linguaggio Java.

Topics: Sicurezza informatica, applicazioni web

Scritto da: Trainer Secure Coding

Esperienza pluriennale come Senior Security Consultant in una delle più importanti società italiane di consulenza nel settore della Sicurezza Applicativa. In tale ruolo ha effettuato l’esecuzione di Penetration Test e Secure Code Review nei confronti di applicazioni finanziarie e sistemi critici web e mobile, nonchè Vulnerability Assessment e Network Penetration Test per le più importanti aziende enterprise e istituzioni finanziarie italiane ed internazionali. Come trainer ha effettuato training on-site relativamente ad argomenti di Web e Mobile Security per clienti italiani ed internazionali. Nel Marzo 2015, nel corso di un lavoro di ricerca su iOS Security, ha scoperto una vulnerabilità sulla libreria AFNetworking che ha ottenuto un’attenzione a livello mondiale in quanto diffusamente utilizzata. È inoltre un collaboratore OWASP ed ha contribuito alla traduzione italiana della OWASP Testing Guide v4, come speaker per il Security Summit italiano, e nel 2016 come trainer presso l’OWASP AppSec Europe.