Есть ли в MySQL встроенные средства защиты от атак с использованием инъекций от URL-атак?

Question

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

---

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

Одна страница загружает информацию о человеке из базы данных на основе уникального идентификационного номера, которыйвиден через URL страницы.Очевидно, что это отдельная проблема - я мог бы просто изменить идентификатор с «? Id = 2» на «? Id = 3», чтобы загрузить новую запись из базы данных - но проблема, с которой я больше обеспокоенмоментом является атака на основе URL для выполнения «плохого» запроса поверх предполагаемого запроса.

Намеченный запрос выглядит примерно так: ... where person.ID="10" and person.ID = notes.ID and ...

При изменении URL,Я могу закрыть параметр, который ищет идентификатор, и выполнить другой, потенциально вредоносный запрос, такой как:

... ?id=10"; drop table person; select * from notes where ID=" ... 

, который приведет к выполнению следующих запросов:

... select * from person, notes where id="10"; drop table person; select * from notes where ID="" and ...

Мне удалось распечатать этот вредоносный набор запросов (эхо) на моей веб-странице, поэтому я знаю, что это уязвимость.Тем не менее, когда я пытаюсь выполнить этот точный запрос в MySQL, он зависает на несколько секунд перед тем, как полностью выйти из MySQL с ответом «Killed» и без дальнейших объяснений.

Мой вопрос заключается в том, что заставляет MySQL убиватьэтот вредоносный запрос и выход?Это похоже на функцию безопасности, но я не знаю, что это будет - эти запросы сами по себе прекрасно работают.Меня также смущает отсутствие сообщения об ошибке, кроме «Убит», если кто-нибудь сталкивался с подобной ситуацией.

Answer 1

Единственная защита MySQL от случая, который вы демонстрируете, заключается в том, что по умолчанию интерфейс запросов MySQL не выполняет несколько операторов.Разделение операторов по ; приведет только к синтаксической ошибке.

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

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

$pdo->query("insert into foo set id = 1; insert into foo set id = 2");

Однако, если вы попытаетесь использовать подготовленные операторы (отключение эмулированной подготовки), произойдет сбой:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

$stmt = $pdo->prepare("insert into foo set id = ?; insert into foo set id = ?");

Это выбрасываетисключение, если вы включили исключения:

Неустранимая ошибка PHP: Uncaught PDOException: SQLSTATE [42000]: синтаксическая ошибка или нарушение прав доступа: 1064 В синтаксисе SQL имеется ошибка;проверьте руководство, соответствующее вашей версии сервера MySQL, на предмет правильного синтаксиса, который можно использовать рядом с «вставить в foo set id =?»в строке 1

Mysqli включает мультизапрос только для запросов, которые вы выполняете с помощью функции mysqli_multi_query () .Поэтому, если вы не используете multi_query () в своем коде, вы в безопасности.

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

Параметры не просто объединяются в запрос SQL, когда вы используете подготовленные операторы.Это ошибочное мнение многих разработчиков.

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

Именно поэтому параметры запроса являются хорошим методом защиты вашего приложения от SQLинъекции.