SQL injection: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
→Esempi: fix quote |
Nessun oggetto della modifica Etichette: Modifica visuale Modifica da mobile Modifica da web per mobile |
||
| (44 versioni intermedie di 29 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 ''
== Storia ==▼
Sfrutta le [[vulnerabilità|vulnerabilità di sicurezza]] del codice di un'applicazione, ad esempio quando l'input dell'utente non è correttamente filtrato da 'caratteri di escape' contenuti nelle stringhe SQL oppure non è [[Tipizzazione forte|fortemente tipizzato]] e viene eseguito inaspettatamente. È più conosciuto come attacco per i [[sito web|siti web]], ma è anche usato per attaccare qualsiasi tipo di database SQL.▼
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 ==
Permette agli attaccanti di effettuare [[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 dati oppure fare in modo che non siano accessibili, e diventare amministratori del database server.▼
▲Sfrutta le [[vulnerabilità informatica|vulnerabilità di sicurezza]] del codice
▲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
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 ===▼
▲== Storia ==
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:▼
▲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>
▲== 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}}</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}}</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>
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 ==
Riga 34:
La seguente linea di codice illustra questo tipo di vulnerabilità:
<
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>).
<pre>' OR '1'='1' --
' OR '1'='1' ({
Riga 46:
Ecco come appare il rendering dello statement SQL dopo l'inserimento di una delle linee di codice con commento e senza:
<
<
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'; <
L'inserimento dell'input specificato sopra fa diventare lo statement SQL in questo modo:
<
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.
Riga 62:
=== 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:= "<
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
Riga 70:
Viene fatto il drop (eliminazione) della tabella "users" dal database, visto che lo statement SQL diventa:
<
=== Blind SQL injection ===
Riga 80:
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
<
Con la quale popolerà la pagina con i dati della recensione con [[
<
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';</
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><
=== Second order SQL injection ===
Riga 90:
== 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
=== 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 ====
Riga 102:
=== 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:
<
$mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
Riga 108:
$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>.
Riga 118:
=== 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 <
deny select on sys.sysobjects to webdatabaselogon;
deny select on sys.objects to webdatabaselogon;
Riga 126:
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;
</syntaxhighlight>
=== Conversione esadecimale ===
Riga 134:
Esempio di utilizzo della funzione di PHP <kbd>''bin2hex()''</kbd>:
<
echo bin2hex("test");
</syntaxhighlight>
L'output della funzione sopra è:
Riga 145:
Esempio della funzione <kbd>''unhex()''</kbd> in MySQL:
<
SELECT * FROM myTable WHERE id=unhex('32');
</syntaxhighlight>
Se convertissimo la stringa con <kbd>''unhex()''</kbd> in semplice testo diventerebbe:
<
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.
Riga 162:
===== Codice d'esempio =====
<
File: test.php
<?php
Riga 237:
return $array;
}
</syntaxhighlight>
===== Output del programma =====
<
SQL INJECTION - Plain
RES[log_id] = 1
Riga 250:
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.
Riga 259:
===== Codice d'esempio =====
<
File: toHex.js
////////////////////////////////////////////////////////////////////////////////
Riga 277:
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.
Riga 286:
* 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
* 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
* 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
Riga 303:
* 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 [[
* 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>
== 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.
*
* 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>
Riga 335:
== Collegamenti esterni ==
* {{Collegamenti esterni}}
<!-- * [http://www.techyfreaks.com/2012/05/manual-sql-injection-tutorial.html Manual Sql Injection Tutorial] By The Ajay Devgan --> <!-- COLLEGAMENTO NON PIù ESISTENTE -->
* [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://
* [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 |
* [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]]
| |||