Utente:Ilafmi/Sandbox

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca
Questa è la sandbox dell'utente Ilafmi.

Una sandbox è una sottopagina della pagina utente. Serve all'utente stesso come spazio di sviluppo e non è una pagina enciclopedica.

Se sei interessato a contribuire allo sviluppo di questa voce, manda un messaggio a Ilafmi. Saranno comunque ben accette piccole modifiche e correzioni, ma non cambiare eccessivamente la voce, potresti intralciare il suo lavoro.

  • Se vuoi fare delle prove di modifica a una pagina, usa la pagina delle prove comune di Wikipedia.
  • Per creare una tua sandbox personale, clicca qui

Ricorda che non è permesso inserire materiale vandalico o in violazione di copyright neanche nelle pagine non enciclopediche.

Il template:Tradotto da è stato erroneamente inserito nella voce. Spostarlo nella pagina di discussione.

Classificazione dei vettori di attacchi SQL injection nel 2010
Classificazione dei vettori di attacchi SQL injection nel 2010

SQL injection è una tecnica di code injection, usata per attaccare applicazioni data-driven, con la quale vengono inseriti degli statement SQL malevoli all’interno di campi di input in modo che vengano eseguiti (es. per fare inviare il contenuto del database all’attaccante).[1] L’SQL injection sfrutta le vulnerabilità di sicurezza del software di un’applicazione, ad esempio, quando l’input dell’utente non è correttamente filtrato da 'escape characters' contenuti negli statement SQL oppure non è fortemente tipizzato e viene eseguito inaspettatamente. L’SQL injection è più conosciuto come attacco per i siti web, ma è anche usato per attaccare qualsiasi tipo di database SQL.

L’SQL injection permette agli attaccanti di effettuare 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.

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.[2]

Storia[modifica | modifica wikitesto]

Le prime discussioni pubbliche relative all'SQL injection sono apparse attorno al 1998.[3] Per esempio, un articolo del 1998 su Phrack Magazine.[4]

Tipi di SQL injection[modifica | modifica wikitesto]

L’SQL injection (SQLI) è considerata da Open Web Application Security Project una delle 10 maggiori vulnerabilità delle applicazioni web nel 2007 e nel 2010.[5] Nel 2013 SQLI è stato considerato il numero uno degli attacchi sulla OWASP top 10.[6] Ci sono quattro principali sotto classi di SQL injection:

Lo Storm Worm è un esempio di utilizzo delle Compounded SQLI.[11]

Questa classificazione lo stato dell’SQLI rappresenta la sua evoluzione fino al 2010.[12]

Implementazioni tecniche[modifica | modifica wikitesto]

Caratteri di escape non filtrati correttamente[modifica | modifica wikitesto]

Questo tipo di SQL injection si verifica quando non viene filtrato l’input dell’utente dai 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à:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

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: 

' OR '1'='1

Oppure usando dei commenti per non fare eseguire il resto della (ci sono tre tipi di commenti SQL [13]). Tutti e tre le linee hanno uno spazio alla fine: 

' OR '1'='1' --
' OR '1'='1' ({
' OR '1'='1' /*

Ecco come appare il rendering dello statement SQL dopo l’inserimento di una delle linee di codice con commento e senza: 

SELECT * FROM users WHERE name = '' OR '1'='1';

SELECT * FROM users WHERE name = '' OR '1'='1' -- ';

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'; DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

L’inserimento dell’input specificato sopra fa diventare lo statement SQL in questo modo: 

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

Mentre molte delle implementazioni dei server SQL permettono di eseguire statement multipli con un’unica chiamata, alcune di queste API come nella funzione mysql_query() 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[modifica | modifica wikitesto]

Questo tipo di SQL injection si verifica quando un campo fornito dall'utente non è 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 := "SELECT * FROM userinfo WHERE id =" + a_variable + ";"

Da questo statement è evidente che l’autore voleva che la variabile fosse un numero riferito al campo "id". Tutta via se essa è di fatto una stringa, allora l’utente finale potrebbe manipolare lo statement a suo piacimento, e quindi aggirare la necessità di caratteri di escape. Per esempio, impostando una variabile a 

