¿Cómo han evolucionado las inyecciones de SQL? (Pregunta específica + Discusión abierta) [cerrado]

2
  

Publicación por primera vez en Security Stack, pero me he beneficiado mucho de   Publicaciones anteriores. Actualmente soy un estudiante graduado de seguridad cibernética   y estoy construyendo mi proyecto de tesis en este momento: es efectivamente   otro conjunto de aplicaciones web vulnerables (como DVWA o WebGoat) pero   Se centra en gran medida en la enseñanza del back-end de estos ataques y   proporcionando más ejemplos prácticos, junto con actualizaciones y   tipos de ataques más relevantes basados en cosas como los 10 principales de OWASP   para 2017.

     

Por el tiempo y mi tesis, solo voy a construir la sección   cubriendo los ataques de inyección (ya que parece que es uno de los más   tipos comunes y devastadores de ataques basados en la web). El resto vendrá   en mi propio tiempo De todos modos, aquí está mi pregunta:

Parece que estamos en un cambio respecto a cuán vulnerables somos en realidad. Ahora mismo estoy desarrollando mi aplicación en PHP y MySQL, y parece que el cambio a MySQLi realmente se ha solucionado mucho. de las inyecciones basadas en anexos de SQL. Lo que significa que las inyecciones como:

mysqli_query("SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'; DROP TABLE members; --'");

realmente no funciona, ya que la actualización de mysqli_query () solo permite que se pase una declaración SQL única en cualquier momento, y si se intentan más, la función devuelve false. Los desarrolladores específicamente tendrían que usar el tipo mysqli_multi_query () para que eso suceda, y eso no parece probable para los formularios de inicio de sesión simples.

Así que ahora mismo tengo una aplicación simple que mostrará una fila de la tabla según el usuario que proporcione un nombre de usuario y contraseña correctos:

<?php
    // Prevent errors from showing
    error_reporting(0);
    // Connect the db
    require '../../connect_db.php';

    if (isset($_POST['UserName'], $_POST['UserPass'] ) ) {

        // Grab user Input
        $UserName = $_POST['UserName'];
        $UserPass = $_POST['UserPass'];

        // The passwords in this case are stored in the clear. This is an early example. 
        // BINARY is used to force matching case. 
        $query = "SELECT * FROM users WHERE UserName='".$UserName."' AND BINARY UserPass='".$UserPass."'";

        $result = mysqli_query($db, $query)
         or die("Error: " . mysqli_error($db));


        // Echo out the table row(s)
        while($row = mysqli_fetch_array($result)) {
            echo '<tr class="query-result">'; // Class is added so that jQuery can remove old ones
            echo '<td>' . $row['UserId'] . '</td>';
            echo '<td>' . $row['UserName'] . '</td>';
            echo '<td>' . $row['UserPass'] . '</td>';
            echo '<td>' . $row['UserRole'] . '</td>';
            echo '</tr>';
        }
    }

Sé que, como está escrito, este ataque es vulnerable a la inyección '' OR '=', pero para el código anterior, ¿qué otros tipos de ataques de inyección podrían ocurrir? Realmente parece que la mayoría de los ataques de inyección conocidos confiaban realmente en la capacidad de UNION o de alguna manera para apilar comandos de SQL, suponiendo que los desarrolladores estén usando la sintaxis de MySQLi actualizada, ¿para qué otros tipos de ataques de inyección vale la pena prepararse? ¿Y no podemos efectivamente preocuparnos por los ataques de inyección 'basados en apilamiento'?

Me encantaría cualquier y todos los recursos que me puedan brindar, ya que espero poder compartir esto con la comunidad de mayor seguridad.

    
pregunta Tobin Shields 26.08.2017 - 21:00
fuente

1 respuesta

0

Su pregunta es bastante amplia, pero creo que puede reducirse a:

  

¿Se han cambiado las inyecciones de SQL con el cambio de PHP de mysql a mysqli (debido a la falta de soporte de consultas apiladas)

La respuesta: No, no lo han hecho. mysql tampoco admite consultas apiladas .

Con respecto a las limitaciones de no tener consultas apiladas: aparte de las inyecciones basadas en UNION, usted todavía tiene inyecciones ciegas y basadas en errores con subconsultas, que no necesariamente requieren UNION (ver por ejemplo aquí ; existen otros desvíos en caso de que UNION se filtre realmente, pero esa es otra pregunta). Está atascado con el tipo de consulta en la que se encuentra (SELECCIONAR, ACTUALIZAR, BORRAR, etc.), pero aparte de eso, tiene muchas posibilidades (pero, una vez más, parece otra pregunta).

    
respondido por el tim 26.08.2017 - 21:16
fuente

Lea otras preguntas en las etiquetas