Зачем prepared statements? Почему не экранирование?

Question

[PO6OT]

Чем обусловлено предпочтение экранирования ввода использованию prepared statements для защиты от SQL-инъекций?
Почему mysql_real_escape_string() небезопасна?

Заранее извиняюсь за каламбур - я не уверен в верности смысла выражения "предпочтение одного другому".

Answer 1

[Losted]

Вручную легко что-нибудь упустить. Заодно Prepared Statement находится в прекомпилированном состоянии (как минимум в java) - это уменьшает время вызова.

Comments

[abcyu]

Везде, где я встречал это понятие, в доке упомянуто было о прекомпиляции.

[PO6OT]

Расскажите мне про минусы экранирования

[Losted]

Как минимум скорость и надежность, этого мало? Вообще плюсы PS=минусы ручного экранирования. Не знаю, как это по-другому можно сказать.

[neol]

Losted: Скорость можно записать в плюсы PS не во всех ситуациях. Если на каждое выражение выполняется только один запрос - это медленнее. Плюс для PS не работает query_cache, что тоже может плохо сказаться на производительности.

В общем PS - это не про скорость, хотя в некоторых случаях будет действительно быстрее.

[PO6OT]

Losted: лично для меня видится один большооой минус prepared statements - очень сложно реализовать а для escape есть готовые функции

[Arekusei]

Вадим Егоров а что вам нужно реализовывать то? Вам мало mysqli_* и PDO?
Надеюсь вы вкурсе что mysql_* устаревший набор функций?

[PO6OT]

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

[Losted]

neol: Ну я тут готов согласиьтся, что на каждый запрос лепить по PS - нет никакого смысла. Идея - в наличие реюзабельного шаблона. Query Cache для PS тоже работает, хоть и с некоторыми ограничениями. Вообще последнее утверждение сильно зависит от используемой БД. например, Оракл умеет реюзать execution plan'ы, если использовался JDBC PreparedStatement. Я, к сожалению, не знаю PHP, так что могу аппелировать только к java.

[PO6OT]

Losted: Приведите пример SQL-инъекции, если я использую такой код (PHP). Разве он не безопасен?:

$name   = $_POST['name'];
$name   = mysql_real_escape_string($name);
$query  = "SELECT phone_number FROM users WHERE name = '$name'";

Если примера инъекции через этот скрипт быть не может, то вопрос решён. Ведь цель моего вопроса - узнать, почему программисты предпочитают экранированию prepared statements, и, если это из-за безопасности, узнать, чем оно небезопасно.

[Losted]

Вадим Егоров: Я не знаю PHP

[Arekusei]

Losted в PHP есть два варианта как могут работать препары.
1) препары шлются на сервер и там подготавливаются к выполнению,
2) препары эмулируются драйвером/екстеншеном пхпшным.
В первом случае всё зависит от бд, во втором серверу шлются всё те же обычные запросы обработанные и проэкраннированные самим екстеншеном/драйвером.

[PO6OT]

Losted: Даже если вы не знаете PHP, код по-моему, вполне понятен)

[Losted]

Вадим Егоров: Я не знаю насколькоо надежен и эффективен метод mysql_real_escape_string (кстати, что я должен буду использовать, если у меня Оракл?). Однако, согласно комментарию выше, он deprecated. Одного этого для меня бы хватило, чтобы стараться его не использовать в своем проекте.

[neol]

Вадим Егоров: И это по-вашему сильно проще, чем

$name = $_POST['name'];
$stmt = $dbh->prepare('SELECT phone_number FROM users WHERE name = :name');
$stmt->bindParam(':name', $name);
$stmt->execute();

? Ну ок.

Приведённый вами фрагмент кода безопасен.

[PO6OT]

neol: ну я почему-то наткнулся не на 4 строчки: https://github.com/colshrapnel/safemysql/blob/mast...

[Losted]

Neoline: При чем тут вообще Линукс и Микрософт? Однако, если сообщество разработчиков ядра Линукс отметит какой-нибудь кусок из ядра как deprecated я предпочту ее не использовать, так как дальнейшая работоспособность его не гарантируется и может вообще пропасть в будущих версиях. Мотивации по установке статуса устаревания могут быть самые разные - от неэффективности до исправлений кривизны архитектуры, которая мешает дальнейшему развитию.

[neol]

Вадим Егоров: А не надо натыкаться, надо читать документацию - php.net/manual/ru/pdo.prepared-statements.php

[PO6OT]

Neoline: в одну строчку свести всё можно)

function query_pre($query, $vars){
  $stmt = $dbh->prepare($query);
  foreach($vars as $i => $value)
    $stmt->bindParam('%'.$i, $value);
  $stmt->execute();
}

[PO6OT]

Neoline: всё может быть :D
а что не так?

[PO6OT]

Neoline: правда забыл return

Answer 2

[sivabur]

