Является ли SQL запрос уязвимым к SQL инъекции?

Question

[Павел]

Метод экранирования \" обеспечивает безопасность запроса от SQL инъекции или нет?

if( $accounts = $this->mysqli->query("SELECT * FROM `".DB_DB."`.`staff` WHERE `login`=\"$login\"") )
			{
				$row_cnt = $accounts->num_rows;
				if( $row_cnt != NULL )
				{
					while($row = $accounts->fetch_assoc())
					{
						if( strcmp( $row['password'] , md5($pass) ) == 0)
						{
							$this->group = $row['group'];
							return true;
						}
						else
							return false;
					}
					$accounts->close();
				}
				else
					return false;
			}
			else
				return false;

Comments

[AlikDex]

просто ипользуйте плейсхолдеры. Не морочьте себе и людям голову.

[Павел]

AlikDex: У меня вопрос не о том, что использовать для защиты, а о том уязвим запрос или нет, и по возможности написать как применить инъекцию к данному запросу.

[AlikDex]

Павел: положим, для начала введем имя Гарик "--Бульдог" Харламов. Вводите как написано. Как поведет себя ваш код?

[Павел]

AlikDex: Мой код ничего не ответит на это, кроме как ошибки в логине или пароле.

[Павел]

AlikDex: Я добавил соответствующий код, на котором проводил проверку вашим выражением Гарик "--Бульдог" Харламов

[AlikDex]

Павел: Т.е. просто сломается.
javascript:alert('Hello!');
такой ник впишу например
а потом вы сделаете ссылку на профиль =)

[Павел]

AlikDex: вопрос был о SQL инъекции, а не о XSS . Что-то вы напутали )

[AlikDex]

Павел: так надо смотреть в комплексе. От инъекций защитится проще. Об этом даже не думают сейчас просто используя подготовленные выражения. Ваш код вполне безопасен от инъекции в таком виде (именно этот запрос). Но он ломается на раз два. Нет нормальной валидации, и потенциально несет в себе кучу издержек при рефакторинге. Допустим вы точно также какую-нибудь статью заэкранируете, вот мороки то будет ;D А в дальнейшем решите добавить некоторые теги....
Короче, это назвается говнокод. На помойку его.

[Павел]

AlikDex: Так ни о каких статьях и не идет речь ) Речь идет конкретно об одном куске кода, где используется экранирование, но мне что-то не верится, что из-за экранирования не проходит инъекция. Я убрал экранирование и получил вполне хорошую дырку, а инъекция все также не выполняется, не пойму почему...

[AlikDex]

Павел: потому что эта версия драйвера мускула не поддерживает запросы через ;
унионом можно что-нибудь достать, например.

[Павел]

AlikDex:
В форму вставил выражение:
hack" or 1=1; INSERT INTO `staff`(`login`,`password`) VALUES ("hack","hack") ;-- "
Результат такой, что я получил лишь выполнение первого запрос. в котором ошибка логина или пароля, а второй запрос INSERT INTO как будто и не выполнялся.

[AlikDex]

Павел: ну я так и пишу что 2 последовательных запроса не работают в этой версии драйвера мускула.
hack" or 1=1; кончается первый запрос с точкой-запятой.

[AlikDex]

Павел: к тому же хтмлспециал чарс с дефолт флагами экранирует двойные ковычки. Именно поэтому не работает инъекция. Обычно люди экранируют стороковые перменные мускула через одиночные кавычки, и на этом построены все инъекции. Т.е. вы грубо говоря наебали систему, но осложнили себе жизнь в дальнейшем.

[Павел]

AlikDex: Прикольно получилось, я думал хоть дырки оставлю в своём коде, а получилось как назло все защищено.

[Павел]

AlikDex: Но, конечный результат после htmlspecialchars не меняет кавычки! И запрос получается таким:

string(164) "SELECT * FROM `СКРОЮ_название`.`staff` WHERE `login`="hack" or 1=1; INSERT INTO `staff`(`login`,`password`) VALUES ("hack","hack") ;-- """

Значит все через union делать для инъекции?

[AlikDex]

Павел: селект и инсерт с унионом не получица наверное. Запросы должны возвращать идентичные поля. Т.е. сами идентичными. Посмотреть ченить через унион можно. Вывести всех юзеров например, если есть ченить типо того. Или вывести в форму редактирования попробовать вв профиле.

[Павел]

AlikDex: А как быть если вывод информации не предполагался в коде, то есть получили через SELECT и сразу же проверка в if и никакого вывода самих данных не происходит.

[AlikDex]

Павел: никак не быть =) honeypot готовите чтоль?

[Павел]

AlikDex: Печаль, свой код и не могу поломать ёмаё. Да нет, просто хотел свой код поломать, чтобы понять где дыры оставил и обезопасить код после изучения.

[AlikDex]

Павел: ну для начала подготовленные выражения начать юзать. Для паролей password_hash и password_verify. запилить csrf и использовать html purifier Для удаления всякого xss говна из текстов. для валидации всяких емейлов юзать filter_var. Зачем заострять внимание на говне 2005 года? все уже давно придумали до тебя.

[Павел]

