Home / Questions / 18232
Accepted
Alvaro Montoro
Asked: 2020-08-01 13:03:26 +0800 CST 2020-08-01 13:03:26 +0800 CST

Как избежать SQL-инъекций в PHP?

  • 772

Динамические операторы — это операторы SQL, которые создаются в виде строк и в которые вставляются/объединяются значения, полученные из какого-либо источника (обычно от пользователя), что может сделать их уязвимыми для SQL-инъекций, если они не продезинфицированы.

$id_usuario = $_POST["id"];

mysql_query("SELECT * FROM usuarios WHERE id = $id_usuario");

Это пример серьезной уязвимости в безопасности приложения (веб-сайта или нет), потому что, если пользователь введет такое значение 1; DROP TABLE usuarios;--, мы обнаружим, что выполненный оператор будет выглядеть так:

SELECT * FROM usuarios WHERE id = 1; DROP TABLE usuarios;--

И таблица Users со всеми содержащимися в ней данными будет удалена.

Как я могу предотвратить внедрение SQL в PHP?

php

6 Answers

  1. Best Answer

    НЕ ИСПОЛЬЗУЙТЕ ДИНАМИЧЕСКИЕ ЗАЯВЛЕНИЯ ИЛИ ФУНКЦИИmysql_*

    Функции mysql_*( mysql_connect, mysql_query, и т.д.) небезопасны по своей природе, и их использование не только не рекомендуется, но и считается устаревшим и полностью удалено с версии PHP7 .

    Даже собственные методы, которые существуют в PHP для очистки пользовательского ввода (например, mysql_real_escape_string), могут создавать (редкие) проблемы и давать сбои в некоторых случаях, например, когда кодировки символов, отличные от UTF-8, используются вместе с устаревшими версиями MySQL ( в которых страницы PHP для этих функций предупреждают об этом риске).

    Используйте подготовленные операторы и параметризованные запросы

    Хотя входные данные можно очистить с помощью таких методов, как mysqli_real_escape_string, более целесообразно использовать подготовленные или параметризованные операторы. Подготовленные операторы позволят вам выполнить один и тот же оператор с большой эффективностью.

    В PHP у вас есть две основные альтернативы: PDO и MySQLi . Между ними есть несколько различий, но главное из них заключается в том, что PDO можно использовать с разными типами баз данных ( в зависимости от используемого драйвера ), в то время как MySQLi предназначен исключительно для баз данных MySQL. Вот почему я бы рекомендовал PDO вместо MySQLi.

    ЗОП

    Заполнители ( указывающие, где строка будет заменена на ее значение) могут быть определены либо с помощью вопросительного знака ( ?), либо с помощью имени (обычно начинающегося с :). Я лично предпочитаю использовать имя, потому что это помогает мне найти возможные ошибки в случае наличия нескольких переменных.

    Вот пример кода вопроса:

    // la variable $pdo contendrá el objeto con la conexión PDO
$pdo = new PDO('mysql:host=mihost;dbname=basedatos', "usuario", "contraseña");

$id_usuario = $_POST["id"];

$sentencia = $pdo->prepare("SELECT * FROM usuarios WHERE id = :idusuario");
$sentencia=$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$sentencia->bindParam(":idusuario", $id_usuario, PDO::PARAM_INT);
$sentencia->execute();

    В этом случае :idusuarioона будет подставлена ​​на значение $_POST["id"]safe, а при выполнении привязки будет указано, что переменная имеет тип integer ( PDO::PARAM_INT).

    Примечание: если переменная представляет собой текстовую строку, она будет использоваться, PDO::PARAM_STRи кавычки в операторе SQL ставить необязательно; указав PHP, что это строка, он автоматически добавит их при выполнении bind .

    Если в оператор SQL нужно включить несколько переменных, для каждого значения, используемого в операторе, должен быть включен один параметр. Из приведенного выше примера :idusuarioможно использовать только один раз в подготавливаемом запросе. Если в запросе необходимо снова использовать «userid», необходимо создать еще один параметр со значением $id_usuario.

    $pdo = new PDO('mysql:host=mihost;dbname=basedatos', "usuario", "contraseña");

$id_usuario = $_POST["id"];
    
$sentencia = $pdo->prepare("UPDATE usuarios SET id = :idusuario WHERE id = :idusuario1");
$sentencia=$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$sentencia->bindParam(":idusuario", $id_usuario, PDO::PARAM_INT);
$sentencia->bindParam(":idusuario1", $id_usuario, PDO::PARAM_INT);
$sentencia->execute();

    MySQL я

    Этот метод имеет два интерфейса : процедурный и объектно-ориентированный. Процедурный интерфейс очень похож на mysql_*, и поэтому людей, переходящих с mysql_*него, может привлечь простота, которую он mysqli_*предлагает. Хотя, опять же, лично я бы выбрал ООП-версию.

    Примечание. Хотя функции mysqli_*часто похожи на mysql_*, в некоторых случаях они могут иметь разные входные параметры или разные выходные данные, что поначалу может привести к некоторой путанице.

    Пример в вопросе будет выглядеть так с MySQLi в его объектно-ориентированном интерфейсе:

    // en $mysqli tendremos la conexión MySQLi
$mysqli = new mysqli("mihost", "usuario", "contraseña", "basedatos");

