Должен ли я защищаться от SQL-инъекций, если я использовал раскрывающийся список?

Я понимаю, что вам НИКОГДА не следует доверять пользовательскому вводу из формы, в основном из-за возможности SQL-инъекции.

Однако применимо ли это также к форме, в которой ввод осуществляется только из раскрывающихся списков (см. Ниже)?

Я сохраняю $_POST['size']его в сеансе, который затем используется по всему сайту для запроса различных баз данных (с помощью mysqliзапроса Select), и любая SQL-инъекция определенно повредит (возможно, отбросит) их.

Здесь нет области для ввода пользовательского ввода для запроса баз данных, только раскрывающиеся списки.

<form action="welcome.php" method="post">
<select name="size">
  <option value="All">Select Size</option> 
  <option value="Large">Large</option>
  <option value="Medium">Medium</option>
  <option value="Small">Small</option>
</select>
<input type="submit">
</form>

Вы можете сделать что-нибудь столь же простое, как следующий пример, чтобы убедиться, что опубликованный размер соответствует вашим ожиданиям.

$possibleOptions = array('All', 'Large', 'Medium', 'Small');

if(in_array($_POST['size'], $possibleOptions)) {
    // Expected
} else {
    // Not Expected
}

Затем используйте mysqli_ *, если вы используете версию php> = 5.3.0, которой вы должны быть, чтобы сохранить результат. При правильном использовании это поможет с внедрением sql.

Да, от этого нужно защититься.

Позвольте мне показать вам, почему, используя консоль разработчика Firefox:

Если вы не очистите эти данные, ваша база данных будет уничтожена. (Это может быть не совсем корректный оператор SQL, но я надеюсь, что понял свою точку зрения.)

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

Если вы попытались дополнительно ограничить это использование поведения на своей странице, мои варианты включают отключение этого поведения или просто написание пользовательского HTTP-запроса на ваш сервер, который все равно имитирует отправку этой формы. Именно для этого используется инструмент под названием curl , и я думаю, что команда для отправки этой SQL-инъекции в любом случае будет выглядеть примерно так:

curl --data "size=%27%29%3B%20DROP%20TABLE%20*%3B%20--"  http://www.example.com/profile/save

(Возможно, это не совсем верная команда curl, но опять же, я надеюсь, что уловил свою точку зрения.)

Итак, повторю:

НИКОГДА не доверяйте вводу пользователя. ВСЕГДА защищайте себя.

Не думайте, что любой ввод пользователя безопасен. Это потенциально небезопасно, даже если оно поступает не с помощью формы. Ничто из этого не заслуживает доверия, чтобы отказаться от защиты от SQL-инъекции.

Поскольку этот вопрос был отмечен sql-инъекция, вот ответ относительно этого типа атаки:

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

Независимо от любого материала HTML!
Важно понимать, что SQL-запросы должны быть правильно отформатированы независимо от любых внешних факторов, будь то ввод HTML или что-то еще.

Хотя вы можете использовать белый список, предложенный в других ответах, для цели проверки ввода, он не должен влиять на какие-либо действия, связанные с SQL - они должны оставаться такими же, независимо от того, проверяли ли вы ввод HTML или нет. Это означает, что вам все равно придется использовать подготовленные операторы при добавлении любых переменных в запрос.

Здесь вы можете найти подробное объяснение, почему подготовленные операторы необходимы и как их правильно использовать, а где они неприменимы, и что делать в таком случае: Автостопом по защите от SQL-инъекций

Кроме того, этот вопрос был помечен mysqli. Я полагаю, что в основном случайно, но в любом случае я должен предупредить вас, что необработанный mysqli не является адекватной заменой старых функций mysq_ * . Просто потому, что, если использовать его в старом стиле, он вообще не добавит безопасности. Хотя поддержка подготовленных операторов болезненна и проблематична, до такой степени, что средний пользователь PHP просто не может попытаться их применить. Таким образом, если ORM или какая-то библиотека абстракций не является вариантом, тогда PDO - ваш единственный выбор.

Да.

Кто угодно может подделать что угодно для значений, которые действительно отправляются -

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

