Come rendere sicuro un sito web

Proteggere un sito web: considerazioni preliminari

Il mantenimento di un sito web include tutte le attività necessarie per assicurarsi che rimanga aggiornato e funzionante.
Un'importante attività di mantenimento alla quale in tanti non prestano attenzione è la sicurezza del sito web.
Il detto "nessun sistema è sicuro al 100%" non si applica solo ai sistemi operativi, ma anche ai siti web.
Sono ancora in tanti a ritenersi al sicuro perché convinti che ad essere attaccati siano sempre siti, portali e piattaforme più popolari.

Negli ultimi anni, con il nascere di strumenti che permettono di creare e gestire un sito anche a utenti con scarse conoscenze di sviluppo e sicurezza, gli attacchi verso i siti internet si sono moltilplicati; inoltre, gran parte dei malware in circolazione sul web sono automatizzati (worm) e traggono vantaggio dalle vulnerabilità di qualsiasi sito, grande o piccolo che sia.
Questi strumenti spesso si portano dietro vulnerabilità e punti di accesso per malintenzionati; anche una semplice pagina statica con un form da compilare può essere sfruttata per veicolare un attacco ai visitatori del sito.

Tutte le componenti software in quanto tali sono afflitte dal problema delle vulnerabilità, ovvero difetti nel codice che danno la possibilità a terzi non autorizzati di eseguire delle operazioni da remoto, che vengono adattate a scopo di attacco e compromissione del sito.

Un sito web deve il suo funzionamento e la sua sicurezza ad una gerarchia di elementi in cui l'uno dipende dall'altro.
Un problema in un livello qualsiasi è un problema per l'intero sito, ragion per cui ogni componente deve essere valutato attentamente in fase di sviluppo e poi attenzionato nel tempo per garantire la qualità e la continuità del servizio.

La sicurezza di un sito web copre un'ampia gamma di attacchi dei quali si può cadere vittima e un'altrettanta gamma di contromisure da adottare per prevenirli.
L'articolo vuole concentrarsi sul funzionamento di alcuni degli attacchi più diffusi e fare cenno di quegli altri nella cui trappola, seppur in percentuale minore, si può cadere.

Predictable resource location

La posizione prevedibile delle risorse (predictable resource location) è una tecnica di attacco utilizzata per scoprire contenuti e funzionalità nascosti di un sito web, non collegati alla directory del dominio.

Un utente malintenzionato potrebbe indovinare nomi di file e directory non destinati alla visualizzazione pubblica, e magari riuscirci senza troppo impegno, questo perché file e percorsi hanno spesso convenzioni di denominazione comuni e risiedono in posizioni standard.
Le risorse potenzialmente accessibili sono le più varie (file temporanei, di backup, di configurazione, applicazioni demo non ancora collegate al dominio); queste non solo aiuteranno il malintenzionato a identificare l'alberatura del sito, ma anche (nella peggiore delle ipotesi) a ottenere preziosi dati sull'ambiente che lo ospita e addirittura sui suoi utenti (informazioni sul database, password di login, percorsi di file in altre aree sensibili).
L'attaccante può effettuare richieste arbitrarie di file o directory a qualsiasi server web disponibile pubblicamente, determinando l'esistenza di una risorsa dall'analisi dei codici di risposta HTTP forniti dallo stesso web server.

Affinché i suddetti contenuti e percorsi rimangano adeguatamente tutelati è necessario applicargli le dovute autorizzazioni (ad es. solo lettura o protezione con password per i dati privati) ed evitare di posizionare file di configurazione (del database, del web server) nella root del proprio spazio web; inoltre, è fortemente consigliato bloccare la navigazione attraverso le directory del sito configurando opportunamente il file .htaccess.

A questo proposito, gli archivi binari o gli script con un'estensione alternativa possono esporre il codice sorgente a un utente malintenzionato.
Se l'estensione dello script non corrisponde a quella che dovrebbe effettivamente assumere (.asp .jsp .php), il server generalmente considera il contenuto del file come equivalente a testo normale, presentandone il codice sorgente grezzo piuttosto che eseguire lo script e fornire un output interpretato.
In tale scenario, l'esposizione dei dati è variabile, potendo arrivare alla possibile sottrazione di credenziali di connessione al database e password di amministrazione.
Gli archivi di file come .tgz, .tar.gz o .zip non devono mai essere archiviati nella root dello spazio hosting, perché qualora contengano il codice sorgente dell'applicazione server non sarà difficile per un utente smaliziato scaricarne il codice ed esaminarlo.

