Безопасны ли такие SQL-запросы?

Question

[BlackWolf]

1. Опасно ли писать такие SQL-запросы? Если да, то хотелось бы узнать уязвимости построения таких запросов. Про подготовленные выражения знаю, но пока плохо понимаю.

$name = strip_tags(htmlspecialchars(addslashes(($_POST['name']))))
$escape = mysqli_real_escape_string($connection, $name);
$sql = "INSERT INTO `users` (`name`) VALUES ('$escape')";
$sqlquery = mysqli_query($connection, $sql);

P.S для дополнительной безопасности можем удалять фразы с помощью preg_replace: |DROP|, |DELETE|, |SELECT|, |UPDATE|, |INSERT|, |UNION|.

2. Безопасен ли такой GET-параметр? Возможна ли в данном случае SQL-инъекция? Если да, то как?

if (isset($_GET['id'])) {
    $id = (int)$_GET['id']; // тут еще можно использовать mysqli_real_escape_string или htmlspecialchars, но не вижу смысла, так как это (int).
}

Comments

[adrenalinruslan]

Почему бы не использовать PDO ?

Answer 1

[Immortal_pony]

Для защиты от sql-инъекций используйте подготавливаемые запросы с привязкой параметров.

Comments

[BlackWolf]

Спасибо за ответ. Кажется, придется переписывать весь сайт... Но у меня есть еще несколько вопросов:
1. А в чем уязвимость запроса, который приведен в вопросе? Все данные, поступающие от пользователя, экранируются. Защита от XSS тоже есть.
2. Подготавливаемые запросы защищают от SQL-инъекций на 100%? Или они тоже имеют уязвимости?

[Immortal_pony]

BlackWolf,

Кажется, придется переписывать весь сайт

Вынесите низкоуровневое взаимодействие с БД в отдельную функцию или класс.
Ну и валидацию/очистку пеменных тоже.
Можете воспользоваться готовыми библиотеками, или построить свою систему на основе какого-либо фрэймворка, чтобы не писать всё самостоятельно.

А в чем уязвимость запроса, который приведен в вопросе?

Экранирование можно обойти. Например, если явно не задан character_set. Защиту от XSS вам надо будет использовать и в случае с подготавливаемыми запросами.

Подготавливаемые запросы защищают от SQL-инъекций на 100%?

На 100% ничто не защищает. Но данный механизм более надежный, нежели экранирование.

[BlackWolf]

Immortal_pony, А можно ли использовать обычный SQL-запрос в том случае, если переменная поступает от (int)$_GET, либо известна, но не поступает от пользователя? Например:

$id = (int)$_GET['id']; 
$sql = "SELECT id FROM `users` WHERE id='$id'";
$query = mysqli_query($link, $sql);

Или так:

$id = 123; 
$sql = "SELECT id FROM `users` WHERE id='$id'";
$query = mysqli_query($link, $sql);

Или абсолютно все запросы нужно подготавливать?

[Immortal_pony]

Вполне безопасно. Но это требует повышенной внимательности - один раз забудете написать int и получите огромную дыру.

[BlackWolf]

Immortal_pony, 1. А какой стиль программирования лучше и удобнее для подготавливаемых запросов? ООП или процедурный?
2. Как подготовить данные, которые будут содержать цифры, буквы, символы?

$mysqli = new mysqli('localhost', 'my_user', 'my_password', 'world');
$code = 'DEU'; // это string (s)
$language = 'Bavarian'; // тоже string
$official = '$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a'; // А как быть с хешем пароля?
$percent = 'username123'; // А как быть с этим? 
$stmt = $mysqli->prepare("INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)");
$stmt->bind_param('ss??', $code, $language, $official, $percent);
$stmt->execute();
$stmt->close();
$mysqli->close();

3. От XSS нужно защищаться так?

$mysqli = new mysqli('localhost', 'my_user', 'my_password', 'world');
$code = htmlspecialchars($_POST['text1']);// 123 - int
$language = htmlspecialchars($_POST['text2']); // abc - string
$stmt = $mysqli->prepare("INSERT INTO CountryLanguage VALUES (?, ?)");
$stmt->bind_param('is' $code, $language);
$stmt->execute();
$stmt->close();
$mysqli->close();