$id_usuario = $_POST["id"];

$sentencia = $mysqli->prepare("SELECT * FROM usuarios WHERE id = ?");
$sentencia->bind_param("i", $id_usuario );
$sentencia->execute();

    Как видите, он очень похож на PDO (немного меняется способ указания типа значения для iцелых чисел и sдля строк, но идея аналогична).

    В процедурной версии MySQLi эквивалентный код будет таким:

    // en $conn tendríamos la conexión a la base de datos con MySQLi
$conn = mysqli_connect("mihost", "usuario", "contraseña", "basedatos");

$id_usuario = $_POST["id"];

$sentencia = mysqli_prepare("SELECT * FROM usuarios WHERE id = ?");
mysqli_stmt_bind_param($sentencia, "i", $id_usuario);
mysqli_stmt_execute($sentencia);

    Источник и библиография для получения дополнительной информации на испанском языке:

    • 212

  2. Внимание: принятый ответ, безусловно, хорош, но недостаточен . Это правда, что использование подготовленных запросов почти защищает нас от атак, известных как SQL-инъекция первой степени. Но если PDO настроен неправильно, подготовленные запросы могут быть уязвимы, как показано на примерах в ответе. В конце я разместил ссылки, которые послужили основой для разработки этого ответа, особенно Предотвращение SQL-инъекций в приложениях PHP - простое и исчерпывающее руководство и SQL-инъекция, против которой не помогут подготовленные операторы .

    Моей единственной заслугой был перевод, возможно, в некоторых моментах улучшенный. Мы знаем, что ничто не является безопасным на 100%, но простое использование PDO или MySQLi должно сочетаться с другими стратегиями, описанными в пункте 5 , чтобы обеспечить нечто столь же ценное, как наши данные.

    1. Введение

    Внедрение SQL — это метод управления запросом к базе данных, который часто приводит к нарушению конфиденциальности. В некоторых случаях это может привести к полному захвату сервера.
    Например:

    SELECT 'código diabólico aquí' INTO OUTFILE '/var/www/reverse_shell.php'

    Поскольку внедрение кода (охватывающее методы SQL, LDAP , Command OS и XPath Injection ) постоянно остается в топ -10 уязвимостей OWASP , это популярная тема для блоггеров, пытающихся разобраться в области безопасности приложений.

    К сожалению, большая часть советов, циркулирующих в Интернете (особенно в старых блогах, занимающих высокие позиции в поисковых системах) , устарела, непреднамеренно вводит в заблуждение и часто опасна .

    2. Очень распространенная ошибка: неправильно сконфигурированный PDO

    Если вы разработчик PHP и хотите получить максимальную отдачу от PDO, мы рекомендуем вам изменить два значения по умолчанию:

    1. Отключите эмулированные препараты . Это гарантирует, что вы получите готовые заявления.
    2. Установите режим ошибок, чтобы генерировать исключения . Это избавляет вас от необходимости следить за результатами PDOStatement::execute()и делает ваш код менее избыточным.

    Чтобы сделать оба:

    $pdo = new PDO(/* Fill in the blank */);
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

    Поскольку он PDO::ATTR_EMULATE_PREPARESопределен как false, мы получаем фактические подготовленные операторы. И поскольку мы определили PDO::ATTR_ERRMOREкак PDO::ERRMODE_EXCEPTION.

    Вместо этого:

    $stmt = $pdo->prepare("SELECT * FROM foo WHERE first_name = ? AND last_name = ?");