Monitorando i log del proprio sito web, spesso si scoprirà che i tentativi di intrusione provengono da un determinato user-agent, "libwww-perl".
Lo user-agent in questione proverà ad accedere alle URL corrispondenti alle pagine del sito allo scopo di iniettare codice malevolo.
Una volta che lo script infetto viene eseguito, può arrivare a disabilitare molte delle funzioni eseguite dai propri script, e lato-client e lato-server.

Questi tentativi di penetrazione da parte di agenti dannosi possono essere prevenuti settando apposite regole dall'interno del file .htaccess, che vadano a bloccare l'accesso dallo user-agent "libwww-perl" e dagli URL che includono il comando "= http:" Quest'ultima è una possibile stringa utilizzabile dagli aggressori per violare il sito e collegarlo a un altro sito che contiene lo script dannoso.

Attacco man in the middle: come difendersi

Un sito web non è altro che un insieme di file conservati su un web server.
Ogni utente, per poterlo visualizzare, dovrà scaricare una certa quantità di dati comunicando, allo stesso tempo, la sua presenza sul sito attraverso l'invio di pacchetti di dati e informazioni identificative al server, che lasciano traccia del suo passaggio.
Tutti gli scambi di informazione, se non crittografati, possono essere intercettati e aprire la porta ad un attacco man in the middle in cui un malintenzionato riesce a "sniffare" i messaggi che si scambiano client e server, servendosene per scopi illegittimi; ad es. il tabnabbing (che vedremo a breve) costituisce una variante di attacco man in the middle.
Questo pericolo deve assolutamente essere evitato, soprattutto nel momento in cui l'utente è invitato a rilasciare dati sensibili (personali, bancari).

Tutti noi abbiamo presente il lucchetto verde presente sulla barra degli indirizzi del browser; ecco, questo simbolo sta ad indicare che la connessione client-server è crittografata e, proprio per questo, non decifrabile e violabile da terzi.
L'installazione di un certificato di sicurezza (SSL o TLS) garantisce ai visitatori una connessione criptata (dunque, sicura) tra il loro browser e il server web, mantenendo la riservatezza dei dati durante la trasmissione.

Per gli e-commerce e per tutti i siti web che prevedono la possibilità di transazioni elettroniche o di inoltro di dati personali, il possesso di un certificato di sicurezza SSL è obbligatorio per legge.

Tabnabbing

Una delle best practices per la sicurezza di un sito web e dei suoi utenti è la prevenzione del tabnabbing, tecnica di phishing alquanto subdola che sfrutta l'attributo target=”_blank” del tag HTML <a>, il cui valore determina l'apertura di una nuova scheda per i collegamenti a risorse esterne.

La vulnerabità si verifica quando l'attaccante, grazie al varco rappresentato dall'apertura della nuova scheda, accede all’oggetto della finestra originale attraverso JavaScript, ottenendone il controllo e sostituendola con un documento dannoso o modificandone il contenuto.
L'aspetto della pagina dannosa potrebbe rispecchiare in tutto e per tutto quello della pagina illegittimamente sostituita, ma in realtà l'URL sarà diverso e utenti poco accorti potrebbero non notarne la modifica.
La pagina fasulla potrebbe chiederci dei dati di login; un malaugurato inserimento verrà inoltrato all'account dell'attaccante e l'utente, ignaro, reinderizzato sulla pagina originale senza accorgersi di essere stato derubato delle credenziali.