AlikDex: Подготовленные выражения - это хранимые процедуры в SQL или я не так понял? С password_hash и password_verify возьму на заметку и даже поменяю в своем коде кусок кода с проверкой.
filter_var - пожалуй тоже начну пользоваться вместо регулярок.

[AlikDex]

Павел: php.net/manual/ru/pdo.prepared-statements.php

[Павел]

Не пойму в чем проблема.
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens' in и т.д.

[Павел]

Подготовил запрос через PDO::prepare , при вызове execute() передал массив, и вываливается ошибка эта. Самое интересное что я нашел место в переменных после которой вываливается ошибка и это ни моя вина, а что-то другое. У меня 18 переменных должны связаться в запросе.

[Павел]

14-ть переменных связывается и запрос выполняется, а больше 14-ти не связывается, че за ерунда не пойму.

Answer 1

[Rsa97]

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

Comments

[Павел]

А данный выше запрос , уязвим ?

[Rsa97]

Павел: Да.

[Rsa97]

Павел: Попробуйте в $_POST['name'] передать 'Вася", admin = "yes'
Конечно, это только пример, поля admin в вашей таблице скорее всего нет. Но ведь можно поэкспериментировать и перебрать разные варианты.

[Павел]

Rsa97: Можно узнать конкретно каким выражением в форме, возможно провести инъекцию?
P.S. Проверяю свой код на наличие уязвимостей.

[Rsa97]

Павел: И, кстати, ваш запрос и сам по себе всё порушит. Он заменит значения полей во всех строках таблицы, поскольку нет WHERE.

[Павел]

Rsa97: Забыл написать, запрос не полный, там есть WHERE который отсечен, поскольку весь запрос не было смысла писать. Но возможно к счастью, на выражение 'Вася", admin = "yes' код невосприимчив.

Answer 2

[Алексей Николаев]

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

Comments

[Павел]

Не могу провести инъекцию для такого куска кода:
if( $accounts = $this->mysqli->query("SELECT * FROM `".DB_DB."`.`staff` WHERE `login`=\"$login\"") )

[Павел]

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

Answer 3

[SagePtr]

Зависит от того, откуда берётся переменная $login и обрабатывается ли она предварительно как-нибудь. Хотите гарантированно безопасный запрос - используйте плейсхолдеры. Если по каким-то причинам не можете их использовать - то экранируйте все поступающие в запрос извне переменные.

Comments

[Павел]

Меня не совсем интересует как обезопасить, я не могу разобраться почему не выходит преднамеренная инъекция.
Переменная $login предварительно обрабатывается так:

$login = htmlspecialchars(strip_tags($_POST['Login']));

В форму вставил Вставил выражение:
hack" or 1=1; INSERT INTO `staff`(`login`,`password`) VALUES ("hack","hack") ;-- "
Результат такой, что я получил лишь выполнение первого запрос. в котором ошибка логина или пароля, а второй запросINSERT INTO как будто и не выполнялся.

[SagePtr]

Павел: видимо, потому что htmlspecialchars меняет " на "

[SagePtr]

Павел: пардон, меняет " на "

[Павел]

SagePtr: Нет, как раз этого не происходит, потому что в конечном варианте запрос принимает вид строки:
string(164) "SELECT * FROM `СКРОЮ_название`.`staff` WHERE `login`="hack" or 1=1; INSERT INTO `staff`(`login`,`password`) VALUES ("hack","hack") ;-- """

[SagePtr]

Павел: ещё функция mysqli::query позволяет выполнить только один запрос. Для выполнения нескольких есть отдельно функция mysqli::multi_query

[Павел]

SagePtr: Но UNION никто не отменял ведь, значит получается можно один запрос сделать. только при этом пользоваться UNION?

[SagePtr]

Павел: ну так проверьте и заодно расскажите, получилось или нет

[Павел]

SagePtr: Проверить то можно, вот только результаты запросов не выведутся) Как с этим быть...

[SagePtr]

Павел: Посмотреть по содержимому базы, сработали ли эти запросы или нет. И, естественно, включить вывод на экран ошибок mysql.

Answer 4

[index0h]

Является ли SQL запрос уязвимым к SQL инъекции?

Да. Пример

$login = '"; DROP TABLE `staff`;'

Метод экранирования \" обеспечивает безопасность запроса от SQL инъекции или нет?

Только в случае, если вы экранируете встраиваемые строки. Нынче это делается через плейсхолдеры.

Comments

[Павел]

Значит конкретно мой код и запрос не уязвим, потому что там экранирование строки идет.

[index0h]

Павел Я не вижу, что происходит с $login, посему конкретно приведенный вами код уязвим со всей силы)). Пока не поздно почитайте: php.net/manual/ru/pdo.prepared-statements.php

Answer 5

[Erling]

Используйте подготовленные запросы и избавитесь сразу от многих вопросов по SQL-инъекциям. Поищите более 1-й статьи (обсуждения) по prepared statements (MySQLi || PDO) и в бой.

Answer 6

[Аноним Анонимов]

Конкретно этот запрос уязвим из-за кавычек.

Советую впредь проверять сайт с помощью sqlmap или других инструментов, чтобы найти возможные SQLi. Как вариант, можно сделать онлайн с помощью pentest-tools или METASCAN.