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.