Возможна ли sql инъекция?

Question

[Карлиндоу Мэрлифи]

$string = 'любой текст для проверки инъекции';
  $string = trim($string);
  $string = mysql_escape_string($string);
  $string = htmlspecialchars($string);
  mysql_query('INSERT INTO `test` (`inject`) VALUES ("'.$string .'")');

Лично я сам проверял по разному, но всё удачно вставляет, то есть без ошибок

Comments

[DevMan]

кто-то бесконечно застрял.

[Everything_is_bad]

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

[Rsa97]

Как оно там живётся, в нулевых годах? А у нас в двадцатых все уже давно перешли на подготовленные выражения с плейсхолдерами.

[Михаил Ливач]

если отвлечься от других комментариев ( авторы которых, безусловно, правы), то не очень разумно делать htmlspecialchars() после mysql_escape_string(). Если в этом и был какой-то смысл, то надо бы поменять вызовы местами.

[Карлиндоу Мэрлифи]

Rsa97, мне просто нужно понять, возможно ли через этот конкретный пример провести sql инъекцию или нет.
Прошлое ворошу

[Everything_is_bad]

Карлиндоу Мэрлифи, дык смысла даже нет, "закопайте стюардессу"

[Adamos]

Михаил Ливач, htmlspecialchars рядом с SQL выполняет только одну функцию - сообщает изучающему код, что его писал ламер, не понимающий, что он делает и зачем. Независимо от того, до или после ;)

[Виктор Кожухарь]

Карлиндоу Мэрлифи, Вам тогда надо не сюда, а в древние форумы профессионалов по безопасности, где и обнаруживали проблемы.
У меня подход к безопасности следующий:
- Всегда брать сторонние проверенные решения. Там люди собаку съели на безопасности, не чета мне (и 90% программистам), занимающихся перекладыванием json или данных из форм в базу и обратно через тонкий слой элементарной логики.
- Если я где-то в проверенных источниках услышу, что решение небезопасно, я даже особо вдаваться в подробности не буду, просто прекращу этим пользоваться. Упрямство и завышенный ЧСВ программистов часто приводят к утечкам, о которых потом говорят в новостях.

Поэтому, тут вам и примеров-то никто не даёт, потому что все те, кто зарабатывают деньги при помощи написания кода, уже забыли много лет назад о mysql_escape_string и mysql_query)

[Карлиндоу Мэрлифи]

Виктор Кожухарь, пожалуй ты прав

Answer 1

[Ипатьев]

Нет.

Comments

[Карлиндоу Мэрлифи]

верный ответ, при условии кодировки UTF-8

Answer 2

[nokimaro]

Возможна.

Почему не стоит использовать mysql_escape_string
https://www.php.net/mysql_escape_string

Warning
This function was deprecated in PHP 4.3.0

https://www.gosecure.it/blog/art/483/sec/mysql_esc...

Не хотите SQL-инъекций используйте подготовленные выражения (prepared statements)
https://www.php.net/manual/en/mysqli.quickstart.pr...

а был бы с нами FanatPHP он бы ещё дал ссылку почитать https://phpfaq.ru/mysql/slashes

Comments

[nokimaro]

Если легаси, то хотя бы вместо mysql_escape_string -> mysql_real_escape_string

Answer 3

[rPman]

почти наверняка будут глюки при использовании utf8 или любой другой мультибайтовой кодировки, и формировании строки с неправильной комбинацией символов, так как mysql_escape_string не будет их считать опасными (она вообще только для однобайтовых кодировок).

Чтобы воспользоваться уязвимостью нужно серьезно зарыться в исходники php или mysql и понимать как обрабатываются ими мультибайтовые кодировки.

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

Comments

[Карлиндоу Мэрлифи]

если всё настолько сложно, значит очень вряд ли использовалась эта уязвимость

[rPman]

Карлиндоу Мэрлифи, очень глупо надеяться на это

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

[ThunderCat]

Карлиндоу Мэрлифи,

если всё настолько сложно, значит очень вряд ли использовалась эта уязвимость

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

[Vitsliputsli]

Карлиндоу Мэрлифи,

если всё настолько сложно, значит очень вряд ли использовалась эта уязвимость

Сложно искать новые уязвимости, но если она найдена, то несложно проверить какой-либо сервис на устойчивость к ней. Если уязвимость не описана в публичном пространстве, это не значит, что она неизвестна в других кругах.
Тем более, что This function was deprecated in PHP 4.3.0, а значит ее давно никто ни на какие уязвимости не проверяет.

[Ипатьев]

При использовании utf8 не будет

[Карлиндоу Мэрлифи]

Ипатьев, я тоже в этом убедился)

[rPman]

Карлиндоу Мэрлифи, мне интересно, какие тесты вы провели, чтобы в этом убедиться?

[Карлиндоу Мэрлифи]

rPman, самое главное в этой инъекции это вставить двойную кавычку в строку, чтоб она такой же попала в sql запрос, чтоб модифицировать его.
Пробовал различными вариантами вставить эти двойные кавычки, всякие символы ASCII char и другое, не помню уже

[rPman]

Карлиндоу Мэрлифи, символ ковычки должен быть частью мультибайтового символа utf8, ее декодирует mysql_escape_string так будто это однобайтовая кодировка, а mysql по уму должна принять utf8, если такова настроена в базе данных.

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

простыми подстановками валидных строк тут не обойдется