1;DROP TABLE users

Viene fatto il drop (eliminazione) della tabella "users" dal database, visto che lo statement SQL diventa: 

SELECT * FROM userinfo WHERE id=1; DROP TABLE users;

Blind SQL injection[modifica | modifica wikitesto]

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 è state individuate dov'è la vulnerabilità e qual è l’informazione obiettivo.[14]

Risposte condizionali[modifica | modifica wikitesto]

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 http://books.example.com/showReview.php?ID=5 farà eseguire al server la query 

SELECT * FROM bookreviews WHERE ID = 'Value(ID)';

Con la quale popolerà la pagina con i dati della recensione con ID 5, memorizzati nella tabella bookreviwes. 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 http://books.example.com/showReview.php?ID=5 OR 1=1 e http://books.example.com/showReview.php?ID=5 AND 1=2, che potrebbero generare rispettivamente l’esecuzione di queste query: 

SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
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: http://books.example.com/showReview.php?ID=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4, 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.[15][16]

Second order SQL injection[modifica | modifica wikitesto]

Il Second order SQL injection si verifica quando i valori inviati dalllutente 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[modifica | modifica wikitesto]

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 su Talktalk, la BBC ha riportato come gli esperti di sicurezza fossero stupiti che una così grande compagnia fosse vulnerabile a questo tipo di attacco.[17]

Statement parametrizzati[modifica | modifica wikitesto]

Lo stesso argomento in dettaglio: Prepared statement.

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.[18]

Rafforzamento a livello di codice[modifica | modifica wikitesto]

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[modifica | modifica wikitesto]

Un modo diretto, anche se soggetto ad errori per prevenire attacchi di SQLI è quello di evitare caratteri che hanno un 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 (') 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 mysqli_real_escape_string(); prima di inviare a query SQL: 

$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);

Questa funzione antepone dei backslash ai seguenti caratteri: \x00, \n, \r, \, ', " e \x1a. Essa è di solito usata per rendere sicure le query prima di inviare ad un database MySQL.[19]
In PHP vi sono tante altre funzioni per vari tipi di database come pg_escape_string() per PostgreSQL. La funzione addslashes(string $str) 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 caratter NULL.[20]
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.[21]

Controllo dei pattern[modifica | modifica wikitesto]

Si possono controllare parametri con stringhe di interi, float or 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[modifica | modifica wikitesto]

Limitare i permessi nel logon 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;
deny select on sys.tables to webdatabaselogon;
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;

Conversione esadecimale[modifica | modifica wikitesto]

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 bin2hex()[22] o dechex[23]. La funzione bin2hex() è da preferire visto che converte qualsiasi carattere e non solo numeri. In questa sezione verrà usata solo la funzione bin2hex().

Esempio di utilizzo della funzione di PHP bin2hex(): 

echo bin2hex("test");

L’output della funzione sopra è: 

74657374

A scopo d’esempio parliamo soltanto del database MySQL[24]. In MySQL, la funzione unhex()[25] è usata per riconvertire una stringa esadecimale in semplice testo.

Esempio della funzione unhex() in MySQL: 

SELECT * FROM myTable WHERE id=unhex('32');

Se convertissimo la stringa con unhex() in semplice testo diventerebbe: 

SELECT * FROM myTable WHERE id=2;

La conversione esadecimale elimina gli attacchi di SQL injection perché la stringa esadecimale inviata alla funzione unhex() viene ritornata come stringa già utilizzata e non viene interpretata.

Esempio di programmazione[modifica | modifica wikitesto]

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 tutte 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[modifica | modifica wikitesto]
File: test.php
<?php

    include_once "dosql.php";
#
#   Metti le informazioni sul tuo database qui.  Stò 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;
}
Output del programma[modifica | modifica wikitesto]
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

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 [26] 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[modifica | modifica wikitesto]

In aggiunta, l’utilizzo di BIN2HEX and UNHEX richiede meno tempo d’esecuzione rispetto agli altri metodi presentati. Questo accade principalmente per l nature semplicistica di entrambe le funzioni. Come mostrato nello snippet Javascript, convertire in esadecimale è piuttosto semplice e diretto:

