Owasp Capitolo 2: la crittografia per proteggere i dati sensibili. Ecco i 15 comandamenti da seguire
Precedentemente nota come Sensitive Data Exposure, il nome è stato cambiato per evidenziare meglio quella che è la causa piuttosto che la conseguenza. La mancanza di crittografia (causa) può generare una esposizione di dati sensibili (conseguenza).
Ormai sappiamo come i dati sia in transito che a “riposo” devono necessariamente essere protetti. E come possiamo proteggere i nostri preziosi dati? La risposta sta nella crittografia. Password, numeri di carte di credito, dati sanitari, informazioni personali e secreti industriali richiedono livelli di protezioni estremamente elevati e sicuri, anche in virtù delle sempre più stringenti normative in termini di trattamento dei dati (GDRP, PCI DSS, HIPAA etc…).
Per proteggere correttamente tutti i nostri dati dovremmo porci i seguenti quesiti:
- Ci sono dati trasmessi in chiaro? Il traffico esterno su internet è pericoloso, e questo riguarda tutti i protocolli, HTTP, SMTP, FTP. Stiamo usando le loro versioni protette da TLS? È necessario assicurarsi che tutti i dati in transito lo facciano solo se sono protetti (e NO SSL È OBSOLETO ed è stato rimpiazzato da TLS)
- State utilizzando algoritmi di crittografia superati o deboli? Anche se in componenti vecchie del codice?
- Le chiavi di crittografia usate, sono deboli? Riutilizzate? Quelle di default? C’è un piano di gestione delle chiavi? Sono immagazzinate in repositories sicure?
- La crittografia viene obbligata? Le pagine web sono dotate degli header di sicurezza o relative direttive di sicurezza?
- Il certificato del server è validato correttamente? Anche la relativa trust chain?
- I vettori di inizializzazione vengono ignorati? Riutilizzati o non generati in maniera sufficientemente sicura a seconda della modalità operativa di crittografia? State usando modalità operative insicure tipo ECB? Viene usata la crittografia semplice quando sarebbe consigliabile la crittografia con autenticazione?
- Le password vengono usate come chiavi di crittografia invece di una funzione derivativa che parta dalla password stessa per generare la chiave?
- Utilizzate una funzione di randomizzazione non sviluppata ad-hoc per la crittografia? Anche se state usando la funzione adeguata, essa deve essere generata dallo sviluppatore? e in caso contrario, lo sviluppatore ha sovrascritto un eventuale seed robusto già implementato, con uno a cui manca sufficiente entropia/non prevedibilità?
- State usando funzioni di hashing deprecate, quali MD5 o SHA1? State utilizzando hash non critoografici ove invece sarebbero necessari quelli specifici?
- Vengono usati metodi di padding crittografici deprecati come PCKS #1 v1.5?
- I messaggi di errore di crittografia o le informazioni side channel sono exploitabili, come ad esempio negli attacchi di padding oracle?
Come difendersi?
Ecco i 15 comandamenti per proteggere adeguatamente i dati:
- Classificherai i dati inviati, elaborati o immagazzinati dall’applicazione. Identificherai i dati importanti in riferimento alle leggi, requisiti, e esigenze aziendali
- Non immagazzinerai dati importanti se non strettamente necessario. Scarterai i dati non necessari al più presto, o utilizzerai la tokenizzazione conforme alla PCI-DSS. I dati non salvati non possono essere rubati
- Cripterai tutti i dati “at rest” importanti
- Ti assicurerai di utilizzare algoritmi forti, protocolli e chiavi, aggiornati; utilizzerai un sistema adeguato di gestione delle chiavi
- Cripterai TUTTI i dati in transito, usando protocolli sicuri come TLS con la Perfect Forward Secrecy (PFS), la prioritizzazione della cifratura dal server, e parametri sicuri. Obbligherai la crittografia usando direttive come l’http Strict Transport Secrecy (HSTS)
- Disabiliterai il caching delle risposte che contengono dati importanti
- Applicherai i controlli di sicurezza adeguati a seconda della tipologia dei dati
- Non utilizzerai protocolli superati quali FTP o SMTP per trasportare dati importanti
- Utilizzerai funzioni di salting robuste e adattive come Argon2, scrypt, bcrypt o PBKDF2 per immagazzinare le password
- Sceglierai i vettori di inizializzazione (IV) giusti in base alle modalità operative. Questo significa per molti utilizzare un CSPRNG (cryptographically secure pseudo random number generator). Per le modalità che richiedono un nonce, il vettore di inizializzazione (IV) non richiede il CSPRNG. In ogni caso l’IV non dovrà essere utilizzato due volte per la stessa chiave
- Utilizzerai sempre la crittografia autenticata e non la sola crittografia
- Le chiavi verranno sempre generate in maniera crittografica casuale e verranno salvate in memoria come array di bytes. Se viene usata una password, allora essa verrà convertita in una chiave tramite una apposita funzione di derivazione delle chiavi
- Ti assicurerai che venga utilizzato (quando opportuno), di usare la casualità crittografica e che essa non sia stata generata in modo predicibile o con bassa entropia. Molte API moderne non richiedono allo sviluppatore la generazione di un CSPRNG per migliorare la sicurezza
- Eviterai funzioni crittografiche e schemi di padding deprecati e/o sorpassati, come MD5, SHA1, PCKS#1 v1.5
- Verificherai in maniera indipendente l’efficacia di configurazione e settaggi.