if(in_array($_POST['ddMenu'], $dropDownValues){

    $valueYouUseLaterInPDO = $dropDownValues[array_search("two", $arr)];

} else {

    die("effin h4x0rs! Keep off my LAMP!!"); 

}

Один из способов защиты от пользователей, изменяющих раскрывающиеся списки с помощью консоли, - использовать в них только целые значения. Затем вы можете проверить, что значение POST содержит целое число, и использовать массив для преобразования его в текст при необходимости. Например:

<?php
// No, you don't need to specify the numbers in the array but as we're using them I always find having them visually there helpful.
$sizes = array(0 => 'All', 1 => 'Large', 2 => 'Medium', 3 => 'Small');
$size = filter_input(INPUT_POST, "size", FILTER_VALIDATE_INT);

echo '<select name="size">';
foreach($sizes as $i => $s) {
    echo '<option value="' . $i . '"' . ($i == $size ? ' selected' : '') . '>' . $s . '</option>';
}
echo '</select>';

Затем вы можете использовать $sizeв своем запросе, зная, что он всегда будет содержать FALSEтолько целое число.

Другие ответы уже охватывают то, что вам нужно знать. Но, возможно, это поможет прояснить еще кое-что:

Есть две вещи , которые вы должны сделать:

1. Подтвердите данные формы.

Как ясно показывает ответ Джонатана Хоббса , выбор элемента html для ввода формы не обеспечивает надежной фильтрации.

Проверка обычно выполняется таким образом, чтобы данные не изменялись, но снова отображалась форма с полями, помеченными как «Исправьте это».

Большинство фреймворков и CMS имеют конструкторы форм, которые помогут вам с этой задачей. И не только это, они также помогают против CSRF (или «XSRF»), который является еще одной формой атаки.

2. Очистить / избежать переменных в операторах SQL.

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

Если вы создаете инструкцию (My) SQL с любыми переменными, предоставленными пользователем или нет, вам нужно экранировать и заключить эти переменные в кавычки.

Как правило, любая такая переменная, которую вы вставляете в инструкцию MySQL, должна быть либо строкой, либо чем-то, что PHP может быть надежно преобразовано в строку, которую MySQL может переварить. Например, числа.

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

• В старой школе MySQL + PHP mysql_real_escape_string () выполняет эту работу. Проблема в том, что об этом слишком легко забыть, поэтому вы обязательно должны использовать подготовленные операторы или построители запросов.
• В MySQLi вы можете использовать подготовленные операторы.
• Большинство фреймворков и CMS предоставляют построители запросов, которые помогут вам с этой задачей.

Если вы имеете дело с числом, вы можете опустить экранирование и кавычки (вот почему подготовленные операторы позволяют указать тип).

Важно отметить, что вы избегаете переменных для оператора SQL, а НЕ для самой базы данных . В базе данных будет храниться исходная строка, но для оператора требуется экранированная версия.

Что произойдет, если вы пропустите одно из них?

Если вы не используете проверку формы , но дезинфицируете свой ввод SQL, вы можете увидеть все виды плохих вещей, но вы не увидите SQL-инъекцию! (*)

Во-первых, это может привести ваше приложение в состояние, которое вы не планировали. Например, если вы хотите рассчитать средний возраст всех пользователей, но один пользователь указал возраст «aljkdfaqer», ваш расчет не удастся.

Во-вторых, могут быть всевозможные другие виды атак с использованием инъекций, которые вам необходимо учитывать: например, пользовательский ввод может содержать javascript или другой материал.

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

Но даже если у вас есть свободное текстовое поле, в котором вы разрешаете любой ввод без проверки вообще, вы все равно можете сохранить его в базе данных точно так же, если вы правильно экранируете его, когда он переходит к оператору базы данных. Проблема возникает, когда вы хотите где-то использовать эту строку.

(*) или это было бы что-то действительно экзотическое.

Если вы не экранируете переменные для операторов SQL , но проверили ввод формы, вы все равно можете видеть, что происходит плохое.

Во-первых, вы рискуете, что при сохранении данных в базе данных и их повторной загрузке это уже не будут те же данные, «потерянные при переводе».

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

В-третьих, это все еще может вызывать SQL-инъекцию.

Если ваш пользовательский ввод из форм уже отфильтрован / проверен, намеренная инъекция SQl может стать менее вероятной, ЕСЛИ ваш ввод сведен к жестко запрограммированному списку параметров или если он ограничен числами. Но любой ввод произвольного текста можно использовать для SQL-инъекции, если вы не экранируете переменные в операторах SQL должным образом.

И даже если у вас вообще нет ввода формы, у вас все равно могут быть строки из всех источников: чтение из файловой системы, извлечение из Интернета и т. Д. Никто не может гарантировать, что эти строки безопасны.

Ваш веб-браузер не «знает», что он получает страницу с php, он видит только html. А слой http знает еще меньше. Вам нужно уметь обрабатывать практически любой тип ввода, который может пересекать слой http (к счастью, для большинства вводимых php уже выдает ошибку). Если вы пытаетесь не допустить, чтобы вредоносные запросы испортили вашу базу данных, вам нужно предположить, что парень на другом конце знает, что он делает, и что он не ограничен тем, что вы можете видеть в своем браузере при нормальных обстоятельствах ( не говоря уже о том, что вы можете возиться с инструментами разработчика браузера). Итак, да, вам нужно учитывать любой ввод из раскрывающегося списка, но для большинства вводимых данных вы можете выдать ошибку.

Тот факт, что вы ограничили пользователя только использованием значений из определенного раскрывающегося списка, не имеет значения. Технический пользователь может перехватить http-запрос, отправленный на ваш сервер, до того, как он покинет его сеть, изменить его с помощью такого инструмента, как локальный прокси-сервер, а затем продолжить его. Используя измененный запрос, они могут отправлять значения параметров, отличные от тех, которые вы указали в раскрывающемся списке. Разработчики должны иметь представление о том, что ограничения клиента часто бессмысленны, поскольку в клиенте можно изменить что угодно. Проверка сервера требуется в каждой точке ввода данных клиента. Злоумышленники полагаются на наивность разработчиков только в этом аспекте.

Лучше всего использовать параметризованный запрос, чтобы избежать SQL-инъекций. В этом случае запрос будет выглядеть так:

SELECT * FROM table WHERE size = ?

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

SELECT * FROM table WHERE size = 'DROP table;'

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

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

Пример того, что может и произойдет, когда вы доверяете клиенту.

Хакер может полностью обойти браузер, включая проверку формы Javascript, отправив запрос через Telnet. Конечно, он будет смотреть на код вашей html-страницы, чтобы получить имена полей, которые он должен использовать, но с тех пор для него «все идет». Таким образом, вы должны проверить все значения, отправленные на сервер, как если бы они не были получены с вашей html-страницы.