E 'possibile fare un'iniezione SQL (HIGH Level) su Damn Vulnerable Web App?

17

Ho cercato su google per vedere come sarebbe possibile ignorare quanto segue (è l'alto livello di sicurezza di DVWA ):

<?php    

if (isset($_GET['Submit'])) {

// Retrieve data

$id = $_GET['id'];
$id = stripslashes($id);
$id = mysql_real_escape_string($id);

if (is_numeric($id)){

    $getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";
    $result = mysql_query($getid) or die('<pre>' . mysql_error() . '</pre>' );

    $num = mysql_numrows($result);

    $i=0;

    while ($i < $num) {

        $first = mysql_result($result,$i,"first_name");
        $last = mysql_result($result,$i,"last_name");

        echo '<pre>';
        echo 'ID: ' . $id . '<br>First name: ' . $first . '<br>Surname: ' . $last;
        echo '</pre>';

        $i++;
    }
  }
 }
?>

È possibile decifrarlo?

Inoltre, la mia altra preoccupazione è a livello medio. Ha il funzionamento di mysql_real_escape_string (), ma quando si utilizza la stessa iniezione SQL da Basso livello E si rimuovono le virgolette, si ignora la protezione. Perché? Com'è che è stato così facile bypassare la stringa mysql_real_escape?

Il codice (versione concisa) del livello medio è questo:

   $id = $_GET['id']; 
   $id = mysql_real_escape_string($id); 
   $getid = "SELECT first_name, last_name FROM users WHERE user_id = $id";
    
posta Guillaume Néry 03.10.2013 - 19:35
fonte

4 risposte

16

L'esempio "alto" non è sfruttabile. Non è un approccio buono (nel codice moderno dovresti usare la parametrizzazione invece di chiamare mysql_real_escape_string , e stripslashes è una reliquia di un'era di citazioni magiche che è fortunatamente finita), ma è progettata non essere immediatamente vulnerabile.

(A SQL injection comunque. è vulnerabile a HTML-injection che porta a problemi XSS, grazie a quegli orribili echo s, ma questa è un'altra storia.)

How come it was so easy to bypass mysql_real_escape string? [in the Medium example]

Poiché mysql_real_escape_string è progettato per l'escape di caratteri per la sicurezza quando inclusi in un contesto letterale stringa SQL. Senza virgolette singole circostanti nel punto di iniezione della query, non ci si trova in un contesto letterale stringa, si è in un contesto SQL non elaborato.

    
risposta data 03.10.2013 - 22:35
fonte
11

SQL Injection è non possibile in questa situazione. Questo codice impedisce SQLi correttamente e anche se la piattaforma è vecchia o mal configurata, dovrebbe comunque essere immune a SQLi.

... In una configurazione leggermente diversa potrebbe essere vulnerabile.

Se is_numeric() è stato rimosso, mysql_real_escape_string() è stato sostituito con addslashes() , e il server è stato configurato per utilizzare il set di lingue GBK, quindi c'è possibilità di un attacco multi-byte utilizzando la codifica del linguaggio GBK .

    
risposta data 03.10.2013 - 19:59
fonte
9

Ecco qualcosa di interessante: L'alto livello in DVWA non è inteso per essere sfruttabile . È l'implementazione "corretta" e sicura dei concetti, come l'autore del DVWA riteneva opportuno al momento. Quindi, è molto naturale che non sia possibile eseguire SQL Injection ad alto livello. Se lo fai davvero, scoprirai qualcosa di nuovo. Un giorno zero, forse.

Ho giocato con DVWA per anni e ho dovuto imparare questo nel modo più duro.

    
risposta data 03.10.2013 - 20:26
fonte
-2

Il codice corrente su dvwa per l'injection sql di alto livello è vulnerabile con lo stesso approccio.

se ometti il comando Limit dalla query sql che puoi eseguire facendo ex: a' or 1=1;# .

# menzionato qui limiterà il comando Limit menzionato nell'ultima query e nel bingo riceverai tutti gli utenti e le password.

    
risposta data 27.12.2015 - 19:49
fonte

Leggi altre domande sui tag