if ($stmt->execute([$_GET['first_name'], $_GET['last_name'])) {
    $users = $stmt->fetchAll(PDO::FETCH_ASSOC);
} else {
    // Handle error here.
}
$args = [
    json_encode($_GET)
    (new DateTime())->format('Y-m-d H:i:s')
];
$insert = $pdo->prepare("INSERT INTO foo_log (params, time) VALUES (?, ?);");
if (!$insert->execute($args)) {
    // Handle error here.
}

    Вы можете просто написать свой код следующим образом:

    try {
    $stmt = $pdo->prepare("SELECT * FROM foo WHERE first_name = ? AND last_name = ?");
    $stmt->execute([$_GET['first_name'], $_GET['last_name']);
    $users = $stmt->fetchAll(PDO::FETCH_ASSOC);
    $args = [
        json_encode($_GET),
        (new DateTime())->format('Y-m-d H:i:s')
    ];
    $pdo->prepare("INSERT INTO foo_log (params, time) VALUES (?, ?);")
        ->execute($args);
} catch (PDOException $ex) {
    // Handle error here.
}

    Повышенная безопасность, краткость и лучшая разборчивость. Что еще тебе надо?

    3. Еще одна ошибка: не до конца понимать, для чего нужен PDO

    Очень распространенной ошибкой является неполное понимание того, для чего существует PDO, и использование его в качестве простого помощника по обновлению.

    Mientras juegan con PDO, casi todos los usuarios de PHP terminan considerándolo como una especie de mejora para la consulta INSERT/UPDATE, que acepta una matriz asociativa y crea una consulta con marcadores dinámicos, que básicamente se parece a esto (un código real tomado de una pregunta sobre Stack Overflow):

     $params = []; 
 $setStr = "" ; 
 foreach ( $data as $key => $value ) 
 { 
    if( $key != "id" ) 
    { 
         $setStr .= $key . " = :" . $key . ","; 
    } 
     $params[':' . $key] = $value ; 
 
 } 
 $setStr = rtrim($setStr, ",");
 $pdo->prepare("UPDATE users SET $setStr  WHERE id = :id" )->execute($params);

    Se ve bastante bien, ya que puede producir rápidamente una consulta dentro de una matriz o arreglo en la que las claves representan nombres de columna y los valores representan los valores que se utilizarán en la consulta. Dado que los nombres de campos en formato HTML son los mismos que los nombres de columna de tabla, puede automatizar en gran medida el procesamiento de formularios, permitiéndole utilizar el mismo código para editar información en cualquier tabla. Muy conveniente. Pero catastróficamente vulnerable.

    "¿Cómo?" - usted diría probablemente - "los marcadores de posición se utilizan y los datos se enlazan con seguridad, por lo tanto nuestra consulta es segura". Sí, los datos son seguros. Pero, de hecho, lo que hace este código es tomar la entrada del usuario y agregarlo directamente a la consulta. Sí, es una variable $key que va a la derecha en su consulta sin ningún tratamiento.

    Usar PDO de forma ingenua y mal configurado es una puerta abierta a la inyección SQL.

    4. Ejemplos de inyección posibles con PDO mal configurado y desmontando algunos mitos sobre protección de la base de datos

    El punto 4 sólo aplica si tenemos un PDO mal configurado. Aunque es un poco extenso lo he querido traducir para que podamos apreciar el alcance de un error tan fácil de cometer. También desmonta algunos mitos como el saneamiento de nuestras cadenas, erróneamente recomendado en muchos sitios de internet.

    Aquí hay una pequeña prueba de código de concepto que, siempre y cuando tenga una tabla usuarios y una fila con id = 1, cambiará el nombre de usuario a un resultado de la consulta SELECT. Y esta consulta podría ser cualquier cosa:

     <form method = POST> 
 <input type = hidden name = "name=(SELECT'hacked!')WHERE`id`=1#" value = ""> 
 <input type = hidden name = "name" value = "Joe"> 
 <input type = hidden name = "id" value = "1"> 
 <input type = submit> 
 </form> 
 <? php 
 if( $_POST ) {
     $pdo = new PDO('mysql:dbname=test;host=localhost', 'root', '');
     $params = [];
     $setStr = "" ;
    foreach($_POST as $key => $value)
    { 
        if( $key != "id" )
        {
             $setStr .= $key . " = :" . $key . ","; 
        } 
        $params[$key] = $value;
    }

     $setStr = rtrim($setStr, ",");
     $pdo->prepare("UPDATE users SET $setStr WHERE id = :id")->execute($params);
 }

    Este código producirá una consulta como esta

    UPDATE users 
  SET name =
  ( SELECT 'hacked!' ) 
  WHERE ` id `= 1 # = :name=(SELECT'1')
  WHERE`id`=1#,name = :name WHERE id = :id

    Donde todo lo pasado después de # será tratado como un comentario.

    Puedes probarlo en casa.

    ¿Qué sucede en este código?
    Estamos forjando un formulario, añadiendo otro campo a él y escribiendo un código SQL en el atributo name. La función auxiliar mencionada tomará este SQL forjado y lo insertará en la consulta construida. Como resultado, en lugar de Joe el nombre se establecerá en hackeado!. ¿No asusta demasiado, eh? Pero usted tiene que entender que lo que es peligroso aquí es el hecho de la inyección. Mientras que sea posible, la cantidad de crear consultas mal intencionadas es infinita. Y no todas son tan inofensivas. A continuación veremos una vulnerabilidad más peligrosa.

    PDO::quote() - El movimiento equivocado

    Ok, necesitamos proteger nuestro código útil (así como cualquier otro código que no pueda ser protegido con declaraciones preparadas).

    Lo primero que un usuario promedio de PHP probablemente pensaría es una función incorporada de PDO::quote(), que aparentemente hace lo que necesitamos: proteger los datos de la inyección de SQL. Pero pronto estará claro que una función destinada al formato de cadena es inaplicable para los identificadores. Ésta agregará comillas simples alrededor del valor devuelto y hará que nuestro código produzca una secuencia como esta:

      'name' = 'joe'

    Lo que resultará en un error de sintaxis, ya que las comillas simples son ilegales como delimitadores de nombre de campo en MySQL.

    No pienses nunca en recortar comillas simples de la cadena resultante, ya que fue sugerido hace algún tiempo en un comentario bajo la entrada de PDO::quote() en el manual de PHP: el propósito de esta función es hacer un formateo completo haciendo escape de ambos caracteres y agregando comillas. Saca una de estas dos acciones y tendrás una inyección.

    En otras palabras, si tiramos las comillas simples circundantes del resultado de PDO::quote(), será como si solo aplicáramos la picadura regular escapando. Y veamos por qué está mal:

    Cadena de escape (mysql_real_escape_string) - un desastre

    Otra cosa que un usuario de PHP podría pensar es una función de escape familiar que "hace que sus datos sean seguros" como falsamente se declaró durante mucho tiempo en el manual de PHP. Desafortunadamente, solo ayudará si el código de inyección contiene comillas simples u otros caracteres con esta función. La mala noticia es que todos esos caracteres son innecesarios para la inyección, demostrando esta función inútil para el caso (y refutando las habilidades ficticias de protección de esta función):

     <form method = POST> 
 <input type = hidden name = "name=(SELECT password from admins)WHERE`id`=1#" value = ""> 
 <input type = hidden name = "name" value = "Joe"> 
 <input type = hidden name = "id" value = "1"> 
 <input type = submit> 
 </form> 
 <? php 
 if ( $_POST ) { 
     $pdo = new PDO('mysql:dbname=test;host=localhost', 'root', ''); 
     $params = []; 
     $setStr = ""; 
     foreach( $_POST as $key => $value ) 
     { 
        if( $key != "id" ) 
        { 
            $setStr .= addslashes($key). " = :" . $key . ","; 
        } 
        $params[$key] = $value; 
    } 
    $setStr = rtrim($setStr, ","); 
    $pdo->prepare("UPDATE users SET $setStr WHERE id = :id")->execute($params); 
    var_dump("UPDATE users SET $setStr WHERE id = :id", $_POST); 
 }  
 ?>

    Como se puede ver, no hay una sola cita en la consulta maliciosa y por lo tanto ni addslashes() ni varios *_escape_string() puede hacer nada aquí.

    Esta inyección es mucho más peligrosa ya que revelará la contraseña del administrador a cualquier persona.

    Adición de Operadores de ejecución o comillas invertidas `` (aún vulnerable)

    Ok, como ya hemos aprendido, las comillas simples no ayudarán. ¿Quizá los operadores de ejecución o comillas invertidas (``) ayudarían? Veamos si ayudan:

      <form method = POST> 
 <input type = hidden name = "name`=(SELECT'hacked!')WHERE`id`=1#" value = ""> 
 <input type = hidden name = "name" value = "Joe"> 
 <input type = hidden name = "id" value = "1"> 
 <input type = submit> 
 </form> 

 <? php 
 if ( $_POST ) { 
     $pdo = new PDO('mysql:dbname=test;host=localhost', 'root', ''); 
     $params = []; 
     $setStr = ""; 
     foreach( $_POST as $key => $value ) 
     { 
         if( $key != "id" ) 
         { 
             $setStr .= "` $key ` = : $key ,"; 
         } 
         $params[$key] = $value;
     } 
     $setStr = rtrim($setStr, ","); 
     $pdo->prepare("UPDATE users SET $setStr WHERE id = :id")->execute($params); 
 }
 ?>

    Como se puede ver, añadir comillas invertidas no nos ayudó en absoluto: un atacante sólo añade otra comilla para cerrar prematuramente el identificador y luego proceder con la consulta malintencionada. Sucede porque agregar cualquier delimitador alrededor de algún literal es inútil si no escapamos de estos delimitadores dentro - es la lección que aprendimos duramente de las inyecciones convencionales basadas en cadenas. ¡Así que escaparemos nuestras comillas invertidas!

    Escapando las comillas invertidas

    Entonces, ¿qué se puede hacer para conservar una función tan útil, pero sin una violación terrible?

    Como se dijo antes, escapar delimitadores ayudaría. Por lo tanto, su primer nivel de defensa debe ser escapar delimitadores (comillas invertidas) duplicándolos.

    Construyendo nuestra consulta de esta manera:

     $setStr .= "`" . str_replace("`", "``", $key). "` = :" . $key . ",";

    Usted conseguirá eliminar la inyección.

    Si tratamos de inyectar utilizando el método anterior resultará en un error de ejecución de la consulta, que, aunque es seguramente mejor que una inyección exitosa, todavía no es un comportamiento bastante deseable.

    Esta es la razón por la que citar/escapar nombres de campo aún no es suficiente. Y esta es la razón por la que usted debe utilizar otro nivel de defensa:

    Solución sólida en todo

    Hay una cosa más a tener en cuenta: aunque citar/escapar nombres de campo eliminará la inyección de SQL clásica, hay otro vector de ataque posible.
    Como no controlamos qué nombres de campo se utilizan para actualizar, es posible que el usuario modifique el valor al que no debería tener acceso. Por ejemplo, imagine que hay un campo en una tabla de usuarios como admin que se establece en 1 para admins y 0 para usuarios regulares. La función en cuestión permitirá a cualquier manipulador de código aumentar el nivel de privilegio de su cuenta.

    Suponiendo todo lo anterior, una función tan útil debe estar siempre aceptando un parámetro adicional con una lista de nombres de campos permitidos:

            <form method = POST> 
        <input type = hidden name = "name`=(SELECT'hacked!')WHERE`id`=1#" value = ""> 
        <input type = hidden name = "name" value = "Joe"> 
        <input type = hidden name = "id" value = "1"> 
        <input type = submit> 
        </form> 
    
     <? php 
         if( $_POST ) { 
             $pdo = new PDO('mysql:dbname=test;host=localhost', root', ''); 
             $allowed = ["name", "surname", "email"]; 
     
             $params = []; 
             $setStr = "" ; 
             foreach( $allowed as $key ) 
             { 
                 if( isset($_POST[$key]) && $key != "id" ) 
                 { 
                      $setStr .= "`" . str_replace("`", "``", $key). "` = :" . $key . ","; 
                      $params[$key] = $_POST[$key]; 
                 } 
             } 

             $setStr = rtrim($setStr, ",");
             $params['id'] = $_POST['id']; 
             var_dump("UPDATE users SET $setStr WHERE id = :id", $params, $_POST); 
             $pdo->prepare("UPDATE users SET $setStr WHERE id = :id")->execute($params); 
     }
     ?>

    ¡Con tal mejora nuestro código se convertirá en sólido en todo!

    Por supuesto, los ejemplos anteriores (punto 4) sólo funcionarán si el modo de emulación está activado. Pero usted tiene que entender que si la inyección del SQL puede ser explotada con éxito o no es una pregunta diferente y completamente irrelevante. Usted no debe dejar una inyección en el primer lugar o la manera de explotarlo se encontrará un día u otro.

    5. Entonces, las consultas preparadas sirven o no?

    Sí, pero a condición de que nuestro PDO esté configurado como se indica en el apartado 2

    5.1 Cómo prevenir inyección de SQL (casi) siempre* garantizado

    Utilice las instrucciones preparadas , también conocidas como consultas parametrizadas. Por ejemplo:

    /**
 * Note: This code is provided for demonstration purposes.
 *       In general, you want to add some application logic to validate
 *       the incoming parameters. You do not need to escape anything.
 */
$stmt = $pdo->prepare('SELECT * FROM blog_posts WHERE YEAR(created) = ? AND MONTH(created) = ?');
if ($stmt->execute([$_GET['year'], $_GET['month']])) {
    $posts = $stmt->fetchAll(\PDO::FETCH_ASSOC);
}

    Las declaraciones preparadas eliminan cualquier posibilidad de inyección de SQL en su aplicación web. No importa lo que se pasa a las variables $_GET aquí, la estructura de la consulta SQL no puede ser cambiada por un atacante (a menos que, por supuesto, tenga PDO::ATTR_EMULATE_PREPARES activado, lo que significaría que no está usando auténticas declaraciones).

    Nota: Si usted intenta desactivar PDO::ATTR_EMULATE_PREPARES es posible que algunas versiones de controladores de bases de datos ignoren este intento. Para tomar precauciones extras, establezca explícitamente el conjunto de caracteres en el DSN a uno que su aplicación y base de datos utilizan (por ejemplo UTF-8, el cual, si está usando MySQL, se llama confusamente utf8mb4).

    Los estados preparados solucionan un problema fundamental de la seguridad de la aplicación: Separan los datos que se van a procesar de las instrucciones que operan sobre dichos datos enviándolos en paquetes completamente separados. Este es el mismo problema fundamental que hace provoca los desbordamientos de pila.

    Siempre y cuando nunca concatenes las variables proporcionadas por el usuario o el entorno con la sentencia SQL (y asegúrandote de no usar preparaciones emuladas) puedes, para todos los propósitos, descartar la inyección de SQL de tu lista de preocupaciones para siempre.

    Advertencia Importante y Clarificación

    Las sentencias preparadas protegen las interacciones entre su aplicación web y su servidor de base de datos (si están en máquinas separadas, también deben comunicarse a través de TLS). Todavía es posible que un atacante pueda almacenar una carga útil en un campo que podría ser peligroso, por ejemplo, en un procedimiento almacenado. Llamamos a esto una inyección SQL de orden superior (la respuesta de Stack Overflow vinculada se refiere a ellos como de "segundo orden", pero cualquier cosa que se ejecute después la consulta inicial debería ser objeto de análisis).

    En esta situación, nuestro consejo sería no escribir procedimientos almacenados de tal manera que creen puntos de inyección SQL de orden superior.

    5.2 ¿Qué pasa con el saneamiento de las entradas (Sanitizing Input)?

    Si bien es posible prevenir ataques mediante la reescritura del flujo de datos entrantes antes de enviarlo al controlador de la base de datos, esta práctica está llena de matices peligrosos y oscuros... (Ambos enlaces en la oración anterior son muy recomendables.)

    A menos que desee tomar el tiempo para investigar y lograr un dominio completo sobre todos los formatos Unicode que su aplicación use o acepte, es mejor que no intente desinfectar sus entradas. Las sentencias preparadas son más eficaces en la prevención de la inyección de SQL que las cadenas de escape.

    Además, alterar el flujo de datos entrantes puede causar daños en los datos, especialmente si se trata de bloques binarios crudos (por ejemplo, imágenes o mensajes cifrados).

    Las sentencias preparadas son más fáciles y pueden garantizar la prevención de la inyección de SQL.

    Si la entrada del usuario nunca tiene la oportunidad de alterar la cadena de consulta, nunca puede conducir a la ejecución de código. Las sentencias preparadas separan completamente el código de los datos.

    5.3 La entrada debe ser validada

    La validación no es lo mismo que el saneamiento.
    Las sentencias preparadas pueden impedir la inyección de SQL pero no pueden guardarlos de datos incorrectos. Para la mayoría de los casos filter_var() es útil aquí.

    $email = filter_var($_POST['email'], FILTER_VALIDATE_EMAIL);
if (empty($email)) {
    throw new \InvalidArgumentException('Invalid email address');
}

    Nota: filter_var() valida que la cadena de correo electrónico dada se ajusta a la especificación RFC. No garantiza que haya una bandeja de entrada abierta en esa dirección ni compruebe que el nombre de dominio esté registrado. Una dirección de correo electrónico válida todavía no es segura para usar en consultas sin procesar, ni para mostrar en una página web sin filtrar para evitar ataques XSS .

    5.4 ¿Qué pasa con los identificadores de columnas y tablas?

    Dado que los identificadores de columna y tabla forman parte de la estructura de consulta, no es posible parametrizarlos. Por lo tanto, si la aplicación que está desarrollando requiere una estructura de consulta dinámica donde las tablas o columnas son seleccionadas por el usuario, debe optar por una lista blanca.

    Una lista blanca es una estrategia de lógica de aplicación que explícitamente sólo permite unos cuantos valores aceptados y rechaza el resto o utiliza un predeterminado sano. Contrasta con una lista negra que sólo prohíbe las entradas mal conocidas. En la mayoría de los casos las listas blancas son mejores para la seguridad que las listas negras.

    $qs = 'SELECT * FROM photos WHERE album = ?';
// Use switch-case for an explicit whitelist
switch ($_POST['orderby']) {
    case 'name':
    case 'exifdate':
    case 'uploaded':
       // These strings are trusted and expected
       $qs .= ' ORDER BY ' . $_POST['orderby'];
       if (!empty($_POST['asc'])) {
           $qs .= ' ASC';
       } else {
           $qs .= ' DESC';
       }
       break;
    default:
       // Some other value was passed. Let's just order by photo ID in descending order.
       $qs .= ' ORDER BY photoid DESC';
    }
$stmt = $db->prepare($qs);
if ($stmt->execute([$_POST['album_id']])) {
    $photos = $stmt->fetchAll(\PDO::FETCH_ASSOC); 
}

    Si permite que el usuario final proporcione los nombres de la tabla y/o de las columnas, ya que los identificadores no pueden parametrizarse, debe recurrir a escapar. En estas situaciones, recomendamos lo siguiente:

    No : Simplemente escriba los meta caracteres SQL (por ejemplo ' )
    Sí : Filtre todos los caracteres que no están permitidos.

    El siguiente fragmento de código sólo permitirá nombres de tablas que comiencen con una letra en mayúscula o minúscula seguida de cualquier número de caracteres alfanuméricos y subrayados.

    if (!preg_match('/^[A-Za-z][A-Za-z0-9_]*$/', $table)) {
    throw new AppSpecificSecurityException("Possible SQL injection attempt.");
}
// And now you can safely use it in a query:
$stmt = $pdo->prepare("SELECT * FROM {$table}");
if ($stmt->execute()) {
    $results = $stmt->fetchAll(PDO::FETCH_ASSOC);
}

    5.6 ¿Qué pasa si el uso de declaraciones preparadas parece demasiado engorroso?

    La primera vez que un desarrollador encuentra sentencias preparadas puede sentirse frustrado por la perspectiva de verse forzado a escribir mucho código redundante (preparar, ejecutar, buscar, preparar, ejecutar, buscar, ad nauseam ).

    Existe una biblioteca de PHP llamada EasyDB, que puede servir como alternativa al uso de PDO.

    6. Enlaces

    1. PDO y MySQLi nos protegen de la inyección SQL primaria solamente
    2. Inyección SQL de segundo nivel
    3. Muy buen artículo con algunas recomendaciones para el uso de PDO
    • 89

  3. Принятый ответ - отличное дополнение, которое всегда приветствуется. Некоторое время назад я также прочитал в Интернете статью, которая, на мой взгляд, довольно интересна, и я хотел бы поделиться ею, жаль, что она на английском языке, я собираюсь перевести часть статьи, насколько это возможно, так как это очень обширен ( Автостопом по предотвращению SQL-инъекций ).

    Быстрый ответ будет:

    Как защититься от инъекции типа [xxx].

    Вас могут атаковать разные виды инъекций - «слепые» , «задержка менструации» , «второго порядка» и тысячи других. Нужно понимать, что это не все разные способы выполнения инъекции, а просто разные способы ее использования. Хотя есть только один способ выполнить инъекцию: нарушить целостность запроса . Таким образом, если вы можете поддерживать целостность запроса, вы защищены от всех тысяч различных типов инъекций одновременно.

    А для поддержания целостности запроса просто правильно форматируйте литералы запроса.

    Вывод.

    Подводя итог, можно сформулировать два простых правила:

    Даже динамически созданный SQL-запрос должен состоять только из двух возможных типов данных:

    1. Постоянные части, закодированные в скрипте
    2. Заполнители для каждого динамического значения

    При соблюдении этих правил гарантируется 100% защита.

    Давайте посмотрим на более подробный ответ на предотвращение SQL-инъекций:

    1) Что такое SQL-инъекция?

    Источником проблемы inyección SQLявляется смесь кода и данных. По сути, наш запрос SQLпредставляет собой программу. Легальная и полная программа, как и наши PHPзнакомые скрипты. Так получилось, что мы создаем это приложение динамически, добавляя некоторые данные по ходу дела. Следовательно, эти данные могут мешать нашему коду и изменять его. Такое изменение было бы своим собственным inyección.

    Это может произойти только в том случае, если мы не отформатируем части нашего запроса неуязвимым образом.

    Давайте посмотрим на канонический пример:

    $nombre = 'Foo'; 
$sentencia = "SELECT * FROM usuario WHERE nombre='$nombre'";

    Которая скомпилирована в вредоносную последовательность.

    SELECT * FROM usuario WHERE nombre='Foo';

    Называют ли inyección? Неправильно. Это неправильное форматирование строкового литерала.

    Пока он правильно отформатирован, он никому не навредит:

    SELECT * FROM usuario WHERE nombre='Foo\';

    Возьмем другой канонический пример,

    $id    = "1";
$id    = mysqli_real_escape_string($conexion, $id);
$query = "SELECT * FROM usuario where id = $id";

    С менее вредным результатом:

    SELECT * FROM usuario WHERE id =1;

    Позвонить ему inyecciónснова? В очередной раз плохо. Это искаженный числовой литерал. Пока это правильный формат, честный

    SELECT * FROM usuario where id = 1;

    Заявление было бы положительно безвредным.

    Примечание. Вся опасность исходит от самого вопроса: миллионы пользователей PHP по-прежнему считают, что хорошо известная цель функции mysql_real_escape_string() — «защитить SQL от инъекций» (путем экранирования некоторых «опасных символов»). фиктивным образом). Если бы они знали истинное назначение этой честной функции, не было бы в мире инъекций! Если бы они просто форматировали свои запросы, а не «защищали» их, в результате у них была бы реальная защита.


    2) Каковы правила форматирования?

    Правда в том, что правила форматирования не так просты и не могут быть выражены в одном императиве. Для MySQL это будет:

    1. Цепи

    • Они должны быть добавлены с помощью собственного оператора подготовки или специальные символы должны быть заключены в кавычки и должны быть экранированы.
    • Правильная кодировка клиента должна или может быть закодирована в шестнадцатеричном формате.

    2. Числа

    • Они должны быть добавлены с помощью собственного подготовленного оператора или должны быть отформатированы, чтобы содержать только числа, десятичный разделитель и знак.

    3. Идентификаторы

    • Они должны быть заключены в одинарные кавычки.
    • Спецсимволы (откровенно говоря — те самые обратные кавычки-разделители) нужно экранировать.

    4. Операторы и ключевые слова

    • Для ключевых слов и операторов не существует специальных правил форматирования, за исключением того, что они должны быть законными операторами и ключевыми словами SQL. Поэтому они должны быть в белом списке.

    Как видите, существует четыре различных набора правил, а не одно утверждение.


    3) Подготовленные отчеты

    Идея sentencia preparadaнативного умная и простая: запрос и данные отправляются на сервер отдельно друг от друга, а значит нет возможности их мешать. Что делает невозможным inyección. Но в то же время нативная реализация имеет свои ограничения, поскольку поддерживает только два типа литералов (а именно строки и числа), что делает их недостаточными и небезопасными для реального использования.

    И тут мы подходим к главному: общая идея создания запроса SQLиз константной части и заполнителей, который заменяется реальными данными, автоматически форматируется — это действительно тот самый Святой Грааль, который мы искали.

    Основное и самое существенное преимущество declaraciones preparadas— устранение всех опасностей ручного форматирования:

    • Подготовленный оператор выполняет полное форматирование. Все это без вмешательства программиста!
    • Подготовленный оператор, который выполняет правильное форматирование (пока мы привязываемся к нашим данным, используя правильный тип).
    • Подготовленные операторы делают форматирование неуязвимым.
    • Подготовленная выписка оформляется в единственно правильном месте - непосредственно перед выполнением запроса.

    Вот почему ручное форматирование сегодня так презирают, а подготовленные операторы так чтят.

    mysqli_prepare — подготавливает оператор SQL к выполнению:

    $mi_conexion = new mysqli("servidor", "usuario", "contraseña", "basedatos");