Codice d’esempio[modifica | modifica wikitesto]
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;
}

Come mostrato, a differenza di mysqli_real_escape_string()[27] con il quale deve essere fatto il test di escape per ogni differente, bin2hex() converte semplicemente tutti i caratteri nel loro corrispettivo esadecimale. E la funzione unhex()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 mysqli_real_escape_string(), se in futuro dovesse essere scoperto un nuovo metodo, la funzione bin2hex() disabiliterà automaticamente la combinazione di caratteri, perché ritorna una stringa esadecimale. Un esempio di questo è il carattere Control-D ASCII.[28] Control-D può provocare una condizione "Fine della trasmissione"[29] in alcuni linguaggi. Se viene usata la funzione bin2hex() il Control-D diventa semplicemente il semplice testo ASCII “04” che non può causare problemi.

Articoli[modifica | modifica wikitesto]

Ci sono diversi articoli su internet che parlano della Conversione esadecimale e come fermare gli attacchi di SQLI. Alcuni di questi sono:

  1. E’ sufficiente la conversione esadecimale per rendere sane le query SQL? [30]
  2. Utilizzo di bin2hex ed unhex come semplice metodo di prevenzione da sql injection [31]
  3. I migliori modi per prevenire l’SQL? [32]
  4. SQL Injections – La soluzione finale a[33]

Esempi[modifica | modifica wikitesto]

  • Nel Febbraio del 2002, Jeremiah Jacks scoprì che Guess.com era vulnerabile ad una attacco di SQL injection, permetteno a chiunque sia in grado di 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.[34]
  • L'1 Novembre 2005, un hacker minorenne ha usato un attacco di SQL injection per entrare nel sito di una rivista di sicurezza informatica Taiwanese della Tech Target Group e rubare informazioni sui clienti.[35]
  • 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.[36]
  • Il 29 Marzo 2006, un hacker scoprì una vulnerabilità all'SQL injection su un sito ufficiale per il turismo del governo indiano.[37]
  • Il 29 Giugno 2009, un criminale informatico deturpò il sito web di e Microsoft UK usando un attacco di SQLI.[38][39] 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[40]
  • Nel Gennaio 2008, il sito del Malesiano Kaspersky fu hackerato 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, hackerò il sito " UN-Maldives" usando l'SQL Injection.
  • Il 28 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's search engine per identificare dei siti web che usassero SQL server, che era vulnerabile ad un SQLI tool.[40][41]
  • Nel 2008, almeno da Aprile ad Agosto, una serie di ttacchi comincio a sfruttare le vulnerabilità ad SQLI di IIS web server e SQL Server database 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 solo richiesta.[42] 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 le 500,000.[43]
  • 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. E' riportato come "il maggiore caso di furto di identità nella storia americana".[44]
  • Nel Dicembre 2009, un attaccante riusci ad entrare un database di testo della RockYou che conteneva le password e gli username non criptati di circa 32 minilioni di utenti usando un attacco di SQLI.[45]
  • Nel Giugno del 2010, un ricercatore sulla sicurezza sud americano che va con lo pseudonimo "Ch Russo" ottenne informazioni sensibili sugi utenti di un popolare sito per il BitTorrent , cioè The Pirate Bay. Ottenne l'accesso al pannello di controllo da amministratore del sito, e sfrutto un vulnerabilità di ad SQLI che gli rese possibile ottenere informazioni sugli account degli utenti, inclusi indirizzi IP,MD5 password hashes e records di quali torrent ogni utente aveva caricato.[46]
  • Dal 24 al 26 Luglio 2010, degli attaccanti 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 catena di supermercati Izumiya Co, Maruetsu Inc, e Ryukyu Jusco Co. Il furto dei dati riguardò 12,191 clienti. Mentre il 14 Agosto 2010, sono stati riportati più di 300 casi di informazioni ulle 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.[47]
  • L' 8 Novembre 2010, il sito britannico Royal Navy fu compromesso da un hacker romeno chiamato TinKode che usò un attacco di SQL injection.[48][49]
  • 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.[50]
  • Il 27 Marzo 2011, mysql.com, il sito ufficiale di MySQL, fu compromesso da un hacke che unò un attacco di Blind SQL injection.[51]
  • L'11 Aprile 2011, la Barracuda Networks fu compromessa a causa di una vulnerabilità ad SQLi. Fuorono ottenuti Indirizzi email ed username degli impiegati.[52]
  • Durante un perido 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, 8,000 account casuali sui 9,000 attivi e 90,000 account vecchi o inattivi.[53][54][55]
  • L'1 Giugno del 2011, gli "hacktivisti" del gruppo LulzSec furono accusati di aver rubato dei coupons, download keys, e passwords che erano memorizzate nel database di testo sul sito della Sony, accedendo a alle informazioni personali di milioni di utenti.[56][57]
  • Nel Giugno del 2011, PBS fu hackerata, molto probabilmente tramite SQLi; il processo completo usato dagli hacker per eseguire l'attacco è descritto su questo blog Imperva .[58]
  • 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.[59]
  • 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 "union-based SQL injection technique".[60][61]
  • L'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, Stanford, Cornell, Johns Hopkins, e l'University of Zurich su pastebin.com. Gli hacker dissero che volevano "fare prendere coscienza dei cambiamenti nell'educazione di oggi", lamntandosi del cambiamento delle leggi sull'educazione in Europa, e l'incremento delle tasse scolastiche negli USA.[62]
  • Il 27 Giugno 2013, il gruppo hacker "RedHack" sfondò il sito dell'amministrazione di Istanbul.[63] 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.[64]
  • 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.[65]
  • In 2 Febbraio 2014, un gruppo di hacker chiamato @deletesec fece trapelare 40,000 account dal sito di AVS TV.[66]
  • Il 21 Febbraio 2014, il forum di Governance degli Stati Uniti ebbe un attacco che portarono l'esposizione di 3,215 account.[67]
  • 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.[68]
  • Nel Ottobre del 2015, Si crede si stato usato un attacco di SQL injection ai danni dei server di una compagnia di telecomunicazioni inglese, la Talk Talk, rubando i dati personali di milioni di consumatori.[69]

