SQL injection: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: Modifico: de:SQL-Injection |
Nessun oggetto della modifica Etichette: Modifica visuale Modifica da mobile Modifica da web per mobile |
||
| (208 versioni intermedie di oltre 100 utenti non mostrate) | |||
Riga 1:
[[File:KD SQLIA Classification 2010.png|thumb|alt=Classificazione dei vettori di attacchi SQL injection nel 2010|Classificazione dei vettori di attacchi SQL injection nel 2010]]
Nella [[sicurezza informatica]] '''SQL injection ''' è una tecnica di ''command injection'', usata per [[Attacco informatico|attaccare]] applicazioni che gestiscono dati attraverso [[database relazionali]] sfruttando il linguaggio [[Sql|SQL]]. Il mancato controllo dell'input dell'utente permette di inserire artificiosamente delle [[Stringa (informatica)|stringhe]] di [[codice sorgente|codice]] [[SQL]] che saranno eseguite dall'applicazione [[server]]: grazie a questo meccanismo è possibile far eseguire comandi SQL, anche molto complessi, dall'alterazione dei dati (es. creazione di nuovi utenti) al [[download]] completo dei contenuti nel database.<ref>{{Cita web|url= https://technet.microsoft.com/en-us/library/ms161953%28v=SQL.105%29.aspx |titolo= SQL Injection |accesso= 4 agosto 2013 |autore= Microsoft |citazione= SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution. Any procedure that constructs SQL statements should be reviewed for injection vulnerabilities because SQL Server will execute all syntactically valid queries that it receives. Even parameterized data can be manipulated by a skilled and determined attacker.}}</ref>
== Storia ==
Le prime discussioni pubbliche relative all'SQL injection sono apparse attorno al 1998.<ref>{{Cita web|titolo= How Was SQL Injection Discovered? The researcher once known as Rain Forrest Puppy explains how he discovered the first SQL injection more than 15 years ago. |autore= Sean Michael Kerner |data= 25 novembre 2013 |url= http://www.esecurityplanet.com/network-security/how-was-sql-injection-discovered.html }}</ref> Per esempio, un articolo del 1998 su [[Phrack Magazine]].<ref>{{Cita pubblicazione|titolo= NT Web Technology Vulnerabilities |autore= Jeff Forristal (signing as rain.forest.puppy) |rivista= [[Phrack Magazine]] |volume= 8 |numero= 54 (article 8) |data= 25 dicembre 1998 |url= http://www.phrack.com/issues.html?issue=54&id=8#article }}</ref>
== Descrizione ==
Sfrutta le [[vulnerabilità informatica|vulnerabilità di sicurezza]] del codice applicativo che si collega alla fonte dati SQL, ad esempio, sfruttando il mancato ''filtraggio'' dell'input dell'utente (es. 'caratteri di escape' nelle stringhe SQL) oppure la mancata [[tipizzazione forte]] delle variabili impiegate. È più conosciuto come attacco destinato ad [[Applicazione web|applicazioni web]], ma è anche usato per attaccare qualsiasi altro tipo di applicazione che impieghi in modo non sicuro database SQL.
Permette agli attaccanti di effettuare attività di [[IP spoofing|spoof identify]], modificare dati esistenti, causare repudiation issues come l'annullamento di transazioni o la modifica dei bilanci, permette di ottenere tutti i dati sul sistema, eliminare o rendere inaccessibile dei dati, e creare o compromettere gli utenti (e.g. amministratore) del database server.
In uno studio del 2012, è stato osservato che in media le applicazioni web ricevono 4 attacchi al mese, ed i rivenditori ricevono il doppio degli attacchi rispetto alle industrie.<ref>{{Cita web|url= http://www.imperva.com/docs/HII_Web_Application_Attack_Report_Ed4.pdf |titolo= Imperva Web Application Attack Report |accesso= 4 agosto 2013 |autore= Imperva |data= July 2012 |formato= PDF |citazione= Retailers suffer 2x as many SQL injection attacks as other industries. / While most web applications receive 4 or more web attack campaigns per month, some websites are constantly under attack. / One observed website was under attack 176 out of 180 days, or 98% of the time.}}</ref>
=== Tipi di SQL injection ===
L'SQL injection (SQLI) è considerata da [[OWASP|Open Web Application Security Project]] una delle 10 maggiori vulnerabilità delle applicazioni web nel 2007 e nel 2010.<ref>{{Cita web |url=https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project |titolo=Category:OWASP Top Ten Project |editore=OWASP |accesso=3 giugno 2011 |urlarchivio=https://web.archive.org/web/20191201191321/https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project |dataarchivio=1 dicembre 2019 |urlmorto=sì }}</ref> Nel 2013 e nel 2017 SQLI è stato considerato il numero uno degli attacchi sulla OWASP top 10.<ref>{{Cita web |url=https://www.owasp.org/index.php/Top_10_2013-Top_10 |titolo=Category:OWASP Top Ten Project |editore=OWASP |accesso=13 agosto 2013 |urlarchivio=https://web.archive.org/web/20131009150041/https://www.owasp.org/index.php/Top_10_2013-Top_10 |dataarchivio=9 ottobre 2013 |urlmorto=sì }}</ref> Ci sono quattro principali sotto classi di SQL injection:
* Classic SQLI
* Blind or Inference SQL injection
* [[Database management system]]-specific SQLI
* Compounded SQLI
** SQL injection + insufficient authentication<ref>{{Cita web |url=http://www.xiom.com/whid-2007-60 |titolo=WHID 2007-60: The blog of a Cambridge University security team hacked |editore=Xiom |accesso=3 giugno 2011 |urlmorto=sì |urlarchivio=https://web.archive.org/web/20110619071503/http://www.xiom.com/whid-2007-60 |dataarchivio=19 giugno 2011 }}</ref>
** SQL injection + [[DDoS]] attacks<ref>{{Cita web |url=http://www.xiom.com/content/whid-2009-1-gaza-conflict-cyber-war |titolo=WHID 2009-1: Gaza conflict cyber war |editore=Xiom |accesso=3 giugno 2011 |urlmorto=sì |urlarchivio=https://web.archive.org/web/20111007201703/http://www.xiom.com/content/whid-2009-1-gaza-conflict-cyber-war |dataarchivio=7 ottobre 2011 }}</ref>
** SQL injection + [[DNS hijacking]]<ref>{{cita web |url=http://www.xiom.com/whid-list/DNS%20Hijacking |titolo=Copia archiviata |accesso=22 maggio 2011 |urlmorto=sì |urlarchivio=https://web.archive.org/web/20100305182306/http://www.xiom.com/whid-list/DNS%20Hijacking |dataarchivio=5 marzo 2010 }} </ref>
** SQL injection + [[Cross-site scripting|XSS]]<ref>{{Cita web |url=http://www.darkreading.com/security/management/showArticle.jhtml?articleID=211201482 |titolo=Third Wave of Web Attacks Not the Last |editore=Dark Reading |accesso=29 luglio 2012 |urlmorto=sì }}</ref>
Lo [[Storm Worm]] è un esempio di utilizzo delle Compounded SQLI.<ref>{{Cita web|cognome=Danchev |nome=Dancho |url=https://ddanchev.blogspot.com/2007/01/social-engineering-and-malware.html|titolo=Mind Streams of Information Security Knowledge: Social Engineering and Malware |editore=Ddanchev.blogspot.com |data=23 gennaio 2007 |accesso=3 giugno 2011}}</ref>
Questa classificazione dello stato dell'SQLI rappresenta la sua evoluzione fino al 2010.<ref>{{Cita web|cognome=Deltchev|nome=Krassen|titolo=New Web 2.0 Attacks|url=http://www.nds.ruhr-uni-bochum.de/teaching/theses/Web20/|sito=B.Sc. Thesis|editore=Ruhr-University Bochum|accesso=18 febbraio 2010|dataarchivio=2 aprile 2012|urlarchivio=https://web.archive.org/web/20120402120703/http://www.nds.ruhr-uni-bochum.de/teaching/theses/Web20/|urlmorto=sì}}</ref>
== Implementazioni tecniche ==
=== Caratteri di escape non filtrati correttamente ===
Questo tipo di SQL injection si verifica quando non viene filtrato l'input dell'utente dai [[escape character|caratteri di escape]] e quindi vengono passati all'interno di uno statement. Questo può provocare la manipolazione degli statements eseguiti sul database dagli utenti finali dell'applicazione.
La seguente linea di codice illustra questo tipo di vulnerabilità:
<syntaxhighlight lang="C#" inline>statement = "</syntaxhighlight><syntaxhighlight lang="sql" inline>SELECT * FROM users WHERE name = '</syntaxhighlight><syntaxhighlight lang="C#" inline>"</syntaxhighlight><syntaxhighlight lang="C#" inline> + userName + "</syntaxhighlight><syntaxhighlight lang="sql" inline>';</syntaxhighlight><syntaxhighlight lang="C#" inline>"</syntaxhighlight>
Questo codice SQL recupera tutti i record che hanno un certo username dalla tabella users. Tuttavia, se un utente malintenzionato scrive la variabile “userName” in un certo modo, lo ''statement SQL'' può fare più di quello che era inteso dall'autore del codice. Per esempio, impostando la variabile “userName” come:
<pre>' OR '1'='1</pre>
Oppure usando dei commenti per non fare eseguire il resto della query (ci sono tre tipi di commenti SQL<ref>{{Cita pubblicazione |titolo= IBM Informix Guide to SQL: Syntax. Overview of SQL Syntax > How to Enter SQL Comments |editore= IBM |url= https://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls36.htm |urlmorto= sì }}</ref>). Tutte e tre le linee hanno uno spazio alla fine:
<pre>' OR '1'='1' --
' OR '1'='1' ({
' OR '1'='1' /* </pre>
Ecco come appare il rendering dello statement SQL dopo l'inserimento di una delle linee di codice con commento e senza:
<syntaxhighlight lang="sql">SELECT * FROM users WHERE name = '' OR '1'='1';</syntaxhighlight>
<syntaxhighlight lang="sql">SELECT * FROM users WHERE name = '' OR '1'='1' -- ';</syntaxhighlight>
Se questo codice fosse utilizzato in una procedura di [[autenticazione]], allora questo esempio potrebbe essere usato per forzare la selezione di tutti i campi dati (*) di "tutti" gli utenti piuttosto che di un singolo username come era inteso dal codice, ciò accade perché la valutazione di ‘1'='1' è sempre vera ([[short-circuit evaluation]]).
Nell'esempio di sotto il valore di “userName” causerebbe l'eliminazione della tabella “user” e la selezione di tutti i dati nella tabella “userinfo” (in pratica rivelando le informazioni di tutti gli utenti), usando un API che permette statement multipli:
a'; <syntaxhighlight lang="sql" inline> DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't</syntaxhighlight>
L'inserimento dell'input specificato sopra fa diventare lo statement SQL in questo modo:
<syntaxhighlight lang="sql">SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';</syntaxhighlight>
Mentre molte delle implementazioni dei server SQL permettono di eseguire statement multipli con un'unica chiamata, alcune di queste API come nella funzione <code>mysql_query()</code> di [[PHP]] non lo permettono per motivi di sicurezza. Questo evita che gli attaccanti iniettino delle query completamente separate all'interno dello statement, ma ciò non li ferma dal modificarle.
=== Gestione non corretta del tipo ===
Questo tipo di SQL injection si verifica quando un campo '''fornito dall'utente''' non è [[Tipizzazione forte|fortemente tipizzato]] o non vengono controllati i vincoli sul tipo. Questo può accadere, ad esempio, quando viene utilizzato un campo numerico in uno statement SQL, ma il programmatore non fa controlli per verificare che l'input immesso dall'utente sia effettivamente numerico. Per esempio:
statement:= "<syntaxhighlight lang="sql" inline>SELECT * FROM userinfo WHERE id = </syntaxhighlight>" + a_variable + ";"
Da questo statement è evidente che l'autore voleva che la variabile fosse un numero riferito al campo "id". Tuttavia se essa è di fatto una [[Stringa (informatica)|stringa]], allora l'[[Utilizzatore finale|utente finale]] potrebbe manipolare lo statement a suo piacimento, e quindi aggirare la necessità di caratteri di escape. Per esempio, impostando una variabile a
<pre>1;DROP TABLE users</pre>
Viene fatto il drop (eliminazione) della tabella "users" dal database, visto che lo statement SQL diventa:
<syntaxhighlight lang="sql">SELECT * FROM userinfo WHERE id=1; DROP TABLE users;</syntaxhighlight>
=== Blind SQL injection ===
Il Blind SQL Injection è usato quando un'applicazione web è vulnerabile ad SQLI ma i risultati dell'operazione non sono visibili all'attaccante. La pagina con la vulnerabilità potrebbe non essere una che mostra dei dati, ma può essere visualizzata differentemente a seconda del risultato dello statement di tipo logico iniettato dentro lo statement SQL originale, chiamato per quella pagina.
Questo tipo di attacco può impiegare un notevole dispendio di tempo perché bisogna creare un nuovo statement per ogni bit recuperato. Ci sono vari strumenti che permettono di automatizzare questi attacchi una volta che sono state individuate le vulnerabilità e qual è l'informazione obiettivo.<ref>{{Cita web |url= http://www.justinclarke.com/archives/2006/03/sqlbrute.html |titolo= Using SQLBrute to brute force data from a blind SQL injection point |editore= Justin Clarke |accesso= 18 ottobre 2008 |urlarchivio= https://web.archive.org/web/20080614203711/http://www.justinclarke.com/archives/2006/03/sqlbrute.html |dataarchivio= 14 giugno 2008 |urlmorto= sì }}</ref>
==== Risposte condizionali ====
Uno dei tipi di blind SQL injection forza il database a valutare uno statement logico su un'ordinaria schermata dell'applicazione. Ad esempio, un sito di recensioni sui libri usa una [[query string]] per decidere che recensione su quale libro mostrare. Quindi l'[[URL]] <code><nowiki>http://books.example.com/showReview.php?ID=5</nowiki></code> farà eseguire al server la query
<syntaxhighlight lang="sql">SELECT * FROM bookreviews WHERE ID = 'Value(ID)';</syntaxhighlight>
Con la quale popolerà la pagina con i dati della recensione con [[identificatore|ID]] 5, memorizzati nella tabella bookreviews. La query viene eseguita completamente sul server; quindi l'utente non saprà i nomi del database, della tabella, o dei campi, e nemmeno conoscerà la query string. L'utente vedrà soltanto che l'URL di sopra ritorna la recensione di un libro. Un [[Hacker]] può caricare i seguenti URL <code><syntaxhighlight lang="sql" inline>http://books.example.com/showReview.php?ID=5 OR 1=1</syntaxhighlight></code> e <code><syntaxhighlight lang="sql" inline>http://books.example.com/showReview.php?ID=5 AND 1=2</syntaxhighlight></code>, che potrebbero generare rispettivamente l'esecuzione di queste query:
<syntaxhighlight lang="sql">SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';</syntaxhighlight>
Se utilizzando l'URL con "1=1" viene caricata la recensione originale e con l'URL che ha "1=2" viene caricata una pagina bianca o d'errore, e la pagina ritornata non mostra all'utente che è appena stato inserito un URL non valido, è molto probabile che il sito sia vulnerabile ad attacchi di SQL injection perché vuol dire che entrambe le query potrebbero essere state eseguite correttamente dal database server. L'hacker potrebbe eseguire la seguente query string per venire a conoscenza del numero di versione di [[MySQL]] presente sul server: <code><syntaxhighlight lang="mysql" inline>http://books.example.com/showReview.php?ID=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4</syntaxhighlight></code>, una volta eseguita mostrerebbe la recensione del libro se il server utilizza MySQL 4 ed altrimenti una pagina bianca o d'errore. L'hacker può continuare ad usare del codice all'interno delle query string per ottenere sempre più informazioni sul server fino a quando non viene scoperta una nuova via di attacco oppure fino a quando i suoi obiettivi non siano raggiunti.<ref>{{Cita web|url=http://forum.intern0t.org/web-hacking-war-games/818-blind-sql-injection.html|titolo=Blind SQL Injection tutorial|autore=macd3v|accesso=6 dicembre 2012|urlmorto=sì|urlarchivio=https://web.archive.org/web/20121214193021/http://forum.intern0t.org/web-hacking-war-games/818-blind-sql-injection.html|dataarchivio=14 dicembre 2012}}</ref><ref>{{Cita web|titolo=TDSS botnet: full disclosure|url=http://nobunkum.ru/analytics/en-tdss-botnet|accesso=6 dicembre 2012|autore=Andrey Rassokhin|autore2=Dmitry Oleksyuk|urlarchivio=https://web.archive.org/web/20121209032723/http://nobunkum.ru/analytics/en-tdss-botnet|dataarchivio=9 dicembre 2012|urlmorto=sì}}</ref>
=== Second order SQL injection ===
Il Second order SQL injection si verifica quando i valori inviati dall'utente contengono comandi maligni che vengono salvati sul server piuttosto che venire eseguiti immediatamente. In alcuni 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 da SQL injections potrebbe eseguire lo statement memorizzato. Questo tipo di attacco richiede la conoscenza che i valori inviati vengano utilizzati successivamente. Gli scanner di sicurezza per applicazioni web potrebbero non accorgersi facilmente di questo tipo di SQL injection e potrebbero aver bisogno di essere istruite manualmente su dove cercare indizi sull'attacco.
== Prevenzione ==
L'SQL injection è un attacco molto conosciuto e facilmente evitabile con semplici misure. Dopo quello che si pensa fosse stato un attacco di SQL injection sull'azienda britannica TalkTalk Group, la BBC ha riportato come gli esperti di sicurezza fossero stupiti che una così grande compagnia fosse vulnerabile a questo tipo di attacco.<ref>{{Cita web|titolo= Questions for TalkTalk - BBC News|url= https://www.bbc.com/news/technology-34636308|sito= BBC News|accesso= 26 ottobre 2015|lingua= en}}</ref>
=== Statement parametrizzati ===
Con molte delle piattaforme di sviluppo, è possibile usare statement parametrizzati che lavorano con dei parametri (chiamati placeholder o bind variable) al posto di inserire direttamente l'input dell'utente direttamente nello statement. Un placeholder può memorizzare 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.
In molti casi, lo statement SQL viene invece fissato, ed ogni parametro è quindi uno scalare, e non una tabella. L'input dell'utente è quindi assegnato (legato) ad un parametro.<ref>{{Cita web|titolo=SQL Injection Prevention Cheat Sheet|url=https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet|editore=Open Web Application Security Project|accesso=3 marzo 2012|urlarchivio=https://web.archive.org/web/20151116090859/https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet|dataarchivio=16 novembre 2015|urlmorto=sì}}</ref>
==== Rafforzamento a livello di codice ====
Usare delle librerie di [[object-relational mapping]] evita di scrivere codice SQL. Le librerie ORM generano automaticamente degli statement SQL parametrizzati, partendo da del codice orientato agli oggetti.
=== Escape ===
Un modo diretto, anche se soggetto ad errori per prevenire attacchi di SQLI è quello di evitare caratteri che hanno un significato speciale in SQL. I manuali dei DBMS SQL spiegano quali caratteri hanno significati speciali, ciò permette di creare una lista di caratteri che devono essere sostituiti perché potenzialmente dannosi. Ad esempio, ogni apostrofo (<code>'</code>) in un parametro deve essere sostituito con due apostrofi (' ') per ottenere una stringa SQL di letterali valida. Per esempio, in PHP di solito si evitano i caratteri speciali nei parametri utilizzando la funzione <code>mysqli_real_escape_string();</code> prima di inviare la query SQL:
<syntaxhighlight lang="php">
$mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
$mysqli->real_escape_string($username),
$mysqli->real_escape_string($password));
$mysqli->query($query);
</syntaxhighlight>
Questa funzione antepone dei backslash ai seguenti caratteri: <code>\x00</code>, <code>\n</code>, <code>\r</code>, <code>\</code>, <code>'</code>, <code>"</code> e <code>\x1a</code>.
Essa è di solito usata per rendere sicure le query prima di inviare ad un database [[MySQL]].<ref>{{Cita web|url=http://in2.php.net/manual/en/mysqli.real-escape-string.php|titolo=mysqli->real_escape_string - PHP Manual|editore=PHP.net|accesso=7 aprile 2016|urlarchivio=https://web.archive.org/web/20160417223559/http://in2.php.net/manual/en/mysqli.real-escape-string.php|dataarchivio=17 aprile 2016|urlmorto=sì}}</ref><br />In PHP vi sono tante altre funzioni per vari tipi di database come <code>pg_escape_string()</code> per [[PostgreSQL]]. La funzione <code>addslashes(string $str)</code> serve ad evitare i caratteri speciali, ed è usata in particolare per fare query a database che non hanno funzioni di escape in PHP, essa ritorna una stringa con dei backslash prima dei caratteri che hanno bisogno di essere tra apici. Questi caratteri sono l'apostrofo ('), doppi apici ("), il backslash ed il carattere NULL.<ref>{{Cita web|url=http://pl2.php.net/manual/en/function.addslashes.php|titolo=Addslashes - PHP Manual|editore=PHP.net|urlmorto=sì|urlarchivio=https://web.archive.org/web/20110905022827/http://pl2.php.net/manual/en/function.addslashes.php|dataarchivio=5 settembre 2011}}</ref><br />
Fare sempre l'escape delle stringhe SQL è una pratica soggetta ad errori perché è facile dimenticare di fare l'escape di una determinata stringa. Creare un livello trasparente per rendere sicuro l'input può ridurre gli errori o eliminarli totalmente.<ref>{{Cita web|url=http://www.xarg.org/2010/11/transparent-query-layer-for-mysql/|titolo=Transparent query layer for MySQL|editore=Robert Eisele|data=8 novembre 2010}}</ref>
=== Controllo dei pattern ===
Si possono controllare parametri con stringhe di interi, float o booleani, e verificare se il loro valore ha una valida struttura per il tipo di dato controllato. Le stringhe che hanno una struttura abbastanza rigida (data, UUID, solo alfanumerici, ecc.) possono essere controllati per vedere se rispecchiano la struttura del tipo di dato.
=== Permessi del database ===
Limitare i permessi nel [[login]] usato dell'applicazione web per accedere al database, mettendo solo i permessi necessari, può servire a ridurre l'efficacia di qualsiasi attacco di SQL injection, mirato a dei bug dell'applicazione.
Per esempio, su [[Microsoft SQL Server]], si può proibire al logon del database di fare una select ad alcune delle tabelle di sistema, in questa maniera viene evitato che venga inserito del JavaScript all'interno di tutte le colonne del database <syntaxhighlight lang="tsql">
deny select on sys.sysobjects to webdatabaselogon;
deny select on sys.objects to webdatabaselogon;
deny select on sys.tables to webdatabaselogon;
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;
</syntaxhighlight>
=== Conversione esadecimale ===
La conversione esadecimale viene fatta convertendo del semplice testo nella sua rappresentazione esadecimale prima di usarlo in un comando SQL. In PHP, le funzioni usate sono la funzione <kbd>''bin2hex''()</kbd><ref>https://php.net/manual/en/function.bin2hex.php</ref> o <kbd>''dechex''</kbd><ref>https://php.net/manual/en/function.dechex.php</ref>. La funzione <kbd>''bin2hex()''</kbd> è da preferire visto che converte qualsiasi carattere e non solo numeri. In questa sezione verrà usata solo la funzione <kbd>''bin2hex()''</kbd>.
Esempio di utilizzo della funzione di PHP <kbd>''bin2hex()''</kbd>:
<syntaxhighlight lang="php">
echo bin2hex("test");
</syntaxhighlight>
L'output della funzione sopra è:
<kbd>74657374</kbd>
A scopo d'esempio parliamo soltanto del database <kbd>MySQL</kbd><ref>https://www.mysql.com/</ref>. In MySQL, la funzione <kbd>''unhex()''</kbd><ref>https://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_unhex</ref> è usata per riconvertire una stringa esadecimale in semplice testo.
Esempio della funzione <kbd>''unhex()''</kbd> in MySQL:
<syntaxhighlight lang="sql">
SELECT * FROM myTable WHERE id=unhex('32');
</syntaxhighlight>
Se convertissimo la stringa con <kbd>''unhex()''</kbd> in semplice testo diventerebbe:
<syntaxhighlight lang="sql">
SELECT * FROM myTable WHERE id=2;
</syntaxhighlight>
La conversione esadecimale elimina gli attacchi di SQL injection perché la stringa esadecimale inviata alla funzione <kbd>''unhex()''</kbd> viene ritornata come stringa già utilizzata e non viene interpretata.
==== Esempio di programmazione ====
Nel seguente breve programma viene presentato un programma in PHP ed una sua funzione. Il programma mostra un attacco di SQL injection su un semplice comando SQL. Successivamente, mostra come convertendo tutti i dati in entrata in esadecimale, riesce a fermare l'attacco. La funzione PHP è un semplice insieme di comandi per il database e per il recupero dell'output dal database SQL. Come detto sopra il database usato è MySQL.
===== Codice d'esempio =====
<syntaxhighlight lang="php">
File: test.php
<?php
include_once "dosql.php";
#
# Metti le informazioni sul tuo database qui. Sto usando i dati del mio file di log.
#
$hostname = "myhost";
$username = "myUser";
$password = "myPassword";
$database = "myDatabase";
$mysqli = new mysqli($hostname, $username, $password, $database);
if ($mysqli->connect_errno) {
echo "Failed to connect to MySQL: (", $mysqli->connect_errno, ") ", $mysqli->connect_error;
exit;
}
echo "SQL INJECTION - Plain\n";
$sql = "SELECT * FROM log WHERE log_id='2' OR 1=1; #'";
$res = dosql($sql);
foreach ($res[0] as $k => $v) {
echo "RES[$k] = $v\n";
}
echo "\n\nSQL INJECTION = Hexadecimal\n";
$sql = "SELECT * FROM log WHERE log_id=unhex('" . bin2hex("2' or 1=1; #'") . "')";
$res = dosql($sql);
foreach ($res[0] as $k => $v) {
echo "RES[$k] = $v\n";
}
exit;
?>
File: dosql.php
<?php
################################################################################
# dosql(). Do the SQL command.
################################################################################
function dosql($sql)
{
global $mysqli;
$cmd = "INSERT INTO log (date,entry) VALUES (NOW(), unhex('" . bin2hex($sql) . "'))";
$res = $mysqli->query($cmd);
$res = $mysqli->query($sql);
if (!$res) {
$array = debug_backtrace();
if (isset($array[1])) { $a = $array[1]['line']; }
else if (isset($array[0])) { $a = $array[0]['line']; }
else { $a = "???"; }
echo "ERROR @ ", $a, " : (", $mysqli->errno, ")\n", $mysqli->error, "\n\n";
echo "SQL = $sql\n";
exit;
}
if (preg_match("/INSERT/i", $sql)) { return $mysqli->insert_id; }
if (preg_match("/DELETE/i", $sql)) { return null; }
if (!is_object($res)) { return null; }
$count = -1;
$array = array();
$res->data_seek(0);
while ($row = $res->fetch_assoc()) {
$count++;
foreach ($row as $k => $v) { $array[$count][$k] = $v; }
}
return $array;
}
</syntaxhighlight>
===== Output del programma =====
<syntaxhighlight lang="text">
SQL INJECTION - Plain
RES[log_id] = 1
RES[date] = 2015-03-25 10:40:18
RES[entry] = SHOW full columns FROM log
SQL INJECTION = Hexadecimal
RES[log_id] = 2
RES[date] = 2015-03-25 10:40:18
RES[entry] = SELECT * FROM log ORDER BY title ASC
</syntaxhighlight>
La prima parte dell'output del programma mostra l'invio del comando SQL senza fare controllo o modifiche. La richiesta originale dovrebbe far ritornare il secondo record, ma grazie all'SQL injection viene ritornato il primo record. La seconda parte dell'output mostra invece cosa succede se vengono convertiti tutti i dati in ingresso in esadecimale. Usando la conversione, tutti i caratteri nel comando, inclusi quelli inseriti dall'SQL injection, vengono convertiti in esadecimale e non sono più un pericolo perché non vengono interpretati come comandi ma come stringhe. Visto che tutti i caratteri vengono trattati come parte dell'intera stringa, se MySQL capisce che ha bisogno di un numero, converte la stringa in numero. Le regole per la conversione da stringa a numero, sono di convertire<ref>https://dev.mysql.com/doc/refman/5.0/en/type-conversion.html</ref> la stringa fino a quando non raggiunge un carattere non numerico o la fine della stringa. Quando si verifica uno di questi due eventi, la conversione si arresta in quel punto. Quindi, viene visto il “2” e poi l'apostrofo (‘), il che dice a My SQL di terminare la conversione della stringa. Infine il valore numerico due(2) viene usato per determinare quale record ritornare. Questo processo o metodo di valutazione dei dati in ingresso è il motivo per cui non possono avvenire attacchi di SQL injection se si usa una conversione esadecimale.
==== Considerazioni aggiuntive ====
In aggiunta, l'utilizzo di BIN2HEX and UNHEX richiede meno tempo d'esecuzione rispetto agli altri metodi presentati. Questo accade principalmente per la natura semplicistica di entrambe le funzioni. Come mostrato nello snippet JavaScript, convertire in esadecimale è piuttosto semplice e diretto:
===== Codice d'esempio =====
<syntaxhighlight lang='javascript'>
File: toHex.js
////////////////////////////////////////////////////////////////////////////////
// toHex(). Converte una stringa in esadecimale.
////////////////////////////////////////////////////////////////////////////////
function toHex(s)
{
var l = "0123456789ABCDEF";
var o = "";
if (typeof s != "string") { s = s.toString(); }
for (var i = 0; i < s.length; i++) {
var c = s.charCodeAt(i);
o = o + l[(c >> 4)] + l[(c & 0xf)];
}
return o;
}
</syntaxhighlight>
Come mostrato, a differenza di <kbd>''mysqli_real_escape_string()''</kbd><ref>https://php.net/manual/en/function.mysql-real-escape-string.php</ref> con il quale deve essere fatto il test di escape per ogni differente, <kbd>''bin2hex()''</kbd> converte semplicemente tutti i caratteri nel loro corrispettivo esadecimale. E la funzione <kbd>''unhex()''</kbd>fa l'operazione opposta. Visto che non devono essere fatti test per un particolare carattere o caratteri, il ciclo di conversione è piccolo ed efficiente. Inoltre, a differenza di <kbd>''mysqli_real_escape_string()''</kbd>, se in futuro dovesse essere scoperto un nuovo metodo, la funzione <kbd>''bin2hex()''</kbd> disabiliterà automaticamente la combinazione di caratteri, perché ritorna una stringa esadecimale. Un esempio di questo è il carattere Control-D ASCII.<ref>http://www.ascii-code.com/</ref> Control-D può provocare una condizione "Fine della trasmissione"<ref>http://www.asciitable.com/</ref> in alcuni linguaggi. Se viene usata la funzione <kbd>''bin2hex()''</kbd> il Control-D diventa semplicemente il semplice testo ASCII “04” che non può causare problemi.
== Esempi ==
* Nel febbraio del 2002, Jeremiah Jacks scoprì che Guess.com era vulnerabile ad un attacco di SQL injection, permettendo a chiunque fosse stato in grado di {{chiarire|creare un URL creata ad hoc}} di recuperare più di 200 000 nomi, numeri e date di scadenza di carte di credito nel database dei clienti del sito.<ref>{{Cita web|url=http://www.securityfocus.com/news/346|titolo=Guesswork Plagues Web Hole Reporting|editore=[[SecurityFocus]]|data=6 marzo 2002}}</ref>
* Il 1º novembre 2005, un hacker minorenne ha usato un attacco di SQL injection per entrare nel sito di una rivista di sicurezza informatica [[Taiwan]]ese della Tech Target Group e rubare informazioni sui clienti.<ref>{{Cita web|url=http://www.xiom.com/whid-2005-46|titolo=WHID 2005-46: Teen uses SQL injection to break to a security magazine web site|editore=[[Web Application Security Consortium]]|data=1º novembre 2005|accesso=1º dicembre 2009|urlmorto=sì|urlarchivio=https://web.archive.org/web/20100117054540/http://www.xiom.com/whid-2005-46|dataarchivio=17 gennaio 2010}}</ref>
* Il 13 gennaio 2006, dei criminali informatici russi sono entrati nel sito del governo di Rhode ed hanno rubato dati sulle carte di credito degli individui che avevano fatto affari con le agenzie di stato.<ref>{{Cita web|url=http://www.xiom.com/whid-2006-3|titolo=WHID 2006-3: Russian hackers broke into a RI GOV website|editore=[[Web Application Security Consortium]]|data=13 gennaio 2006|accesso=16 maggio 2008|urlmorto=sì|urlarchivio=https://web.archive.org/web/20110213051033/http://www.xiom.com/whid-2006-3|dataarchivio=13 febbraio 2011}}</ref>
* Il 29 marzo 2006, un hacker scoprì una vulnerabilità all'SQL injection su un sito ufficiale per il turismo del governo indiano.<ref>{{Cita web|url=http://www.xiom.com/whid-2006-27|titolo=WHID 2006-27: SQL Injection in incredibleindia.org|editore=[[Web Application Security Consortium]]|data=29 marzo 2006|accesso=12 marzo 2010|urlmorto=sì|urlarchivio=https://web.archive.org/web/20090701130734/http://www.xiom.com/whid-2006-27|dataarchivio=1º luglio 2009}}</ref>
* Il 29 giugno 2009, un criminale informatico deturpò il [[sito web]] di e [[Microsoft]] UK usando un attacco di SQLI.<ref>{{Cita web|url=http://www.cgisecurity.net/2007/06/hacker-defaces.html|titolo=Hacker Defaces Microsoft U.K. Web Page|editore=cgisecurity.net|autore=Robert|data=29 giugno 2007|accesso=16 maggio 2008}}</ref><ref>{{Cita web|url=https://rcpmag.com/news/article.aspx?editorialsid=8762|titolo=Hacker Defaces Microsoft UK Web Page|editore=Redmond Channel Partner Online|autore=Keith Ward|data=29 giugno 2007|accesso=16 maggio 2008|urlarchivio=https://web.archive.org/web/20071223181645/http://rcpmag.com/news/article.aspx?editorialsid=8762|dataarchivio=23 dicembre 2007|urlmorto=sì}}</ref> Un sito web britannico, ''[[The Register]]'' riportò che un portavoce di Microsoft avesse confermato il problema.
* Nel gennaio 2008, decine di migliaia di PC furono infettati da un attacco di SQL injection automatizzato che sfruttava le vulnerabilità nel codice che usava [[Microsoft SQL Server]]<ref name="chinesefarm" />
* Nel gennaio 2008, il sito del malesiano [[Kaspersky Lab]] fu violato da un hacker turco conosciuto con lo pseudonimo "m0sted", che disse di aver usato un SQL injection.
* Nel febbraio del 2013, un gruppo di hacker delle Maldive violò il sito " UN-Maldives" usando l'SQL Injection.
* Il 27 maggio 2009, gli investigatori [[Anti-U.S. Hackers Infiltrate Army Servers]] dissero di credere di aver ricevuto un attacco chiamato SQL injection che sfruttava una vulnerabilità di sicurezza di Microsoft SQL Server per entrare nei web server. "m0sted" è conosciuto per aver effettuato attacchi simili in molti altri siti nel passato.
* Nel maggio del 2008, una [[server farm]] in [[Cina]] usò delle query automatizzate inviate a [[Google Search|Google's search engine]] per identificare dei siti web che usassero SQL server, che era vulnerabile ad un SQLI tool.<ref name="chinesefarm">{{Cita web |url= https://www.pcworld.com/businesscenter/article/146048/mass_sql_injection_attack_targets_chinese_web_sites.html |titolo= Mass SQL Injection Attack Targets Chinese Web Sites |autore= Sumner Lemon, IDG News Service |editore= [[PCWorld]] |data= 19 maggio 2008 |accesso= 27 maggio 2008 |dataarchivio= 26 maggio 2008 |urlarchivio= https://web.archive.org/web/20080526210653/http://www.pcworld.com/businesscenter/article/146048/mass_sql_injection_attack_targets_chinese_web_sites.html |urlmorto= sì }}</ref><ref name="attackspecifics">{{Cita web |url= http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx |titolo= ASCII Encoded/Binary String Automated SQL Injection Attack |autore= Michael Zino |data= 1º maggio 2008 |accesso= 7 aprile 2016 |urlarchivio= https://web.archive.org/web/20080601094431/http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx |dataarchivio= 1 giugno 2008 |urlmorto= sì }}</ref>
* Nel 2008, almeno da aprile ad agosto, una serie di attacchi comincio a sfruttare le vulnerabilità ad SQLI di [[Internet Information Services|IIS web server]] e SQL Server. L'attacco non richiedeva di indovinare il nome di una tabella o la colonna, e corrompeva tutte le colonne di testo in tutte le tabelle in una sola richiesta.<ref name="broad_inject_specifics">{{Cita web|url= https://hackademix.net/2008/04/26/mass-attack-faq/ |titolo= Mass Attack FAQ |autore=Giorgio Maone|data= 26 aprile 2008 }}</ref> Ad ogni valore veniva appeso una stringa HTML con un riferimento ad un [[malware]] [[JavaScript]]. Quando successivamente, veniva visualizzato il valore al visitatore del sito, lo script tentava vari approcci per prendere il controllo del sistema del visitatore. Il numero delle pagine web sfruttate si stima fosse attorno alle 500,000.<ref name="broad_inject_numbers">{{Cita news |url=https://www.computerworld.com/article/2535473/huge-web-hack-attack-infects-500-000-pages.html |titolo=Huge Web hack attack infects 500,000 pages |pubblicazione=[[Computerworld (blog)|Computerworld]] |nome=Gregg |cognome=Keizer |data=25 aprile 2008 |accesso=16 ottobre 2015 |lingua=en}}</ref>
* Il 17 agosto 2009, il Dipartimento di giustizia degli USA accusò un cittadino americano, [[Albert Gonzalez]], e due russi del furto di 130 milioni di numeri di carte di credito avendo usato un attacco di SQLI. È riportato come "il maggiore caso di furto di identità nella storia americana".<ref>{{Cita news|url=http://news.bbc.co.uk/2/hi/americas/8206305.stm |titolo=US man 'stole 130m card numbers' |editore=BBC |data=17 agosto 2009 |accesso=17 agosto 2009}}</ref>
* Nel dicembre 2009, un hacker riuscì ad accedere a un database della [[RockYou]] che conteneva le [[password]] e gli username non criptati di circa 32 milioni di utenti usando un attacco di SQLI.<ref>{{Cita news|url=https://www.nytimes.com/external/readwriteweb/2009/12/16/16readwriteweb-rockyou-hacker-30-of-sites-store-plain-text-13200.html |titolo= RockYou Hacker - 30% of Sites Store Plain Text Passwords |pubblicazione=New York Times |nome=Jolie |cognome=O'Dell |data=16 dicembre 2009 |accesso=23 maggio 2010}}</ref>
* Nel giugno del 2010, un ricercatore sulla sicurezza sud americano che va con lo pseudonimo "Ch Russo" ottenne informazioni sensibili sugli utenti di un popolare sito per il [[BitTorrent]], cioè [[The Pirate Bay]]. Ottenne l'accesso al pannello di controllo da amministratore del sito, e sfruttò una vulnerabilità di SQLI che gli rese possibile ottenere informazioni sugli account degli utenti, inclusi indirizzi IP, [[MD5]] [[Cryptographic hash function|password hashes]] e record di quali torrent ogni utente aveva caricato.<ref>{{Cita news|url=https://krebsonsecurity.com/2010/07/pirate-bay-hack-exposes-user-booty/ |titolo= The pirate bay attack |data=7 luglio 2010 }}</ref>
* Dal 24 al 26 luglio 2010, degli hacker dal [[Giappone]] e dalla Cina usarono un SQL injection per ottenere l'accesso ai dati sulle carte di credito dei clienti della Neo BEAT, una compagnia di Osaka che gestisce il sito di un grosso supermercato online. L'attacco ha danneggiato anche sette partner in affari come le catene di supermercati Izumiya Co, Maruetsu Inc, e Ryukyu Jusco Co. Il furto dei dati riguardò 12 191 clienti. Il 14 agosto 2010 sono stati riportati più di 300 casi di informazioni sulle carte di credito usate per acquistare beni e servizi in Cina.
* Il 19 settembre 2010, durante le elezioni generali svedesi del 2010, un votante tentò una code injection a mano, scrivendo dei comandi SQL sulla scheda elettorale.<ref>{{Cita web|url=http://alicebobandmallory.com/articles/2010/09/23/did-little-bobby-tables-migrate-to-sweden |titolo=Did Little Bobby Tables migrate to Sweden? |editore=Alicebobandmallory.com |accesso=3 giugno 2011}}</ref>
* L'8 novembre 2010, il sito britannico [[Royal Navy]] fu compromesso da un hacker romeno chiamato TinKode che usò un attacco di SQL injection.<ref>[https://www.bbc.co.uk/news/technology-11711478 Royal Navy website attacked by Romanian hacker] ''BBC News'', 8-11-10, Accessed November 2010</ref><ref>{{Cita web|url=http://news.sky.com/skynews/Home/World-News/Stuxnet-Worm-Virus-Targeted-At-Irans-Nuclear-Plant-Is-In-Hands-Of-Bad-Guys-Sky-News-Sources-Say/Article/201011415827544 |titolo=Super Virus A Target For Cyber Terrorists
|autore=Sam Kiley |data=25 novembre 2010 |accesso=25 novembre 2010}}</ref>
* Il 5 febbraio 2011, la [[HBGary]], un'azienda di sicurezza informatica, fu penetrata [[LulzSec]] usando l'SQL injection sul loro sito di tipo CMS-driven.<ref>{{Cita web|url=http://www.par-anoia.net/We_Are_Anonymous_Inside_the_Hacker_World_of_LulzSe.pdf|titolo=We Are Anonymous: Inside the Hacker World of LulzSec|editore=Little, Brown and Company|urlmorto=sì|urlarchivio=https://web.archive.org/web/20120718111038/http://www.par-anoia.net/We_Are_Anonymous_Inside_the_Hacker_World_of_LulzSe.pdf|dataarchivio=18 luglio 2012}}</ref>
* Il 27 marzo 2011 mysql.com, il sito ufficiale di [[MySQL]], fu compromesso da un hacker che usò un attacco di Blind SQL injection.<ref>{{Cita web|url=http://blog.sucuri.net/2011/03/mysql-com-compromised.html|titolo=MySQL.com compromised|editore=[[sucuri]]}}</ref>
* L'11 aprile 2011, la [[Barracuda Networks]] fu compromessa a causa di una vulnerabilità ad SQLi. Furono ottenuti indirizzi email ed username degli impiegati.<ref>{{Cita web |url=http://www.networkworld.com/news/2011/041211-hacker-breaks-into-barracuda-networks.html?hpg1=bn |titolo=Hacker breaks into Barracuda Networks database |urlmorto=sì |urlarchivio=https://web.archive.org/web/20110727234547/http://www.networkworld.com/news/2011/041211-hacker-breaks-into-barracuda-networks.html?hpg1=bn |dataarchivio=27 luglio 2011 }}</ref>
* Durante un periodo di 4 ore, il 27 aprile del 2011, si verificò un attacco automatizzato di SQL injection sul sito di [[Broadband Reports]] che fu capace di ottenere l'8% dell coppie username/password, 8000 account casuali sui 9000 attivi e 90000 account vecchi o inattivi.<ref name="DSLReports">{{Cita web|url=https://www.dslreports.com/forum/r25793356- |titolo=site user password intrusion info |editore=Dslreports.com |accesso=3 giugno 2011}}</ref><ref name="Cnet News">{{Cita news|url=http://news.cnet.com/8301-27080_3-20058471-245.html|titolo=DSLReports says member information stolen|editore=Cnet News|data=28 aprile 2011|accesso=29 aprile 2011|pubblicazione=|dataarchivio=21 marzo 2012|urlarchivio=https://web.archive.org/web/20120321203011/http://news.cnet.com/8301-27080_3-20058471-245.html|urlmorto=sì}}</ref><ref name="The Tech Herald">{{Cita news|url=http://www.thetechherald.com/article.php/201117/7127/DSLReports-com-breach-exposed-more-than-100-000-accounts|titolo=DSLReports.com breach exposed more than 100,000 accounts|editore=The Tech Herald|data=29 aprile 2011|accesso=29 aprile 2011|urlmorto=sì|urlarchivio=https://web.archive.org/web/20110430234009/http://www.thetechherald.com/article.php/201117/7127/DSLReports-com-breach-exposed-more-than-100-000-accounts|dataarchivio=30 aprile 2011}}</ref>
* Il 1º giugno del 2011, gli "[[hacktivism|hacktivisti]]" del gruppo [[LulzSec]] furono accusati di aver rubato dei [[coupon]], download keys e passwords che erano memorizzate nel database di testo sul sito della [[Sony]], accedendo alle informazioni personali di milioni di utenti.<ref>{{Cita pubblicazione |titolo= LulzSec hacks Sony Pictures, reveals 1m passwords unguarded |data= 2 giugno 2011 |pubblicazione= electronista.com |url= http://www.electronista.com/articles/11/06/02/lulz.security.hits.sony.again.in.security.message/ |accesso= 7 aprile 2016 |urlarchivio= https://web.archive.org/web/20110606051745/http://www.electronista.com/articles/11/06/02/lulz.security.hits.sony.again.in.security.message |dataarchivio= 6 giugno 2011 |urlmorto= sì }}</ref><ref>{{Cita pubblicazione |titolo= LulzSec Hacker Arrested, Group Leaks Sony Database |autore= Ridge Shan |data= 6 giugno 2011 |pubblicazione= The Epoch Times |url= http://www.theepochtimes.com/n2/technology/lulzsec-member-arrested-group-leaks-sony-database-57296.html |accesso= 7 aprile 2016 |dataarchivio= 7 giugno 2011 |urlarchivio= https://web.archive.org/web/20110607003940/http://www.theepochtimes.com/n2/technology/lulzsec-member-arrested-group-leaks-sony-database-57296.html |urlmorto= sì }}</ref>
* Nel giugno del 2011, [[PBS (azienda)|PBS]] fu hackerata, molto probabilmente tramite SQLi; il processo completo usato dagli hacker per eseguire l'attacco è descritto su questo blog [http://blog.imperva.com/2011/05/pbs-breached-how-hackers-probably-did-it.html Imperva] .<ref name="PBS Breached - How Hackers Probably Did It">{{Cita news|url=http://blog.imperva.com/2011/05/pbs-breached-how-hackers-probably-did-it.html|titolo=Imperva.com: PBS Hacked - How Hackers Probably Did It|accesso=1º luglio 2011}}</ref>
* Nel maggio del 2012, il sito web di ''[[Wurm Online]]'', un [[massively multiplayer online game]], fu buttato giù tramite un attacco di SQL injection mentre il sito veniva aggiornato.<ref>{{Cita web|url=http://wurmonline.tumblr.com/post/22835329693/wurm-online-restructuring |titolo=Wurm Online is Restructuring |data=11 maggio 2012}}</ref>
* Nel giugno del 2012, un gruppo di hacker rubò 450,000 credenziali di accesso da [[Yahoo!]]. I login erano memorizzati in semplice testo. Il gruppo sfondò la sicurezza di Yahoo tramite una "[[Set operations (SQL)#UNION operator|union]]-based SQL injection technique".<ref>Chenda Ngak. [https://www.cbsnews.com/8301-501465_162-57470956-501465/yahoo-reportedly-hacked-is-your-account-safe/ "Yahoo reportedly hacked: Is your account safe?"], CBS News. July 12, 2012. Retrieved July 16, 2012.</ref><ref>https://www.zdnet.com/450000-user-passwords-leaked-in-yahoo-breach-7000000772/</ref>
* Il 1º ottobre del 2012, un gruppo di hacker chiamati "Team GhostShell" pubblicò i record personali degli studenti, facoltà, dipendenti, laureati, di 53 università, incluse [[Harvard]], [[Princeton University|Princeton]], [[Università di Stanford|Stanford]], [[Cornell University|Cornell]], [[Johns Hopkins University|Johns Hopkins]], e l'[[University of Zurich]] su [[Pastebin|pastebin.com]]. Gli hacker dissero che volevano "fare prendere coscienza dei cambiamenti nell'educazione di oggi", lamentandosi del cambiamento delle leggi sull'educazione in Europa, e l'incremento delle tasse scolastiche negli USA.<ref>{{Cita news|cognome=Perlroth|nome=Nicole|titolo=Hackers Breach 53 Universities and Dump Thousands of Personal Records Online|url=https://bits.blogs.nytimes.com/2012/10/03/hackers-breach-53-universities-dump-thousands-of-personal-records-online/|giornale=New York Times|data=3 ottobre 2012}}</ref>
* Il 27 giugno 2013, il gruppo hacker "[[RedHack]]" sfondò il sito dell'amministrazione di Istanbul.<ref>{{Cita news|titolo=RedHack Breaches Istanbul Administration Site, Hackers Claim to Have Erased Debts |url=http://news.softpedia.com/news/RedHack-Breaches-Istanbul-Administration-Site-Hackers-Claim-to-Have-Erased-Debts-364000.shtml}}</ref> Essi affermarono che avrebbero cancellato i debiti che le persone avevano con compagnie dell'acqua, gas, internet, elettricità e telefono. Inoltre, pubblicarono username e password di amministratore per fare in modo che i cittadini potessero fare login e cancellare i loro debiti. Annunciarono questa notizia tramite [[Twitter]].<ref>{{Cita news|titolo=Redhack tweet about their achievement |url=https://twitter.com/RedHack_EN/statuses/350461821456613376 }}</ref>
* Il 4 novembre 2014, il gruppo di hacktivisti "RaptorSwag" compromise 71 database del governo cinese usando un attacco di SQL injection sul sito della camera del commercio cinese. I dati fatti trapelare furono postati pubblicamente assieme alla cooperazione di [[Anonymous]].<ref>http://news.softpedia.com/news/Hackers-Leak-Data-Allegedly-Stolen-from-Chinese-Chamber-of-Commerce-Website-396936.shtml</ref>
* In 2 febbraio 2014, un gruppo di hacker chiamato @deletesec fece trapelare 40,000 account dal sito di AVS TV.<ref>http://www.maurihackers.info/2014/02/40000-avs-tv-accounts-leaked.html</ref>
* Il 21 febbraio 2014, il forum di Governance degli Stati Uniti ebbe un attacco che portò l'esposizione di 3,215 account.<ref>{{Cita web |url=http://www.batblue.com/united-nations-internet-governance-forum-breached/ |titolo=Copia archiviata |accesso=7 aprile 2016 |dataarchivio=19 febbraio 2015 |urlarchivio=https://web.archive.org/web/20150219165019/http://www.batblue.com/united-nations-internet-governance-forum-breached/ |urlmorto=sì }}</ref>
* Il 21 febbraio 2014, un gruppo di hacker chiamato @deletesec hackerò Spirol International dopo minacciarono di fare arrestare gli hacker per aver riportato la vulnerabilità di sicurezza. Furono esposti i dettagli di 70,000 utenti durante questo conflitto.<ref>http://news.softpedia.com/news/Details-of-70-000-Users-Leaked-by-Hackers-From-Systems-of-SPIROL-International-428669.shtml</ref>
* Nell'ottobre del 2015, si crede sia stato usato un attacco di SQL injection ai danni dei server di una compagnia di telecomunicazioni inglese, la [[TalkTalk Group|Talk Talk]], rubando i dati personali di milioni di consumatori.<ref>{{Cita web |url=http://www.mobilenewscwp.co.uk/2015/10/23/talktalk-hacking-scandal-expert-reaction |titolo=Mobile News article |accesso=7 aprile 2016 |urlarchivio=https://web.archive.org/web/20160513025801/http://www.mobilenewscwp.co.uk/2015/10/23/talktalk-hacking-scandal-expert-reaction/ |dataarchivio=13 maggio 2016 |urlmorto=sì }}</ref>
== Riferimenti nella cultura di massa ==
* Il login non autorizzato su un sito web tramite SQL injection fornisce uno spunto narrativo per la trama del romanzo ''[[Il seggio vacante]]'' di [[J. K. Rowling]], pubblicato nel 2012.
* Una striscia del webcomic ''[[xkcd]]'' riguarda un personaggio chiamato "Robert'); DROP TABLE students;--", il cui nome permette di effettuare una SQL injection. In riferimento a questa striscia l'SQL injection a volte chiamata in modo informale 'Bobby Tables'.<ref>{{Cita web|cognome=Munroe|nome=Randall|titolo=XKCD: Exploits Of A Mom|url=https://xkcd.com/327/|accesso=26 febbraio 2013}}</ref><ref>{{Cita web|titolo=Bobby Tables: A guide to preventing SQL injection|url=http://bobby-tables.com/|accesso=6 ottobre 2013}}</ref>
* Nel 2014 un soggetto in Polonia ha legalmente rinominato la sua impresa in ''<nowiki>Dariusz Jakubowski x'; DROP TABLE users; SELECT '1</nowiki>'' con lo scopo di ostacolare le operazioni degli spammer [[Web scraping|harvesting bots]].<ref>{{Cita web|titolo=Jego firma ma w nazwie SQL injection. Nie zazdrościmy tym, którzy będą go fakturowali ;)|sito=Niebezpiecznik|lingua=pl|data=11 settembre 2014|url=http://niebezpiecznik.pl/post/jego-firma-ma-w-nazwie-sql-injection-nie-zazdroscimy-tym-ktorzy-beda-go-fakturowali/|accesso=26 settembre 2014}}</ref>
== Note ==
<references />
== Voci correlate ==
* [[Code injection]]
* [[Cross-site scripting]]
* [[Metasploit Project]]
* [[OWASP]] Open Web Application Security Project
* [[Uncontrolled format string]]
* [[w3af]]
* [[Web application security]]
* [[XML external entity]]
== Collegamenti esterni ==
* {{Collegamenti esterni}}
<!-- * [http://www.
* [https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html OWASP SQL Injection Cheat Sheets], by OWASP.
*[https://www.exploit-db.com/docs/english/17397-blind-sql-injection-with-regular-expressions-attack.pdf Blind Sql Injection – Regular Expressions AttackBlind Sql Injection with Regular Expressions Attack]
* [http://projects.webappsec.org/SQL-Injection WASC Threat Classification - SQL Injection Entry], by the Web Application Security Consortium.
* [https://web.archive.org/web/20121109235333/http://docs.google.com/leaf?id=0BykNNUTb95yzYTRjMjNjMWEtODBmNS00YzgwLTlmMGYtNWZmODI2MTNmZWYw&sort=name&layout=list&num=50 Why SQL Injection Won't Go Away], by Stuart Thomas.
* [https://web.archive.org/web/20151107080700/http://www.unixwiz.net/techtips/sql-injection.html SQL Injection Attacks by Example], by Steve Friedl
* [https://web.archive.org/web/20141211215029/http://www.breakthesecurity.com/2010/12/hacking-website-using-sql-injection.html SQL Injection Tutorial], by BTS.
* [http://sqlmap.org/ sqlmap: automatic SQL injection and database takeover tool]
* [https://go.microsoft.com/?linkid=9707610 SDL Quick security references on SQL injection] by Bala Neerumalla.
* [http://www.greensql.com/articles/backdoor-webserver-using-mysql-sql-injection Backdoor Web-server using MySQL SQL Injection] {{Webarchive|url=https://web.archive.org/web/20130402121201/http://www.greensql.com/articles/backdoor-webserver-using-mysql-sql-injection |data=2 aprile 2013 }} By Yuli Stremovsky
* [https://slides.com/abhinavsejpal/sql-injection-for-beginners#/ Attacking web App with SQL injection] by Abhinav Sejpal
{{Portale|sicurezza informatica}}
[[Categoria:Tecniche di attacco informatico]]
[[Categoria:Gestione dei dati]]
| |||