$id = $_POST['id'] ?: '';

//la consulta y los datos se envían al servidor separados entre sí, lo que evita posible inyección.
$stmt = $mi_conexion->prepare("SELECT nombre FROM usuario WHERE id=?"); //Consulta
$stmt->bind_param("i",$id);//Datos
$stmt->execute();//Ejecutamos sentencia.


    4) Некоторые ложные измерения и плохие практики

    1. Экранирование пользовательского ввода.

    Это король. Серьезная иллюзия, до сих пор разделяемая почти всеми пользователями PHP (и даже OWASP, как видите). Он состоит из двух частей: «Экранирование» и «Ввод пользователя»:

    1. Экранирование: как отмечалось выше, он выполняет только часть работы только для одного буквального типа. А когда используется отдельно или не в том месте, это верный призыв к катастрофе.

    2. Пользовательский ввод: В контексте защиты от инъекций таких слов быть не должно. Каждая переменная потенциально опасна - независимо от источника! Или, другими словами, все переменные должны быть правильно отформатированы, чтобы быть помещенными в запрос - не говоря уже об источнике. Это пункт назначения, который имеет значение. В тот момент, когда разработчик начинает отделять овец от козлов, он делает первый шаг к катастрофе.

    2. Проверка данных.

    Надо понимать, что валидация входных (в смысле пользовательского ввода) данных не имеет абсолютно никакого отношения к SQL. Действительно. Никакое правило проверки не может помочь против SQL-инъекций, если текст произвольной формы разрешен. Тем не менее, мы все равно должны отформатировать наш SQL, несмотря на любую проверку - напомните Саре О'Хара, что он принимает имя, которое совершенно правильно с точки зрения пользовательского ввода. Также помните, что правила проверки могут меняться.

    3. Htmlspecialchars (а также filter_var() , strip_tags() и тому подобное).

    Друзья. Это кодировка HTML, если вы еще не заметили. Это не имеет абсолютно никакого отношения к SQL. Это совсем не помогает и никогда не должно использоваться в контексте защиты от SQL-инъекций. Это абсолютно неприменимо для SQL и не может защитить ваш запрос, даже если он используется как функция экранирования строки. Оставьте это для других частей вашего приложения. Кроме того, пожалуйста, поймите, что формат SQL никогда не должен касаться данных. Итак, вы кладете свои драгоценности в сейф, вы хотите, чтобы они были целыми, а не модифицированными или замененными частями! То же самое. База данных предназначена для хранения ваших данных, а не для их «защиты». И важно хранить точные данные, которые вы хотите использовать повторно (означает, что ваша глупая попытка base64 тоже неверна, кстати).

    • 63

  4. Еще одна рекомендация помимо лучшего хорошего ответа

    Рекомендуется добавлять маску к url ​​и создавать дружественные url, которые выполняют 2 функции: 1- скрывают параметры, отправляемые get, а также помогают пользователю более четко видеть информацию.

    Пример

    стандартный URL-адрес: http://stackoverflow.com?id=100
    дружественный URL-адрес: как избежать инъекции SQL в PHP?

    Примечание. Первый URL-адрес не соответствует понятному URL-адресу и является просто примером.

    В случае, если атакующий хотел атаковать стандартный url, у него уже был бы параметр для запуска «id», а в случае с дружественным url все не так просто и он должен дополнительно анализировать сделанный запрос к веб-серверу и найти URL.

    Основные измерения

    Как скрыть URL

    Примером является изменение файла .htaccess на вашем веб-сервере и его привязка с помощью mod_rewrite, если вы используете Apache.

    Подробнее об этом здесь: http://www.emenia.es/como-crear-urls-amigables-con-htaccess/

    Если вы думаете, что этого недостаточно

    Было бы целесообразно совместить использование логина, отслеживания файлов cookie, заголовков, веб-агента.

    Также добавьте систему капчи, чтобы избежать множественных запросов, генерируемых роботами.

    • 31

  5. Mi respuesta simple, vamos al grano, lo que debes hacer ademas de un sistema de login y sesión de usuarios, es "validaciones" (especialmente en el login), crear un pattern y compararlo con lo que viene del post, (ademas de las validaciones básicas disponibles con html ) si es válido que lo deje pasar, algo así: 

    public function index(){
            if ($_POST) { 
               $permitidos = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789@-_.'; 
                for ($i=0; $i<strlen($_POST['username']); $i++){ 
                 if (strpos($permitidos, substr($_POST['username'],$i,1))===false){ 

                  $da = true;
                  return $da; 
                  }else{    
                 }
             }...

    Este filtro determina si la cadena de texto contiene caracteres que no están en tu lista de permitidos, después si pasa por el filtro, el resto del código que seria lo que haría, guardar actualizar etc.

    luego capturas el $da(datos del return) y lo muestras en el front como variable, para que si existe algo en el return, despliegue un mensaje de error en el formulario.

    Por otro lado también deshabilita que puedan copiar y pegar en los inputs del formulario.

    <input type="text" class="form-control" id="username" required name="username" onpaste="return false">

    En resumen: debes evitar que ingresen caracteres especiales que se usan en las consultas sql, como * ; etc.

    • 21

  6. Interesante post. Actualmente estoy desarrollando un panel de administrador para un sitio web y el formulario de la página de inicio tiene en total, hasta ahora, 46 campos para texto (incluyendo rutas a imágenes). Primero creo la conexión a la base de datos:

        $conexion = new PDO('mysql:host=localhost;dbname=basededatos;charset=utf8', 'usuario', 'contraseña');

    Cuando el usuario le da click al botón "guardar cambios", se ejecuta el siguiente código:

    $slogan = $_POST['slogan']; 
   if(strpos($slogan, '<script>') || strpos($slogan, 'Drop') || strpos($slogan, 'SELECT')){
     $slogan = htmlspecialchars($_POST['slogan']);
   }        
   $statement2 = $conexion->prepare("UPDATE inicio SET slogan = :slogan WHERE id=1");
   $conexion->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
   $conexion->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
   $statement2->bindParam(":slogan", $slogan, PDO::PARAM_STR);
   $statement2->execute();

    Y luego tengo que realizar el mismo proceso que hice para el slogan 45 veces mas, y eso solo para la página de inicio. Mi pregunta es si estoy previniendo bien la inyección SQL y además previniendo que se puedan ejecutar scripts de Javascript (por el condicional que tiene strpos buscando por "script" para aplicar htmlspecialchars si lo encuentra).

    Soy bastante novato en cuanto a PHP y MySql así que agradezco cualquier orientación que me puedan brindar. Saludos.

    • 0