L’attributo rel="noopener" associato al tag <a> impedisce che tutto ciò accada, assicurando che la pagina esterna non possa assumere il controllo della pagina originale.
E` bene inoltre prestare molta attenzione ai link in uscita inseriti nelle proprie pagine, verificandone scrupolosamente l'attendibilità e la reputazione.

Clickjacking

Il clickjacking è una tecnica d'attacco agli utenti del web che mira a dirottare i loro click verso oggetti e destinazioni diverse da quelle credute.
Questi, durante la navigazione, decidono di cliccare su un link HTML, ed ecco che interviene JavaScript.
Un click, in JavaScript, corrisponde a un evento.
Ogni evento ha un suo gestore (listener ), per mezzo del quale verrà eseguita una data azione al verificarsi dell'evento.
Nel clickjacking l'azione compiuta a seguito del click ha una finalità fraudolenta, ovvero non corrisponde a quella voluta dell'utente, ignaro del fatto che il suo click lo indirizzerà ad una pagina web malevola o andrà ad innescare i comandi nascosti dall'attaccante nel gestore dell'evento.

Le conseguenze dell'attacco possono essere deleterie per l'utente; potrebbe scaricare ed eseguire un malware sul proprio computer, oppure acquistare un prodotto da un sito e-commerce a sua totale insaputa.
Potrebbe addirittura fornire password sensibili attraverso la compilazione dei campi di un form, non avendo la minima cognizione del fatto che contestualmente l'attaccante sta intercettando i tasti premuti sulla tastiera.

Per camuffare il clickjacking, i malintenzionati ricorrono subdolamente ad un <iframe>, incorporando al suo interno il sito legittimo così da duplicarlo e servirsene per veicolare l'attacco.
Dopodiché, grazie all'aiuto dei CSS, l'attaccante sovrappone al documento "esca" un pulsante, rendendolo invisibile e posizionandolo in un dato punto della pagina fidata dove in corrispondenza si trova un link.
L'utente, cliccandoci sopra, crederà di continuare la navigazione altrove o comunque di eseguire un'azione benevola, ma in realtà sarà caduto nella trappola del pirata senza esserne consapevole.

Per proteggere i propri utenti, un webmaster potrebbe implementare un framekiller, ovvero uno snippet JavaScript che impedisca l'inclusione del dominio all'interno di un frame.
Il framekiller convalida la finestra corrente, verificando che i domini corrispondano: in caso contrario, il rendering della finestra non autorizzata viene bloccato.
Questa metodica, tuttavia, può essere bypassata facilmente bloccando l'esecuzione dello snippet dal frame contenente la pagina fraudolenta.

L'intestazione HTTP X-Frame-Options, se impostata, offre protezione contro il clickjacking dichiarando quella che è la politica adottata dal webmaster in relazione ai frame.
I valori consentiti (DENY, ALLOW-FROM origin o SAMEORIGIN ) possono impedire qualsiasi framing, consentirlo da determinati domini o solo dal dominio principale.

Un rimedio analogo al precedente ma più recente è il ricorso alla direttiva frame-ancestors della Content Security Policy, per impedire l'incorporamento del sito e delle sue risorse da parte di qualunque dominio o consentirlo specificandone le fonti autorizzate.

Fingerprinting

Quando un server web genera pagine di errore (ma anche elenchi di directory e altri output) alcune importanti informazioni sulla versione e altri dettagli di sistema vengono visualizzati nell'intestazione di risposta.
Le righe restituite dal server possono esporre dati (tipo e variante del sistema operativo, versione del web server utilizzato sulla macchina) in grado di rivelare indirettamente buchi di sicurezza esistenti, fornendo a malintenzionati potenziali punti di accesso.
La raccolta di dati e informazioni inerenti un sistema informatico prende il nome di fingerprinting.

Facendo riferimento ad Apache (tra i web server più diffusi), per garantire che il server web non trasmetta pubblicamente informazioni che permettano di identificarlo è necessario modificare due direttive dall'interno del file di configurazione httpd.conf, ovvero ServerTokens e ServerSignature, i cui valori dovranno cambiare rispettivamente in ServerTokens Prod e ServerSignature Off.
La prima direttiva configura Apache in modo che restituisca solo la dicitura "Apache" nell'intestazione di risposta, sopprimendo le informazioni sulla versione del sistema operativo.
La seconda indica ad Apache di non visualizzare la riga a piè di pagina che ne mostra il numero di versione.
Il medesimo risultato può essere raggiunto anche agendo sui settaggi del file .htaccess, normalmente presente nella root del dominio

Attacco XSS: cross-site-scripting

Il cross-site-scripting (XSS ) è una vulnerabilità informatica dalla quale sono affetti quei siti web dinamici che impiegano un insufficiente controllo dell'input nei form, permettendo a un pirata della rete di inserire codice lato-client a scopo di attacco.
Sfruttando vulnerabilità note delle applicazioni web, gli aggressori iniettano contenuto malevolo nel messaggio restituito dal sito vulnerabile, facendo credere all'utente che provenga da fonte sicura.
L'esecuzione dello script infetto consente al malintenzionato operazioni di raccolta, manipolazione e reindirizzamento di informazioni riservate (accesso ai cookie di sessione, visualizzazione e modifica di dati presenti sui server, alterazione del comportamento dinamico delle pagine web).

In passato, l'attacco si basava unicamente sull'utilizzo di frammenti di codice JavaScript inviati all'interno di richieste di pagine web dinamiche, in modo che il web server eseguisse operazioni diverse da quelle previste.
La vulnerabilità si è estesa nel tempo fino a comprendere modalità di iniezione di codice basate non solo su JavaScript, ma anche su ActiveX, VBScript o anche puro HTML.

Vulnerabilita XSS lato-server e DOM-based

Storicamente le vulnerabilità XSS sono state individuate in applicazioni che svolgevano tutto il processamento dei dati lato-server.
L'input dell'utente (tra cui un vettore XSS) veniva inviato al server per poi essere rimandato indietro come una pagina web.

Negli attacchi XSS DOM-based invece (di più recente apparizione), i dati malevoli non sono toccati dal server web, piuttosto sono riflessi dal codice JavaScript interamente sul lato client.

XSS reflected (non-persistent)

Le vulnerabilità cross-site-scripting di tipo reflected sono le più diffuse e sfruttate.
Si verificano quando il server genera pagine dinamiche su richiesta del client senza controllare la correttezza di quest'ultima.
Dato che i documenti HTML hanno una struttura in cui possono mischiarsi testo, istruzioni di formattazione e di controllo, se queste vengono incluse nella pagina dinamica senza validazione e codifica HTML adeguate, questo può portare a iniezione di codice di markup.

Un esempio di possibile vettore d'attacco è il motore di ricerca interno a un sito.
Eseguita una query di ricerca, verrà restituita una pagina di risultati compatibili con la stringa digitata, mentre se non ci sono risultati disponibili la pagina restituirà la stringa inserita (ad es. "risorse sulla sicurezza") seguita dalla dicitura “non trovato”.
Questo è quanto si dovrebbe verificare in condizioni normali.

Tuttavia, quando si invia una query anomala di ricerca, come la seguente, e viene visualizzato un box di avviso (popup) contenente la stringa “xss”, oppure la pagina visualizza il markup iniettato, ne consegue che la pagina è vulnerabile ad attacchi cross-site scripting.

Un attacco non persistente può essere veicolato via mail.
L'esca, il più delle volte, è un URL dall'aspetto innocuo, che punta a un sito attendibile ma vulnerabile al vettore XSS; il click sul link può causare l'esecuzione dello script malevolo dal browser della vittima.

Torniamo al sito precedente, quello con il motore di ricerca interno, e proviamo a illustrare più dettagliatamente l'anatomia dell'attacco.
Il sito è un portale che permette anche di registrarsi e loggarsi nel proprio profilo con username e password.
Effettuato l'accesso, il browser mantiene un cookie di autenticazione, che si presenta come un insieme di caratteri illeggibili che ricordano le autenticazioni precedenti.
L'attaccante nota che il sito contiene una vulnerabilità XSS di tipo reflected.
Crea un URL per sfruttare l'exploit, convertendo astutamente i caratteri ASCII in esadecimale per camuffarlo e renderlo difficilmente decifrabile. Invia una mail ad un ignaro utente del sito, sul quale ha scoperto essere interessato alla stampa 3D, con oggetto: "Ultime novità sulla stampa 3D".
Ricevuta la mail e aperto il link, il malcapitato giungerà su un sito che considera attendibile (dato che ci è registrato), ma non troverà nulla e visualizzerà "novità su stampa 3D non trovato"; nonostante ciò, lo script infetto verrà eseguito invisibilmente sullo schermo, scatenando l'attacco XSS.
Il browser lo eseguirà come se fosse stato inviato dal sito fidato, quindi prenderà una copia del cookie di autenticazione dello sfortunato bersaglio e lo invierà al server dell'attaccante.
Quest'ultimo inserisce il cookie di autenticazione nel suo browser, va sul sito e si autentica come se fosse la vittima; ne spulcia tutti i dati personali e decide anche di cambiare la password in modo che la vittima non possa più entrare.
L'attaccante potrebbe addirittura decidere di inviare un collegamento simile all'amministratore del sito, mirando a una escalation dei privilegi.

XSS non-reflected (persistent)

Una vulnerabilità XSS persistente (o stored ) è una variante ancora più dannosa di cross-site-scripting, che si verifica quando le stringhe inserite dall'attaccante vengono salvate sul server e visualizzate sulle pagine restituite agli utenti senza aver eliminato la formattazione HTML.

Ad esempio, supponiamo che ci sia un sito in cui i membri possono visionare i profili degli altri membri.
L'attaccante, collegandosi al sito, scopre che questo contiene una vulnerabilità XSS. Come?
Posta un commento inserendovi del markup e i tag verranno visualizzati così come sono; lo stesso accadrà per eventuali tag di script.

Per motivi di privacy, il sito nasconde a tutti il vero nome e la mail degli utenti, informazioni, queste, tenute segrete dal server; l'unico momento in cui sono visualizzati è quando il membro si autentica.

Supponiamo che l'attaccante voglia scoprirli; per farlo, crea un proprio profilo e scrive uno script progettato per essere eseguito dal browser degli utenti registrati quando andranno a visitarlo.
Un membro del sito raggiunge il profilo dell'attaccante, contenente lo script che proverà a rubare nome ed email; se lo script è racchiuso all'interno del tag <script> non verrà visualizzato a schermo, ma verrà comunque e automaticamente eseguito dal browser della vittima, rubandone i dati che verranno inviati al server dell'attaccante; oppure, l'attaccante potrebbe rubare il cookie di sessione del malcapitato e sfruttarlo usando il suo account fino a una eventuale invalidazione del cookie.

Le vulnerabilità XSS di tipo persistente sono molto più deleterie rispetto alle altre, questo perché lo script dannoso dell'attaccante viene fornito in maniera automatizzata, senza la necessità di indirizzare la vittima su un sito fraudolento.

In particolare nel caso di siti che prevedono registrazione e login, il codice potrebbe essere progettato per propagarsi autonomamente tra gli account, creando un tipo di worm lato client.

XSS reflected: come proteggersi dalla vulnerabilità

Per mitigare l'attacco di tipo reflected possono essere adoperate differenti contromisure.

L'input del campo di ricerca potrebbe essere analizzata per eliminare eventuali codici.

Il server web potrebbe essere impostato in modo da reindirizzare le richieste non valide; oppure, potrebbe rilevare un accesso simultaneo (da due diversi indirizzi IP) e invalidare le sessioni.

Ancora, il sito web potrebbe richiedere agli utenti di inserire nuovamente la propria password prima di cambiare le informazioni di registrazione (autenticazione a due fattori).

XSS non-reflected: come proteggersi dalla vulnerabilità

Ricollegandoci all'anatomia dell'attacco di tipo non-reflected, l'applicativo software che gestisce le richieste al sito avrebbe potuto analizzare i profili degli utenti, filtrandone i contenuti e rimuovendo eventuali script, ma non l'ha fatto: sta qui il bug di sicurezza.

Altri metodi di contrasto al cross-site-scripting prevedono controlli di sicurezza aggiuntivi durante l'autenticazione della sessione.
Dato che gli script lato-client hanno tipicamente accesso ai cookie di sessione, e un exploit XSS potrebbe rubarli, spesso le applicazioni web legano il cookie di sessione all'indirizzo IP dell'utente che ha ottenuto l'accesso in origine, permettendo solo a tale IP di utilizzare il cookie.
Questo è efficiente nella maggior parte dei casi, ma non funziona in situazioni in cui, ad esempio, la vittima sta cambiando il proprio IP collegandosi da mobile.

Un'altra soluzione la offrono gli stessi browser; stiamo parlando del flag HttpOnly, funzione che consente a un server web di settare un cookie non accessibile dallo script lato-client, prevenendone completamente il furto.

Cross-site-request-forgery (CSRF)

Il Cross-site-request-forgery è, praticamente, l'opposto dell'XSS, nel senso che invece di fare leva sulla fiducia degli utenti in un sito, l'attaccante e la sua pagina malevola sfruttano la fiducia del sito nel software del client, facendo richieste che il sito ritiene azioni consapevoli e attendibili di un utente autenticato.
È una vulnerabilità a cui sono esposti i siti web dinamici che ricevono richieste da un client senza controllare se la richiesta sia stata inviata intenzionalmente o meno.

Un attaccante fa in modo che un utente vittima invii involontariamente dal suo browser al sistema web in cui è attualmente autenticato una richiesta HTTP manipolata; il sistema, vulnerabile al CSRF, avendo la certezza che la richiesta provenga dall'utente già precedentemente loggato, la esegue senza sapere che in realtà dietro di essa si cela un'azione pensata dall'attaccante.

Ci sono diversi modi coi quali un utente può essere raggirato nell'inviare una richiesta a un server web, per esempio nascondendo la richiesta in un'immagine (tramite il tag HTML <img>), oppure tramite un'XMLHttpRequest o un URL.

Questa vulnerabilità è incontrata molto spesso nel codice lato-server dell'applicazione, con la conseguenza che un eventuale exploit può permettere all'attaccante di eseguire del codice maligno, arrivando a furto e alterazione di dati sensibili.

Supponiamo che un utente si sia autenticato a un portale e-commerce per l'acquisto di un oggetto.
Il sito ha un form per i pagamenti che, una volta inviato, richiederà una pagina del tipo: Un malintenzionato, tramite mail, gli invia un'immagine dentro la quale avrà nascosto un link. Quando l'utente aprirà l'immagine, il browser invierà una richiesta HTTP al portale e-commerce; dalla verifica del cookie di sessione, risulterà che la richiesta proviene effettivamente da un utente registrato e perciò autorizzerà il pagamento.

Vi sono alcune contromosse in grado di arginare o almeno di ridurre il rischio di un attacco CSRF.

Evitare il metodo GET per richieste che comportano cambiamenti di stato, e soprattutto controllare il campo di intestazione HTTP referer per verificare se la richiesta è stata prodotta da una pagina valida.

Usare codice fidato (per mezzo di framework o librerie) che eviti allo sviluppatore di rendere vulnerabili i propri script.

Quando un utente effettua una transazione, inviargli una richiesta addizionale di conferma, per esempio una nuova verifica della password prima di eseguire l'operazione.

Infine, è buona abitudine, da parte dell'utente, eseguire sempre il logout da siti web sensibili prima di riprendere la navigazione sul web.

SQL injection: come difendersi

SQL injection è una tecnica usata per attaccare qualsiasi tipo di applicazione che impieghi in modo non sicuro database relazionali per la gestione dei dati, attraverso l'iniezione di codice SQL.

L'attacco sfrutta le vulnerabilità di sicurezza del codice applicativo che si collega alla fonte dati SQL.
Il mancato controllo dell'input dell'utente permette di inserire artificiosamente delle stringhe di codice SQL che saranno eseguite dall'applicazione server.
Grazie a questo meccanismo è possibile far eseguire comandi SQL anche molto complessi (alterazione o eliminazione di dati esistenti, creazione di nuovi utenti, download completo dei contenuti del database, annullamento di transazioni).

Il mancato filtraggio dell'input dai caratteri di escape fa si che questi vengano passati all'interno di uno statement.
Questo può provocare la manipolazione degli statements eseguiti sul database.
In altre parole, lo statement SQL può fare più o meno di ciò che era inteso dall'autore del codice.
A questo proposito, una pratica fortemente consigliata è quella di impedire l'esecuzione di statement multipli con un'unica chiamata.
Ci sono delle API in PHP che non lo permettono, appunto, per motivi di sicurezza, evitando così che gli attaccanti iniettino delle query completamente separate all'interno dello statement.

L'attaccante potrebbe eseguire delle query string malevole per venire a conoscenza del numero di versione di MySQL o comunque per ottenere sempre più informazioni sul medesimo fino a quando non viene scoperta una via di attacco.

I valori inviati dal malintenzionato possono contenere comandi maligni che vengono salvati sul server piuttosto che venire eseguiti immediatamente.
In tali casi, l'applicazione può memorizzare l'input maligno come se fosse uno statement SQL valido, ed un'altra parte dell'applicazione (che non effettua controlli per proteggersi dall'iniezione) potrebbe eseguire lo statement memorizzato.

A tal proposito, è possibile usare statement parametrizzati che lavorano con dei parametri al posto di inserire l'input direttamente nello statement.
I parametri memorizzano soltanto un valore del tipo specificato e non un qualsiasi statement SQL; in questo modo l'SQL injection viene trattata semplicemente come un valore non valido per quel parametro.

Usare delle librerie che generano automaticamente degli statement SQL parametrizzati evita di scrivere direttamente codice SQL, adoperando pattern sicuri e improntati alle migliori pratiche di sviluppo.

Altra strategia di prevenzione degli attacchi SQL è quella di evitare caratteri che hanno un significato speciale, e proprio per questo potenzialmente dannosi (' "" \).
Per esempio, in PHP si è soliti utilizzare delle funzioni che sostituiscono i caratteri speciali, nei parametri, con stringhe valide, rendendo sicura la query prima di inviarla.

Anche la conversione esadecimale viene operata mediante alcune funzioni di PHP, per convertire del testo nella sua rappresentazione esadecimale prima di usarlo in un comando SQL.
La conversione esadecimale elimina gli attacchi di SQL injection perché la stringa esadecimale inviata alla funzione viene trattata come già utilizzata e per questo non interpretata.

Qualcuno ricorderà i data breach di Sony e Yahoo (2011-2012), i cui database furono violati mediante attacchi basati proprio su SQL injection, portando al furto di credenziali d'accesso, chiavi di download, codici sconto e informazioni personali di milioni di utenti.

Cenni di legislazione sul reato informatico

Le condotte fin qui descritte configurano un fenomeno o potenziale fenomeno di crimine informatico, caratterizzato dall'abuso della tecnologia informatica a scopo di lucro o puramente vandalico.
La tipologia e la casistica sono decisamente ampie e una loro disamina sarebbe troppo vasta, per cui ci concentreremo specificamente sul reato delineato dalle fattispecie prese in esame.

Gli attacchi e le forme di intrusione esaminati possono configurare:

• frode informatica, consistente nel penetrare all'interno di un server che gestisce servizi con lo scopo di clonare account di inconsapevoli utilizzatori oppure ottenere tali servizi gratuitamente.
  Il codice penale italiano (art. 640-ter) punisce con la reclusione fino a 3 anni chiunque procura a sé o ad altri un ingiusto profitto alterando in qualsiasi modo il funzionamento di un sistema informatico o intervenendo senza diritto con qualsiasi modalità su dati, informazioni o programmi in esso contenuti;
• danneggiamento informatico, nella cui fattispecie (art. 635-bis c.p.) il nostro ordinamento giuridico fa rientrare l'attività di chiunque distrugge, deteriora, cancella, altera o sopprime informazioni, dati o programmi informatici altrui.
  Anch'esso è punibile con la reclusione fino a tre anni;
• accesso abusivo a un sistema informatico (art. 615-ter c.p), attività posta in essere da un soggetto che vi si introduce aggirando le misure di sicurezza, mantenendosi al suo interno contro la volontà di chi ha il diritto di escluderlo.
  Anch'esso è punibile con la reclusione fino a tre anni.
• Quanto alla diffusione dei malware, la legge (art. 615-quater c.p. "detenzione e diffusione abusiva di codici di accesso a sistemi informatici") punisce con la reclusione fino a due anni chiunque, al fine di procurare a sé o ad altri un profitto o di arrecare ad altri un danno, abusivamente si procura, riproduce, diffonde, comunica o consegna codici, parole chiave o altri mezzi idonei all'accesso ad un sistema informatico protetto da misure di sicurezza, o comunque fornisce indicazioni o istruzioni idonee al predetto scopo.