Nelle reti della SQL injection (SQLi) sono caduti pesci piccoli e grossi. Tra i primi la piattaforma Rousseau del Movimento 5 stelle, tra i secondi figurano il gruppo giapponese Sony e, in tempi recentissimi, persino Woocommerce, il plugin di Wordpress che vanta oltre 5 milioni di installazioni al mondo e attivo sul 23,43% dei siti ecommerce (dati di gennaio 2022).
Il primo caso documentato di SQL injection risale al 1998, questo non significa che non ve ne siano stati di precedenti ma, in modo inequivocabile, vuole dire che questo tipo di attacco esiste da quasi 25 anni.
Indice degli argomenti
SQL injection, una vulnerabilità evergreen
Nonostante le comunità di sviluppatori abbiano adottato misure preventive, le tecniche di SQL injection si sono evolute, continuando a creare danni. Occorre comprendere quindi cosa possono fare le comunità di sviluppatori per rimediare, ovviamente nella misura del possibile perché, per quanto banale, tutto ciò che è connesso in rete è potenzialmente vulnerabile.
Che cos’è
È una vulnerabilità che consente di interagire con le query che le applicazioni fanno ai database e, di norma, viene adottata da un attaccante per accedere a informazioni che gli sono precluse ma anche per modificare o eliminare dati al fine di danneggiare, sia il database, sia le applicazioni che vi fanno ricorso.
Un attacco SQLi andato a buon fine mette in condizione chi lo ha perpetrato di entrare in possesso di dati sensibili come, per esempio, identità degli utenti di un sito, i loro nomi utente e relative password, i numeri delle carte di credito se presenti, numeri di telefono e indirizzi email.
Inoltre, ma questo è un male che non riguarda soltanto le offese SQLi, è possibile lasciare aperta una backdoor per perpetrare compromissioni sul lungo periodo.
Gli attacchi con tecniche di SQLi sono diversi, i principali sono:
- analisi di un database, al fine di comprendere come è strutturato;
- accesso ai dati per sottrarli, cancellarli o modificarli;
- attacchi di tipo Union che permettono di attingere dati da diverse tabelle di un database;
- interferenze con le applicazioni connesse ai database, affinché restituiscano dati errati o non ne restituiscano affatto.
I casi più eclatanti
Durante i primi giorni del mese di novembre appena trascorso, sono state individuate diverse vulnerabilità in cinque diversi plugin WooCommerce, una proprio di tipo SQLi che, per dovere di onestà, interessava versioni non aggiornate del plugin Dropshipping, usato da un numero esiguo di siti ma non per questo la vulnerabilità – la cui gravità è stata giudicata da 9.8 su 10 – diventa meno preoccupante.
Woocommerce è sul mercato dal 2011 e, dopo un decennio di crescita, ha ancora esposto il fianco a una tecnica di hacking nota e molto discussa tra chi si occupa di cybersecurity. Segno questo che, per quanto datate e note, le tecniche di SQL injection danno ancora soddisfazione agli hacker.
Quello che ha coinvolto Woocommerce è soltanto l’ultimo caso celebre in ordine cronologico. Se ne contano a decine ma qui, per cristallizzare la natura dell’SQLi, ne citiamo due.
L’attacco a Sony
A giugno del 2011 Lulz Security, collettivo di hacker che viola siti per divertimento (lulz significa “divertimento”, “risate”) ha attaccato i server del gruppo Sony, sottraendo i dati di circa un milione di utenti. Tra questi figuravano indirizzi email, password, date di nascita e indirizzi delle loro abitazioni.
Si è discusso sulla veridicità della notizia, anche perché è apparso strano che un attacco SQL injection, tanto noto e discusso, potesse mietere vittime illustri. Alcuni dei membri di Lulz Security sono stati arrestati a settembre dello stesso anno e, tra i documenti depositati dall’accusa, ce n’erano alcuni che dimostravano sia l’attendibilità dell’attacco sia la facilità con cui è stato perpetrato.
Da Spamhaus a WannaCry: gli attacchi hacker che hanno fatto storia
Le responsabilità del colosso giapponese
Si è anche osservato che le difese attuate da Sony non avessero fatto il loro dovere, demandando così all’hardware l’assenza di policy chiare in materia di difesa, come se un firewall o una Dmz fossero sufficienti a intercettare e bloccare qualsiasi offensiva.
I server Sony, nei quali il collettivo ha passeggiato con relativa tranquillità, erano ubicati in Russia, in Europa e in Brasile (in quest’ultimo caso Lulz Security si è sempre dichiarata estranea). Ciò dimostra quanto sia stato facile per un gruppo di hacker farsi beffe di un colosso.
E la possibile lettura è soltanto una: dal momento che si è trattato di attacchi né sofisticati né premeditati con particolare dovizia, a rendere possibile tanta pochezza sono state le politiche lasche della Sony la quale, peraltro, non aveva cifrato in alcun modo i dati degli utenti.
L’imbarazzante attacco a Rousseau
Nel 2017 e nel 2018 l’hacker R0gue_0 ha attaccato la piattaforma Rousseau, il “sistema operativo” del Movimento 5 stelle. Un caso che lascia perplessi perché il primo attacco ha insegnato poco nulla agli amministratori del sito e perché le password degli utenti erano conservate in chiaro, quindi senza protezioni hash o salt.
Cosa dovrebbero fare gli sviluppatori
Il report State of Developer Security Skills 2022 fornisce spunti per trovare risposta a quello che sembra essere un arcano. La risposta breve è: darsi da fare e cambiare mentalità. La risposta più approfondita fornisce attenuanti alla sentenza superficiale, perché se gli sviluppatori non appaiono essere sensibili alla sicurezza, le aziende che producono o commissionano software lo sono – se possibile – anche meno.
Dal report, che raccoglie i pareri di 1.200 sviluppatori, emerge come soltanto il 29% di questi si dice convinto della necessità di scrivere codice “vulnerability free”. Sono più di 600 gli sviluppatori che non si dicono pronti a scommettere che i loro codici siano protetti dalle vulnerabilità più comuni.
Un codice sicuro è possibile
Questo è il lato preoccupante, ma ce n’è anche uno capace di infondere speranza: l’8% del campione sostiene che scrivere codice sicuro è stato relativamente facile. Il problema si annida qui: occorre che se ne convinca anche il restante 92%.
Entrando più in profondità nelle cifre sciorinate dal report, si legge che:
- Il 36% del campione sostiene che per rispettare le scadenze di produzione non c’è margine di tempo per concentrarsi sulle vulnerabilità del codice.
- Il 33% non ha idea di cosa possa renda vulnerabile il codice prodotto.
- Il 30% sostiene che le politiche interne all’azienda per la quale lavora non fornisce adeguata attenzione e formazione alla sicurezza.
Anche gli sviluppatori hanno necessità di formazione e di strumenti che entrano nei flussi di produzione dei software, al pari di quelli che esistono per l’analisi e la stesura del codice. Nel contempo, gli standard di sicurezza devono entrare nei processi di validazione dei software prodotti e, le nuove generazioni di sviluppatori, dovrebbero iniziare le rispettive carriere proprio attraversando un periodo di formazione, durante il quale vengano istruiti a riconoscere le vulnerabilità e le meccaniche mediante le quali si annidano.
Tutti vogliono il coding express. E sbagliano
Tutto ciò sembra utopico perché, ancora oggi, uno dei metri di valutazione delle capacità di uno sviluppatore è incentrato sulla velocità di produzione. Occorre quindi che le software house, le comunità e le organizzazioni che sviluppano software al proprio interno cambino logiche di valutazione, premiando chi produce codice sicuro e il più possibile al riparo dagli exploit.
Anche le aziende che comprano software dovrebbero giocare un ruolo attivo in questo cambiamento. Oggi, per lo più, prediligono quei pacchetti che hanno la reputazione di essere efficaci, senza comprendere che un software non sicuro arreca un danno di immagine anche a loro stesse.
Waterfall vs. agile
A partire dai primi anni 2000, negli ambiti della produzione di software si è diffusa la cultura dell’Agile software development in contrapposizione con quella Waterfall, ossia a cascata.
La differenza tra i due modelli risiede soprattutto nella qualità dei test. Nel metodo a cascata le differenti fasi di sviluppo sono frammentate da test approfonditi. Una fase di sviluppo non inizia fino a quando i test relativi alla precedente fase sono stati terminati con successo.
L’approccio agile è più orientato al prodotto e non al progetto in sé: sono gli utenti finali a provare le implementazioni e gli avanzamenti del software.
Quindi, per esempio, saranno dei contabili a comunicare all’azienda che sviluppa l’applicativo con il quale dovranno lavorare cosa cambiare, cosa migliorare e quali funzionalità introdurre.
Cosa, questa, che ha una sua logica per quanto riguarda l’implementazione del pacchetto ma che è poco incline alla sicurezza. I contabili sanno molto bene quali caratteristiche deve avere un software di contabilità ma non è detto che abbiano nozioni di sicurezza.
Migliorare la cyber grazie all’intelligenza artificiale: quattro casi di successo
Che fare
Le tecniche di difesa sono diverse, nessuna però supera la convalida dell’input e le query che includono istruzioni preparate.
Laddove possibile, l’utente che usa un’applicazione non dovrebbe digitare input ma selezionarlo tra opzioni già preimpostate, va da sé che questo non è sempre possibile e quindi occorre che le applicazioni siano in grado di controllare la bontà dei dati inseriti (che rientrino in un intervallo di dati valido o che non contengano codice dannoso già noto). Un lavoro che richiede preparazione, costante aggiornamento e dedizione.
Un approfondimento sulle difese e sui modi di implementarli può essere letto qui.
