¿Es posible realizar una inyección SQL (nivel ALTO) en la aplicación web Damn Vulnerable?

17

Busqué en todo Google para ver cómo sería posible evitar lo siguiente (es del alto nivel de seguridad 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++;
    }
  }
 }
?>

¿Es posible descifrar eso?

También, mi otra preocupación es en el nivel medio. Tiene el mysql_real_escape_string () funcionando, pero cuando usa la misma inyección SQL del nivel bajo Y elimina las comillas, omite la protección. ¿Porqué es eso? ¿Por qué fue tan fácil eludir la cadena mysql_real_escape?

El código (versión concisa) del nivel Medio es el siguiente:

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

4 respuestas

16

El ejemplo 'alto' no es explotable. No es un enfoque bueno (en el código moderno usarías la parametrización en lugar de llamar a mysql_real_escape_string , y stripslashes es una reliquia de una era de citas mágicas que afortunadamente ha terminado), pero está diseñado No ser inmediatamente vulnerable.

(De todos modos, a la inyección de SQL. es vulnerable a la inyección de HTML que conduce a problemas de XSS, gracias a esos horribles echo s, pero esa es otra historia.)

  

¿Por qué fue tan fácil eludir la cadena mysql_real_escape? [en el ejemplo medio]

Porque mysql_real_escape_string está diseñado para escapar de los caracteres por seguridad cuando se incluye en un contexto literal de cadena SQL. Sin comillas simples alrededor del punto de inyección de la consulta, no está en un contexto literal de cadena, está en un contexto SQL sin formato.

    
respondido por el bobince 03.10.2013 - 22:35
fuente
11

La inyección SQL no es imposible en esta situación. Este código impide que SQLi funcione correctamente e incluso si la plataforma es antigua o está mal configurada, debería ser inmune a SQLi.

... En una configuración ligeramente diferente, puede ser vulnerable.

Si se eliminó is_numeric() , mysql_real_escape_string() se reemplazó con addslashes() , y el servidor se configuró para usar el conjunto de idiomas GBK, entonces está posibilidad de un ataque de múltiples bytes utilizando la codificación de idioma GBK .

    
respondido por el rook 03.10.2013 - 19:59
fuente
9

Aquí hay algo interesante: El alto nivel en DVWA no pretende ser explotable . Es la implementación "correcta" y segura de los conceptos como el autor de la DVWA consideró adecuado en ese momento. Por lo tanto, es muy natural que no pueda realizar la inyección SQL en un nivel alto. Si realmente lo haces, estarías descubriendo algo nuevo. Un día cero, tal vez.

He estado jugando con DVWA durante años y tuve que aprender esto de la manera más difícil.

    
respondido por el Adi 03.10.2013 - 20:26
fuente
-2

El código actual en dvwa para inyección de SQL de alto nivel es vulnerable con el mismo enfoque.

si simplemente omite el comando Limit de la consulta de SQL, puede hacerlo haciendo ex: a' or 1=1;# .

# mencionado aquí restringirá el comando Limit mencionado en la última consulta y el bingo obtiene todos los usuarios y contraseñas.

    
respondido por el Shanky 27.12.2015 - 19:49
fuente

Lea otras preguntas en las etiquetas