I dati sanitari delle persone dovrebbero essere tra i segreti meglio custoditi al mondo visto che la loro divulgazione senza esplicito consenso risulterebbe in una gravissima violazione della privacy dei pazienti. Non a caso ogni singolo dato sanitario ottenuto può valere fino a 250$ nel mercato nero .
Proprio per questo motivo mi aspetto che gli applicativi software che trattano questi dati siano protetti seguendo i più alti standard di sicurezza informatica esistenti.
Immaginate il mio stupore quando mi sono accorto che uno dei portali web utilizzati dai medici per il controllo dei proprio assistiti era vulnerabile a quello che OWASP mette al primo posto come fattore di rischio per le web app: la SQL Injection.
Per chi non sapesse di che cosa parlo, tramite un attacco di tipo SQL Injection un attaccante è in grado di eseguire dei comandi in linguaggio SQL con i quali può leggere, alterare ed eliminare qualsiasi dato presente all'interno di un database.
Non oso nemmeno immaginare le conseguenze disastrose che avrebbe potuto avere l'accesso e la divulgazione non consentita dei dati anagrafici e dei percorsi sanitari di migliaia e migliaia di pazienti.
Ma prima di procedere con i dettagli della SQL Injection mi presento: sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti anche al mio canale Telegram in cui ogni martedì parliamo di piccole curiosità legate al mondo della tecnologia!
Cos'è una SQL Injection #
Un attacco di tipo SQL Injection è un attacco che sfrutta la mancata validazione degli input digitati dall'utente per fare in modo che questi vengano interpretati come comandi per il database al fine di introdursi in un sistema informatico.
SQL infatti è un linguaggio di programmazione utilizzato per creare, modificare ed interrogare un database relazionale.
Normalmente quando un utente prova ad inserire un'istruzione SQL all'interno di un campo di input (come potrebbe esserlo il campo username di una pagina di login) il sistema si occupa di validare i dati inseriti accertandosi che non ci siano caratteri illeciti e/o facendone la traslitterazione verso una versione non dannosa (ad esempio il carattere < di solito viene convertito in <).
Se questo processo di validazione dei dati immessi dall'utente non avviene potrebbe essere possibile sferrare un attacco di tra quelli appartenenti alla famiglia delle injection (a cui la SQL Injection appartiene).
Il tipico esempio di SQL Injection riportato in tutti i libri di testo è quello di una schermata di login in cui, per verificare che username e password siano corretti, viene usata la seguente query:
SELECT * FROM users WHERE username = "Foo" AND password = "bar"Un attaccante potrebbe aggirare questa schermata di login digitando come username Foo e come password " OR "" = ". In questo modo la query con i dati inseriti dall'utente diventerebbe:
SELECT * FROM users WHERE username = "Foo" AND password = "" OR "" = ""E poiché l'uguaglianza tra stringhe vuote "" = "" risulta essere sempre verificata l'attaccante si vedrebbe garantito l'accesso al sistema come un regolare utente senza che sia stato necessario conoscerne la password.
La SQL Injection sul portale #
Esattamente come nell'esempio descritto poco sopra, nel portale in questione era possibile aggirare la pagina di login confezionando una stringa SQL ad-hoc e usandola come nome utente.
Per verificare l'esistenza del problema mi è bastato inserire il carattere ' nel campo username della pagina di login ottenendo come risposta la query SQL che il server ha provato ad eseguire per verificare la correttezza delle credenziali inserite.
Il messaggio d'errore restituito inserendo il carattere ' come username
Una volta accertata l'esistenza del problema mi sono immediatamente preoccupato di contattare chi di dovere affinché approntasse un fix per la vulnerabilità.
Timeline #
20/10/2020 Mi accorgo del problema sul portale
20/10/2020 Invio email all'indirizzo di supporto generico (mai risposta)
26/10/2020 Invio email al dirigente del reparto IT che mi mette in contatto con il tecnico incaricato del portale
28/10/2020 Riporto la vulnerabilità al tecnico responsabile
11/11/2020 Mi segnalano che la vulnerabilità è stata sistemata
Conclusioni #
Il problema sembra essere stato corretto e ora quando si prova ad inserire il carattere ' all'interno dei campi di login non viene più visualizzata la query SQL eseguita ma viene mostrata una semplice pagina bianca. Tutto bene quel che finisce bene.
O no?
Sinceramente ho l'impressione che il problema sia stato "risolto" semplicemente nascondendo il messaggio d'errore e lasciando la vulnerabilità esattamente dove si trova ma siccome non sono in grado di dimostrare questa mia ipotesi confido nella bontà della correzione. Avrei dormito sogni tranquilli vedendo un messaggio d'errore generico del tipo "nome utente non valido" piuttosto che una pagina bianca.
In ogni caso, vista la natura estremamente sensibile dei dati sanitari, mi auguro che le istituzioni incaricate al controllo e alla gestione di questi dati si impegnino maggiormente a garantire i più alti standard di sicurezza possibili.
Se questo post ti è piaciuto e ti è stato utile ti invito ad iscriverti al mio canale Telegram. Se invece hai domande o vuoi lasciare un commento puoi contattarmi direttamente su Telegram o su Twitter. A presto!