1. Дырявий + устаревшая функция которая в последней версии помоему уже удаленна собсвенно один из способов обхода https://exelab.ru/f/index.php?action=vthread&forum...

2.prepared подготовленыи запросы- т. е. один раз а сервак шлется шаблон а потом при каждом новом запросе будут слаться тока данные(в общех чертах).

Вообщем mysql_real_escape_string() колхоз еще тот уже как более 5-ти лет.

Comments

[PO6OT]

колхоз колхозом
что насчёт безопасности?

[sivabur]

Вадим Егоров: Замечание: mysql_real_escape_string() не экранирует символы % и _. Эти знаки являются масками групп символов в операторах MySQL LIKE, GRANT и REVOKE.

Требует открытого соеденения с mysql.

При неправильно сконфигурированой кодировки будет криво работать(уязвиммо).

При magic quotes двойное экранирования и (возможна уязвимость тот я глубоко не копал может и не будет уязвимости).

[PO6OT]

sivabur: если SQL поддерживает что-то вроде \0x10, то можно все символы экранировать таким образом - заменяя символы их кодом

[PO6OT]

sivabur: я так замечал очень много сайтов, на которых вылетают ошибки mysql_* deprecated. Получается их взломать можно в два счёта?

[sivabur]

Вадим Егоров: не в два счета(должны сопасть некоторые условия). Если грамотннно все сделанно в вопросах безопасности то нет.

[PO6OT]

sivabur: ну если мне попалась на глаза ошибка и её не убрали хотя-бы с помощью error_reporting(), не думаю, что может идти речь о какой-то грамотной работе.

Answer 3

[res2001]

Вставлю свои 5 копеек.
Не знаю как с MySQL, а в MS SQL и Oracle prepared statements подставляются в запрос в ядре базы данных, а не в какой-то левой библиотеке, непонятно кем написанной и не известно на сколько криво используемой.
Кому как не самой СУБД лучше всего знать что и как экранировать? К тому же СУБД воспринимает prepared statements именно как параметры запроса, они никогда не смогут быть выполнены.
Как-то так, имхо.

Answer 4

[neol]

Потому что экранирование можно забыть (а если что-то возможно, то это рано или поздно произойдёт).
С prepared statements такой проблемы нет.

PS Забудьте про mysql_real_escape_string, его больше нет. И вообще всех функций mysql_* больше нет.

Comments

[65536]

mysql_RIP

[Arekusei]

Neoline а зачем писать код который будет сыпать E_DEPRECATED после обновления пыха?
И мне вот интересен процент тех кто использует пых ниже 5.3 на хостингах учитывая что он более не сопровождается и security фиксы на него не выходят.

[neol]

Neoline: Всем насрать на пользователей XP, они сами себе злобные буратины. Как и те, кто начал писать новые проекты на PHP 5.3 в 2015 году.

Проверять работоспособность на старых версиях языка конечно нужно, если необходима их поддержка, но тут речь идет не о том. Если использовать mysqli, то ваш код теоретически сможет нормально работать на PHP c 4.1 до 7. Если PDO, то с 5.0 до 7. а если mysql, то в версиях 5.5 и 5.6 будут предупреждения, а в 7 код будет неработоспособен. Чувствуете разницу?

[Arekusei]

Neoline хостинги особенно дешёвые и бесплатные на XP не крутят. Так что непонятно тут это упоминание. Как вы сами же заметили если сидишь на XP, то виртуалку в руки и тебе доступна любая версия пыха. Тестировать на старых версиях пыха нужно только если требование такое есть.
А если разрабатываешь что-то общедоступное то как правило достаточно ограничиться тестированием на тех версиях которые сейчас поддерживаются в момент разработки.

Answer 5

[Алексей Уколов]

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

Comments

[PO6OT]

Но реализация prepared statements намного сложнее escape.
Чем так не угодило простое экранирование?
Мне не интересны плюсы prepared statements. Расскажите мне про минусы экранирования.

[Алексей Уколов]

Какая реализация? В чём сложнее? Или вы теперь PDO переписываете для своего скайнета на php?

[PO6OT]

Алексей Уколов: извините, ошибся
просто наткнулся на вот это и решил, что это единственный способ

Answer 6

[Алексей Скобкин]

У них есть разные плюсы. Например, вы можете использовать их по прямому назначению: подготовить запрос и подставлять разные значения в цикле.
Ну и все функции mysql_* - deprecated.

Comments

[PO6OT]

Про deprecated знаю.
Цель моего вопроса - узнать, почему предпочитают экранированию prepared statements, и, если это из-за безопасности, узнать, почему оно небезопасно.
Ну вот чем небезопасен этот код? Deprecated для меня ничего не значит. Назовите конкретные причины.

$name   = $_POST['name'];
$name   = mysql_real_escape_string($name);
$query  = "SELECT phone_number FROM users WHERE name = '$name'";
$result = mysql_query($query);

[Алексей Скобкин]

Вадим Егоров: Например.