Code review e HTTPS

Ha senso fare la revisione di sicurezza di un codice sorgente quando la trasmissione dei dati avviene in HTTPS?

In una presentazione sulla "revisione di sicurezza di codice sorgente" ho sentito tale affermazione:

Se la trasmissione con la Web App avviene in HTTPS, il tampering dei dati è impossibile e quindi la revisione di sicurezza del codice interessato da tali dati non è necessaria(*)

Falso!

Facciamo una piccola premessa: prima di effettuare la revisione di un codice sorgente bisogna identificare le possibili minacce a cui sarà sottoposta l'applicazione (ovvero le tipologie di attori maliziosi che interagiranno con essa) e modellare i "casi di abuso" (ovvero i casi di uso dell'applicazione in cui gli attori sono le minacce) le cui finalità sono quelle di sovvertire l'applicazione.

Ipotizziamo ora che in un caso di abuso i dati in input all'applicazione viaggino in HTTPS. Il codice sorgente che è responsabile dell'elaborazione di tali dati non può solo per questo essere considerato sicuro. Tali dati infatti potrebbero comunque essere resi disponibili dall'applicazione attraverso un' "Information Leakage" o un' eccezione mal gestita (caso di scorretta "Encapsulation" o "Errors" della classificazione "7 Pernicious Kingdoms")

La protezione del canale di trasmissione dei dati non può essere considerata una protezione di livello applicativo ma bensì solo infrastrutturale. Se viene fatto del tampering, che il dato sia stato modificato dall'utente o da qualcuno che lo ha intercettato sulla rete poco importa. Quello che conta, è che tale dato arrivando all'applicazione potrebbe essere mal interpretato se non opportunamente controllato. Questo quindi non implica alcuna esclusione di codice sorgente da analizzare.

Vediamo quindi perché HTTPS e più in generale SSL/TSL hanno una scarsa rilevanza da un punto di vista della sicurezza del codice:

• SSL protegge il canale, ma non le informazioni veicolate in esso: se l'utente che fornisce l'input è malizioso che il canale sia protetto o no poco importa!
• Il contesto SSL non può essere dato per scontato: il sistemista potrebbe aver abilitato la suite crittografica con un algoritmo estremamente debole, o peggio aver disabilitato la cifratura;
• SSL garantisce la sicurezza dell'infrastruttura di comunicazione e nulla ha a che fare con la sicurezza dell'applicazione: non importa chi modifica il dato in input ma come tale dato verrà validato dall'applicazione;
• SSL garantisce unicamente la privatezza del dato nel caso di autenticazione del solo server: sarebbe più corretto parlare quindi di protezione della "privatezza" dei dati piuttosto che di "sicurezza". La garanzia della confidenzialità del dato tramite la cifratura implica l'integrità dello stesso ma non l'autenticità del mittente. Nel caso di mutua autenticazione oltre alla confidenzialità vi è anche la garanzia dell'integrità piena con autenticazione del mittente.

E' chiaro che da qualche parte i revisori dovranno pur tagliare: eseguire la revisione di una grossa applicazione potrebbe diventare non giustificabile dal punto di vista dei costi. Ma attenzione a non fare delle assunzioni troppo grossolane.

Giusto quindi limitare l'analisi ai soli casi di "abuso" modellati a partire dalle minacce. Sbagliato fare assunzioni basate su un "falso senso di sicurezza" indotto da tecnologie appunto di sicurezza.

"Software Security vs. Security Software": rendere sicuro un software non vuol dire utilizzare del software o delle tecnologie di sicurezza (es: HTTP, SSL, cifratura, PRNG, etc. etc.).

---------- AGGIUNTO IL 23/02/2010 ---------------------

(*) la frase originale è:

"La possibilità di fare tampering su determinati parametri che vengono passati in HTTPS con un certificato [...] dove la sicurezza del canale trasmissivo è garantita [...] Quindi una code review deve matchare le informazioni pregresse per non sobbarcare di lavoro inutile i miei sviluppatori"