MySQL escaped_strings VS.Параметризованные запросы

Question

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

У меня есть существующая CMS на базе PHP / MySQL, в которую вводятся ВСЕ (чекбоксы)и переключатели) подчиняются real_escape_string.Существует раздел администратора, доступный по зашифрованному паролю sha1 и соответствующему имени пользователя, где небольшая (3) группа доверенных лиц может обновлять контент (tinyMCE), загружать фотографии и т. Д. Чрезвычайно мало времени.Ни один из моих запросов не параметризован, но выполняется только после экранирования.

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

Мой хост частный, с очень хорошей записью.

При прочих равных условиях, насколько я защищен?

Answer 1

mysql_real_escape_string действительно не немедленно защищает вас от атак SQL-инъекций.Недавно я помогал разработчику небольшого сайта, который думал, что он безопасен для моих звонков mysql_real_escape_string на всех входах, но все же получил pwn'd.В его случае он ожидал, что переменная (через строку GET) будет целым числом, но не проверяла ее как таковую.Затем злоумышленники использовали это поле идентификатора для создания пользовательских запросов и получения доступа к его всей базе данных .

Мораль этой истории?Утвердить, подтвердить, подтвердить.Вы должны предположить, что каждый возможный фрагмент данных, поступающих извне (даже если вы заполняете <input type="hidden">), является попыткой обойти меры безопасности.Здесь полезно использовать такие инфраструктуры, как Codeigniter и т. Д., Поскольку в них встроены компоненты проверки правильности. Если вы хотите все сделать самостоятельно, просто будьте осторожны и проверьте все входные переменные.

Answer 2

Я бы лучше использовал параметризованные / подготовленные операторы. По сравнению с простым экранированием ввода, они позволяют вам указать тип, который удобен (например, вам не нужно преобразовывать значения даты и времени в специфичный для сервера формат), а также устраняет неоднозначность при обработке ошибок преобразования различными RDMS. Например, запрос SELECT * FROM table1 WHERE int_field='aaa' (int_field is integer) возвращает записи с int_field, равным 0 в Mysql, вызывает ошибку в Oracle и SQLServer и возвращает пустой набор в SQlite