web-dev-qa-db-fra.com

Est-il possible de faire l'injection SQL (HIGH Level) sur Damn Vulnerable Web App?

J'ai cherché partout sur Google pour voir comment il serait possible de contourner ce qui suit (c'est du haut niveau de sécurité de 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++;
    }
  }
 }
?>

Est-il possible de casser cela?

De plus, mon autre préoccupation concerne le niveau moyen. La fonction mysql_real_escape_string () fonctionne, mais lorsque vous utilisez la même injection SQL de bas niveau ET que vous supprimez les guillemets, cela contourne la protection. Pourquoi donc? Comment se fait-il qu'il ait été si facile de contourner la chaîne mysql_real_escape?

Le code (version concise) du niveau moyen est le suivant:

   $id = $_GET['id']; 
   $id = mysql_real_escape_string($id); 
   $getid = "SELECT first_name, last_name FROM users WHERE user_id = $id";
sql-injectionmysqldvwa
17
Guillaume Néry

L'exemple "élevé" n'est pas exploitable. Ce n'est pas une approche bonne (dans le code moderne, vous utiliseriez le paramétrage au lieu d'appeler mysql_real_escape_string, et stripslashes est une relique d'une époque de citations magiques qui est heureusement révolue), mais elle est conçue pour ne pas être immédiatement vulnérable.

(Pour l'injection SQL de toute façon. Il est vulnérable à l'injection HTML conduisant à des problèmes XSS, grâce à ces horribles echos, mais c'est une autre histoire.)

Comment se fait-il qu'il ait été si facile de contourner la chaîne mysql_real_escape? [dans l'exemple Medium]

Parce que mysql_real_escape_string est conçu pour échapper les caractères par sécurité lorsqu'ils sont inclus dans un contexte littéral de chaîne SQL. Sans guillemets simples environnants dans le point d'injection de la requête, vous n'êtes pas dans un contexte littéral de chaîne, vous êtes dans un contexte SQL brut.

16
bobince

L'injection SQL n'est pas impossible dans cette situation. Ce code empêche SQLi correctement et même si la plate-forme est ancienne ou mal configurée, elle devrait toujours être à l'abri de SQLi.

... Dans une configuration légèrement différente, il est peut-être vulnérable.

Si is_numeric() a été supprimée, mysql_real_escape_string() a été remplacée par addslashes() et que le serveur a été configuré pour utiliser le jeu de langues GBK, il existe alors la possibilité d'une attaque multi-octets utilisant le codage du langage GBK .

11
rook

Voici quelque chose d'intéressant: Le haut niveau dans DVWA n'est pas censé être exploitable. Il s'agit de la mise en œuvre "correcte" et sûre des concepts comme l'auteur de la DVWA l'a jugé bon à l'époque. Il est donc très naturel que vous ne puissiez pas effectuer d'injection SQL à un niveau élevé. Si vous le faites réellement, vous découvrirez quelque chose de nouveau. Un jour zéro, peut-être.

Je joue avec DVWA depuis des années et j'ai dû l'apprendre à la dure.

9
Adi

Avant DVWA 1.9, DVWA utilisait "élevé" comme niveau de sécurité le plus élevé alors qu'actuellement, ils utilisent un niveau de sécurité "impossible". Ainsi, en "haut", il est possible de faire n'importe quelle autre injection SQL, par exemple une entrée comme: "union select user, password from users; -. Notez que vous devriez avoir de l'espace après - sinon la commande serait syntaxiquement incorrecte.

0
Fatima