SQL Injection con passaggio MD5

Question

SQL Injection con passaggio MD5

#1 da (15 voti)
#2 da (10 voti)
#3 da (4 voti)
#4 da (3 voti)

1

Voglio sapere, se nel mio modulo di accesso è possibile un'iniezione SQL. Se esiste, quale potrebbe essere la voce del modulo Web di exploit? Invio nome utente e password in formato html (POST). Il codice della funzione di accesso è:


$username = $_POST['user'];
$password = $_POST['pwd'];
$password = md5(password);

$sql = "SELECT id_user, name FROM 'TAB_USER' WHERE user = '$username' AND passwd = '$password' AND enable='Y'";

$result = mysql_query($sql,$dbCon);
$check = mysql_num_rows($result);
mysql_free_result($result);

if ($check ==  '1') {
  $result = mysql_query($sql,$dbCon);
  $array = mysql_fetch_array($result);

  $id = $array['id_user'];
  $name = $array['name'];

  $_SESSION['SES_id_user']= $id;
  $_SESSION['SES_name']= $name;

  return $id;
}
else return false;

php sql-injection authentication mysql injection

posta stefano 13.09.2013 - 16:59

fonte

4 risposte

Leggi altre domande sui tag php sql-injection authentication mysql injection

Crittografia dei dati di testo sostituendo i caratteri? Qualcuno può inviare un testo a un telefono e farlo apparire sul messaggio di testo del telefono di un'altra persona?

score 15 · Answer 1

Risposta breve: È dannatamente vulnerabile.

Perché? stai concatenando i valori dati dal POST che provengono direttamente da ciò che l'utente ha digitato. Pertanto, è molto semplice manipolare la query. Inoltre, stai utilizzando l'estensione mysql che è deprecata. Si dovrebbe usare mysqli o PDO per creare istruzioni preparate per la protezione contro l'iniezione.

Ecco una domanda di Stackoverflow che spiega la questione in profondità e come risolverlo.

In una nota a margine, dovresti non utilizzare MD5 per crittografare le password in quanto è un algoritmo danneggiato. Prendi in considerazione l'uso di bcrypt o PBKDF2 come spiegato qui .

score 10 · Answer 2

Scrivi questo:

$sql = "SELECT id_user, name FROM 'TAB_USER' WHERE user = '$username'
                                                           ^^^^^^^^^
                                                    SQL injection is here

Il malvagio invierà come "username" qualcosa che, dopo la sostituzione, renderà il tuo comando SQL simile a questo:

SELECT id_user, name FROM 'TAB_USER' WHERE user = 'Admin'; -- (some stuff here)

vale a dire. l'autore dell'attacco imposterà il "nome utente" alla stringa: Admin'; --

Vedi il carattere di citazione nifty? Questa è la leva per l'attacco. Poiché il codice sostituisce brutalmente $username nel comando SQL, con "qualunque sia il client fornito", il client può fornire un carattere di virgoletta di chiusura, che termina la costante di stringa, quindi un punto e virgola, che termina il comando, quindi un -- che dice al database "tutto il resto sulla linea è un commento, basta ignorarlo". E ignoralo come fa il database!

Ciò consente al malintenzionato di accedere come amministratore indipendentemente dalla password che ha usato. Questa è Iniezione SQL da manuale . Si prega di prendere nota: si potrebbe essere tentati di concludere che i problemi derivano dal carattere "citazione", e semplicemente il filtraggio sarebbe sufficiente per evitare l'attacco. Non è così. Ci sono molti (molti) modi per abusare di un brutale sostituto come quello che fai, ed è molto difficile catturarli tutti; come Pokemon, ogni nuova versione del software di database SQL introduce nuove specie. Le persone hanno cercato di pensare all'iniezione SQL come a un problema di "escape problematiche"; quindi hanno progettato questa funzione . Quindi hanno riprovati . E ancora ha fallito. Solo la tristezza ti aspetta su questa strada; non camminarlo Non aspettare un mysql_really_escape_string_this_time_i_said_please() . Invece, utilizza istruzioni preparate .

score 4 · Answer 3

Solo l'input dell'utente è vulnerabile e pwd è sicuro.

Esempi del modello di iniezione SQL della query (che devono essere utilizzati per l'input dell'utente).

'or'1'='1 and enable='Y'--
user'or 1=1--
'or 1=1--

Un utente malintenzionato non può iniettare il parametro pwd perché è maledito MD5 e il modello di output MD5 esadecimale è ([a-fA-F \ d] {32}) e non è controllabile per l'iniezione di query.

Inoltre, se tutti i cookie funzionano con SES_id_user e SES_name per verificare l'accesso degli utenti, il tuo meccanismo non è sicuro!

-------

Aggiornamento:

Gli hacker non possono eseguire query impilate come DROP ed ETC, perché PHP metodo mysql_query non supporta più (impilato) query .

score 3 · Answer 4

Ciò sarebbe vulnerabile anche agli attacchi automatici di base. Un input come "'; Drop Table' TAB_USER '; SELECT id_user, nome FROM' TAB_USER 'WHERE user =' someuser" (esclusivo della "s) farebbe eseguire tre comandi dal tuo script. La prima sarebbe una selezione valida il secondo farebbe cadere completamente il tuo tavolo e il terzo eseguirà un'altra selezione. (ok, la terza query fallirebbe dal momento che la tabella non è più disponibile, ma dà l'idea generale).

È necessario convalidare qualsiasi input utente prima che vada a una query e / o utilizzare SQL parametrizzato. Ad esempio, per un nome utente, dovrebbe essere effettivamente alfanumerico senza punteggiatura, che lo renderebbe sicuro contro l'iniezione. L'SQL parametrizzato è una buona linea secondaria di difesa poiché l'istruzione SQL comprende che è un valore utente e non deve contenere comandi.

Come altri hanno già menzionato, il meccanismo di memorizzazione della password è anche tristemente insicuro perché non viene sottoposto a hash ed è un algoritmo veloce, quindi esistono tabelle arcobaleno di grandi dimensioni che potrebbero essere utilizzate per cercare un valore di testo normale che produrrà qualsiasi dato hash è nel DB. Questi si combinano per rendere banale non solo l'abuso del database, ma anche l'accesso a un altro utente senza dover modificare il DB (selezionando l'HASH nella sessione e poi scaricandolo in un secondo momento e quindi cercando la password in un tabella arcobaleno esistente per MD5.