4. А стоит ли использовать mysqli_real_escape_string, addslashes, strip_tags для $_POST['text']? (Перед подготавливаемым запросом)

P.S Большое спасибо за помощь и ответы :)

[Immortal_pony]

А какой стиль программирования лучше и удобнее для подготавливаемых запросов? ООП или процедурный?

Зависит от кода вашего проекта в целом. С точки зрения работоспособности - без разницы.

2. Как подготовить данные, которые будут содержать цифры, буквы, символы?

Они будут строками.

$official = '$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a';

Это строка

$official = '$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a';

И это тоже строка.

3. От XSS нужно защищаться так?

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

4. А стоит ли использовать mysqli_real_escape_string, addslashes, strip_tags для $_POST['text']? (Перед подготавливаемым запросом)

mysqli_real_escape_string и addslashes не нужны в случае с подготавливаемыми запросами.
strip_tags поможет от XSS, но иногда и HTML-контент надо сохранить. Так что зависит от ситуации.

Answer 2

[ivankomolin]

1. Да, опасно. В вашем случае заэкранируются кавычки и что-то вроде такого \x00, \n, \r, \. А вот "; drop table ***" позволит написать с легкостью)
2. В таком виде безопасен. Но завтра кто-нибудь уберет (int) без задней мысли и он снова опасен.

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

Comments

[BlackWolf]

1. Как злоумышленник сможет удалить таблицу? Он ведь не знает ее названия. А если я назову её не `users`, а гораздо сложнее? Вывод ошибок отключаем: error_reporting(0); //чтобы не узнали имя таблицы
А еще с помощью preg_replace можно удалить фразы из строки: |DROP| |INSERT| |UPDATE| |DELETE| |SELECT|.
Или все гораздо сложнее?

[Ваня]

BlackWolf, ещё можно штаны через голову одевать, почитайте про PDO лучше, а потом перед ним можете со спокойной душой рисовать миллиард проверок на всё и вся

[BlackWolf]

Сергей, PDO? Пока только учусь. Но меня интересует именно тот запрос, который приведен в вопросе. Хотелось бы узнать уязвимости

[Максим Тимофеев]

BlackWolf,

Он ведь не знает ее названия

Вы серьезно? Много вариантов, например банально перебор

А еще с помощью preg_replace можно удалить фразы из строки

Можно. Вы думаете вся логика взломщиков сводится к этому?

Но меня интересует именно тот запрос, который приведен в вопросе

Сделайте сайт, попросите сломать, пообещайте спасибо и попросите сказать как.

[alexalexes]

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

[BlackWolf]

alexalexes, А почему нельзя склеивать строки запросов с параметрами? Из-за повышенной вероятности SQL-инъекции? Или другая причина?

[alexalexes]

Именно. Если для числовых типов данных можно сделать банальное приведение к типу, то стоковые параметры только через bind передавать.
Вообще, красиво смотрится, когда в коде есть четкие этапы взаимодействия с СУБД:
connection -> prepare query -> bind params -> execute -> disconnect. И связывание параметров - это как раз один из этих этапов. Плюс хорошо, если на каждом этапе будет обработка возможных ошибок.

Answer 3

[Максим Тимофеев]

Крошка сын
--------к отцу пришел,
--------и сказала кроха:
------------PDO - хорошо
------------mysqli это плохо

Comments

[Immortal_pony]

Чем вам не угодил mysqli?

[Максим Тимофеев]

Immortal_pony,
Дело же не в симпатиях:
https://ruseller.com/lessons.php?rub=37&id=1381
просто логически обоснованный выбор. В статье еще не говорится, что практически все современные php framework используют PDO, мелкий, но тоже плюсик в копилку.

[Immortal_pony]