Nella cultura popolare[modifica | modifica wikitesto]

  • Il login non autorizzato su un sito web tramite SQL injection fornisce le basi una sotto trama nel romanzo The Casual Vacancy della J.K. Rowling, pubblicato nel 2012.
  • Un cartone di xkcd cartoon riguarda un personaggio di nome "Robert'); DROP TABLE students;--" che effettua una SQL injection. Come risultato di questo cartone, l'SQL injection viene chiamata qualche volta in modo informale 'Bobby Tables'.[70][71]
  • Nel 2014 un soggetto in Polonia ha legalmente rinominato la sua impresa in Dariusz Jakubowski x'; DROP TABLE users; SELECT '1 con lo scopo di ostacolare le operazioni degli spammer harvesting bots.[72]

Vedi anche[modifica | modifica wikitesto]

Riferimenti[modifica | modifica wikitesto]

  1. ^ Microsoft, SQL Injection, su technet.microsoft.com. URL consultato il 4 agosto 2013.
    «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.»
  2. ^ Imperva, Imperva Web Application Attack Report (PDF), su imperva.com, July 2012. URL consultato il 4 agosto 2013.
    «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.»
  3. ^ Sean Michael Kerner, 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., su esecurityplanet.com, November 25, 2013.
  4. ^ Jeff Forristal (signing as rain.forest.puppy), NT Web Technology Vulnerabilities, in Phrack Magazine, vol. 8, 54 (article 8), Dec 25, 1998.
  5. ^ Category:OWASP Top Ten Project, su owasp.org, OWASP. URL consultato il 3 giugno 2011.
  6. ^ Category:OWASP Top Ten Project, su owasp.org, OWASP. URL consultato il 13 agosto 2013.
  7. ^ WHID 2007-60: The blog of a Cambridge University security team hacked, su xiom.com, Xiom. URL consultato il 3 giugno 2011.
  8. ^ WHID 2009-1: Gaza conflict cyber war, su xiom.com, Xiom. URL consultato il 3 giugno 2011.
  9. ^ [1] Archiviato il 20090618125914 su www.xiom.com URL di servizio di archiviazione sconosciuto.
  10. ^ Third Wave of Web Attacks Not the Last, su darkreading.com, Dark Reading. URL consultato il 29 luglio 2012.
  11. ^ Dancho Danchev, Mind Streams of Information Security Knowledge: Social Engineering and Malware, su ddanchev.blogspot.com, 23 gennaio 2007. URL consultato il 3 giugno 2011.
  12. ^ Krassen Deltchev, New Web 2.0 Attacks, in B.Sc. Thesis, Ruhr-University Bochum. URL consultato il February 18, 2010.
  13. ^ IBM Informix Guide to SQL: Syntax. Overview of SQL Syntax > How to Enter SQL Comments, IBM.
  14. ^ Using SQLBrute to brute force data from a blind SQL injection point, su justinclarke.com, Justin Clarke. URL consultato il October 18, 2008 (archiviato dall'url originale il June 14, 2008).
  15. ^ macd3v, Blind SQL Injection tutorial, su forum.intern0t.org. URL consultato il 6 December 2012.
  16. ^ Andrey Rassokhin, TDSS botnet: full disclosure, su nobunkum.ru. URL consultato il 6 December 2012.
  17. ^ (EN) Questions for TalkTalk - BBC News, su bbc.com. URL consultato il 26 ottobre 2015.
  18. ^ SQL Injection Prevention Cheat Sheet, su owasp.org, Open Web Application Security Project. URL consultato il 3 March 2012.
  19. ^ mysqli->real_escape_string - PHP Manual, su in2.php.net, PHP.net.
  20. ^ Addslashes - PHP Manual, su pl2.php.net, PHP.net.
  21. ^ Transparent query layer for MySQL, su xarg.org, Robert Eisele, November 8, 2010.
  22. ^ http://php.net/manual/en/function.bin2hex.php
  23. ^ http://php.net/manual/en/function.dechex.php
  24. ^ https://www.mysql.com/
  25. ^ https://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_unhex
  26. ^ https://dev.mysql.com/doc/refman/5.0/en/type-conversion.html
  27. ^ http://php.net/manual/en/function.mysql-real-escape-string.php
  28. ^ http://www.ascii-code.com/
  29. ^ http://www.asciitable.com/
  30. ^ http://stackoverflow.com/questions/22567944/is-hexing-input-sufficient-to-sanitize-sql-queries
  31. ^ http://blog.uzitech.com/2014/06/use-bin2hex-and-unhex-as-simple-sql.html
  32. ^ http://demo.sabaidiscuss.com/questions/question/best-way-to-prevent-sql-injection
  33. ^ https://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=2576&lngWId=8
  34. ^ Guesswork Plagues Web Hole Reporting, su securityfocus.com, SecurityFocus, March 6, 2002.
  35. ^ WHID 2005-46: Teen uses SQL injection to break to a security magazine web site, su xiom.com, Web Application Security Consortium, November 1, 2005. URL consultato il December 1, 2009.
  36. ^ WHID 2006-3: Russian hackers broke into a RI GOV website, su xiom.com, Web Application Security Consortium, January 13, 2006. URL consultato il May 16, 2008.
  37. ^ WHID 2006-27: SQL Injection in incredibleindia.org, su xiom.com, Web Application Security Consortium, March 29, 2006. URL consultato il March 12, 2010.
  38. ^ Robert, Hacker Defaces Microsoft U.K. Web Page, su cgisecurity.net, June 29, 2007. URL consultato il May 16, 2008.
  39. ^ Keith Ward, Hacker Defaces Microsoft UK Web Page, su rcpmag.com, Redmond Channel Partner Online, June 29, 2007. URL consultato il May 16, 2008.
  40. ^ a b Sumner Lemon, IDG News Service, Mass SQL Injection Attack Targets Chinese Web Sites, su pcworld.com, PCWorld, May 19, 2008. URL consultato il May 27, 2008.
  41. ^ Michael Zino, ASCII Encoded/Binary String Automated SQL Injection Attack, su bloombit.com, May 1, 2008.
  42. ^ Giorgio Maone, Mass Attack FAQ, su hackademix.net, April 26, 2008.
  43. ^ Gregg Keizer, Huge Web hack attack infects 500,000 pages, su computerworld.com, April 25, 2008. URL consultato il October 16, 2015.
  44. ^ US man 'stole 130m card numbers', BBC, August 17, 2009. URL consultato il August 17, 2009.
  45. ^ Jolie O'Dell, RockYou Hacker - 30% of Sites Store Plain Text Passwords, in New York Times, December 16, 2009. URL consultato il May 23, 2010.
  46. ^ The pirate bay attack, July 7, 2010.
  47. ^ Did Little Bobby Tables migrate to Sweden?, su alicebobandmallory.com. URL consultato il 3 giugno 2011.
  48. ^ Royal Navy website attacked by Romanian hacker BBC News, 8-11-10, Accessed November 2010
  49. ^ Sam Kiley, Super Virus A Target For Cyber Terrorists, su news.sky.com, November 25, 2010. URL consultato il November 25, 2010.
  50. ^ We Are Anonymous: Inside the Hacker World of LulzSec (PDF), su par-anoia.net, Little, Brown and Company.
  51. ^ MySQL.com compromised, su blog.sucuri.net, sucuri.
  52. ^ Hacker breaks into Barracuda Networks database, su networkworld.com.
  53. ^ site user password intrusion info, su dslreports.com. URL consultato il 3 giugno 2011.
  54. ^ DSLReports says member information stolen, Cnet News, 28 aprile 2011. URL consultato il 29 aprile 2011.
  55. ^ DSLReports.com breach exposed more than 100,000 accounts, The Tech Herald, 29 aprile 2011. URL consultato il 29 aprile 2011.
  56. ^ LulzSec hacks Sony Pictures, reveals 1m passwords unguarded, June 2, 2011.
  57. ^ Ridge Shan, LulzSec Hacker Arrested, Group Leaks Sony Database, June 6, 2011.
  58. ^ Imperva.com: PBS Hacked - How Hackers Probably Did It. URL consultato il 1º luglio 2011.
  59. ^ Wurm Online is Restructuring, su wurmonline.tumblr.com, May 11, 2012.
  60. ^ Chenda Ngak. "Yahoo reportedly hacked: Is your account safe?", CBS News. July 12, 2012. Retrieved July 16, 2012.
  61. ^ http://www.zdnet.com/450000-user-passwords-leaked-in-yahoo-breach-7000000772/
  62. ^ Nicole Perlroth, Hackers Breach 53 Universities and Dump Thousands of Personal Records Online, 3 October 2012.
  63. ^ RedHack Breaches Istanbul Administration Site, Hackers Claim to Have Erased Debts.
  64. ^ Redhack tweet about their achievement.
  65. ^ http://news.softpedia.com/news/Hackers-Leak-Data-Allegedly-Stolen-from-Chinese-Chamber-of-Commerce-Website-396936.shtml
  66. ^ http://www.maurihackers.info/2014/02/40000-avs-tv-accounts-leaked.html
  67. ^ http://www.batblue.com/united-nations-internet-governance-forum-breached/
  68. ^ http://news.softpedia.com/news/Details-of-70-000-Users-Leaked-by-Hackers-From-Systems-of-SPIROL-International-428669.shtml
  69. ^ Mobile News article
  70. ^ Randall Munroe, XKCD: Exploits Of A Mom, su xkcd.com. URL consultato il 26 February 2013.
  71. ^ Bobby Tables: A guide to preventing SQL injection, su bobby-tables.com. URL consultato il 6 October 2013.
  72. ^ (PL) Jego firma ma w nazwie SQL injection. Nie zazdrościmy tym, którzy będą go fakturowali ;), su niebezpiecznik.pl, 11 September 2014. URL consultato il 26 September 2014.

External links[modifica | modifica wikitesto]

Estratto da "https://it.wikipedia.org/w/index.php?title=Utente:Ilafmi/Sandbox&oldid=132675827"