Максим Тимофеев, из приведенной статьи не следует, что PDO лучше mysqli. Они просто разные. Более того, статья написана новичком в разработке, так у mysqli и pdo куда больше различий, чем описано. Ну и голословные заявления о скорости выполнения без описания параметров бенчмарков не добавляют статье веса, конечно.

Для ситуаций, когда в проекте надо перейти на использование другой базы данных, PDO позволит сделать процесс прозрачным. Все, что нужно будет сделать - изменить строку соединения и несколько запросов, если какие-либо методы не поддерживаются новой базой данных. В случае с MySQLi придется переписывать весь код, включая запросы

Ну откровенный же бред. Если вы меняете тип базы данных, то запросы-то в любом случае придется переписывать (диалекты SQL у многих БД разнятся, особенно это заметно при сложных запросах).
И изменить драйвер БД mysqli на, скажем, sqlite - так это тоже правка одной строки плюс однгого-двух методов, отвечающих непосредственно за выполнение запросов.

Фрэймворки поддерживают PDO потому что ориентированы на поддержку множественных типов баз данных. В одном же проекте крайне редко используются разные БД или происходит смена БД. Поэтому данным функционалом можно пренебречь.

[Максим Тимофеев]

Immortal_pony, из приведенной мной шутки на основе стихотворения Маяковского тоже. Вам бы понравилось:
Крошка сын к отцу пришел, и сказала кроха:
PDO - хорошо
mysqli это немного слабее, по ряду причин ... (далее статья)
Так???

[Immortal_pony]

Максим Тимофеев, если вы хотите выразить мою мысль в стихотворной форме, то используйте следующий подстрочник с тезисами:
Экранирование вручную - плохо.
Использование подготовливаемых запросов с привязкой параметров - хорошо.
PDO или mysqli - не важно.

Жду шедевра.

[Максим Тимофеев]

Immortal_pony, Еще раз, для тех кто на бронепоезде.
1. это шутка, сама форма ответа на это жирно намекает
2. это Маяковский, я так не смогу

PDO или mysqli - не важно.

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

[Immortal_pony]

Максим Тимофеев,

1. это шутка, сама форма ответа на это жирно намекает

Ну так и я шедевра не на полном серьезе требую. Хотя бы удачную попытку...

2. это Маяковский, я так не смогу

А "так" и не надо. Достаточно использовать разработанный маэстро стиль.

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

Обоснуйте.

[Максим Тимофеев]

Immortal_pony,

Обоснуйте.

Что удобнее

$params = array(':username' => 'test', ':email' => $mail, ':last_login' => time() - 3600);
   
$pdo->prepare('
    SELECT * FROM users
    WHERE username = :username
    AND email = :email
    AND last_login > :last_login');
     
$pdo->execute($params);

или

$query = $mysqli->prepare('
    SELECT * FROM users
    WHERE username = ?
    AND email = ?
    AND last_login > ?');
     
$query->bind_param('sss', 'test', $mail, time() - 3600);
$query->execute();

Речь о именовании параметров, что бы не иметь проблем с последовательностью. Да и куча мелочей еще.

[Immortal_pony]

Максим Тимофеев, это синтаксическая вкусовщина, изменяемая в рамках функции-обертки для запросов в БД. С точки зрения безопасности или скорсти исполнения ни на что не влияет.

[Максим Тимофеев]

Immortal_pony, Ну тогда и наличие ООП как в mysqli так и в php в целом - это вкусовщина. Мы так далеко зайдем. Есть факт, что вариант с именованием параметров более удобен и безопасен (в плане ошибок описок). Нравится Вам это или нет - это есть.

[Immortal_pony]

Ну тогда и наличие ООП как в mysqli так и в php в целом - это вкусовщина.

Безусловно. И, например, при написании серверны скриптов прнебрегать наличием ООП в PHP более чем нормально. И процедурный mysqli туда отлично заходит.

Есть факт, что вариант с именованием параметров более удобен и безопасен (в плане ошибок описок)

Это не факт, а ваше личное мнение.

[Максим Тимофеев]

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

[Immortal_pony]

Максим Тимофеев, не вопрос; думаю, что тему мы раскрыли достаточно :)