Mysql Защита от SQL-инъекций в PHP и MySQL

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

Есть есть, функция выше tep_db_perform она (c) 2000-2001 The Exchange Project.
Сама функция то хорошая и пользоваться удобно, но она с изъяном.
И такой подход перетек в кучу разных проектов, которые сопровождаются и обновляются сегодня. Об этом мало кто задумывается.
Код, с которым, сейчас работаю он весь готовый к инъекциям. :)
 
Приведенная функция занимается именно кодогеренацией, т.е. не просто подставляет значения туда, где можно обойтись prepared statements, а именно генерирует SQL-инструкции. Это уже by design пересечение data/code boundary, и должна сразу загораться лампочка DANGER.
В случае с динамической кодогенерацией на основе входных данных ЕДИНСТВЕННОЕ правильное решение - белый список, о чем в статье Фаната и сказано.
Даже подстановка имен полей - это _уже_ кодогенерация, и, по уму, все известные поля должны быть перечислены (не обязательно в явном виде - например, они могут браться из ActiveRecord-модели или конфигурации table gateway). В случае с полями этим можно _осознанно_ пренебречь, понимая последствия, и ТОЛЬКО имея соответствующие проверки уровнем выше.
 
fixxxer
:) не загрузил.
Я так же вроде сразу и написал, что важно различать ситуации: a) когда от пользователя приходят имена полей и б) когда значения полей.
(мне это понятней чем кодогенерация и динамическая кодогенерация ну и прочая конфигурация table gateway)
Важно потому, что разные инъекции могут возникнуть и нужна разная защита. Без этого не будет осознано.
В статье все это есть и белый список нужен потому как addslashes() уже не хватает, все хорошо, статья мне понравилась.

Я лишь хотел продемонстрировать, что в приведеном практическом примере (от пользователя только значения полей) с insert все будет безопасно и можно обойтись без плейсхолдеров.
А с update нужно применить или плейсхолдер или стандртный 'id=\'' . (int) $id '\'';
А если пойти на прицип и пытаться исправить функцию, делая параметр $parameters - безопасным, она потеряет свою простоту.

Автор, оправдано утверждая что mysql_real_escape_string() -- это миф, создает внекотором роде свой про плейсхолдеры.
 
А где автор статьи утверждает, что нельзя обойтись без плейсхолдеров?
 
Потому, что задачу по безопасности нельзя решать в такой общей постановке как "пересечение границы данных и кода".

eb6.jpg
 
Ну, ну в чем-то он прав.
Действительно, тезис "инъекция - это всего лишь следствие неверно отформатированного SQL" в статье, насколько я понимаю, не формулируется.
Я только недавно к нему пришел.
А рассматриваются только следствия из него.

А функция, конечно - полное говно, насквозь дырявая.
А если пойти на прицип и пытаться исправить функцию, делая параметр $parameters - безопасным, она потеряет свою простоту.
Не потеряет.
Добавить одним параметром белый список - одна строчка.
НУ ИЛИ ХОТЯ БЫ корректно форматировать идентификаторы. Ни в жизнь не поверю, что за 10 лет этот говнокод ни разу не вылетал на именах полей типа desc etc.

При этом размер этой говнофункции можно сократить в два раза просто учтя тот факт, что мускуль прекрасно понимает СЕТ для инсерта
 
Приведенная функция занимается именно кодогеренацией, т.е. не просто подставляет значения туда, где можно обойтись prepared statements, а именно генерирует SQL-инструкции. Это уже by design пересечение data/code boundary, и должна сразу загораться лампочка DANGER.
приведенное в статье решение занимается тем же самым %)
 
Меня вот что бесит, что в популярном WP для якобы безопасности режут текст пользователя (типа стрип_тагс и тому подобное) хотя от дыр это ни разу не спасало, заплатки выходят как и выходили, а вот юзерам всё равно неудобство... Убил бы....

Мне то пофигу, я это дерьмо на свой сайт не поставлю, но есть же и люди которые ставят, и "коменты постить" я там хочу, а не могу...
 
Vladson это дерьмо прекрасно решает проблему "сделать визитку", причем дизайнер и верстальщик могут спокойно делать сайты на нем без участия программистов.
Поэтому это дерьмо вовсе не дерьмо :)
 
Absinthe
Это бесит больше всего, все думают как вы, ставят, мне (как посетителю) куча неудобств... Вообще запретил бы законодательно ставить этот хлам, реально хуже цензуры, пишешь коммент, отправляешь, а там пол поста вырезано типа для безопасности...
 
Кстати да.
Доклад на конфе, я надеюсь, будет сильно понятнее статьи. Всё разложит по полочкам.
 
Доклад на конфе, я надеюсь, будет сильно понятнее статьи. Всё разложит по полочкам.
Я думаю, что группа людей, которая не умеет работать с запросами, и группа тех, кто идет на конференцию разработчиков за 5тр не пересекаются.
 
Absinthe
Ага, и лучше зал выбирать где поинтереснее и народу поменьше, так больше шансов, что будет что-то интересное, а не "размазывание" how-to для всех.
 
Absinthe
Ага, и лучше зал выбирать где поинтереснее и народу поменьше, так больше шансов, что будет что-то интересное, а не "размазывание" how-to для всех.
ходят слухи, что самое интересное на кофебрейках =)
посмотрим...
 
Redjik
ну да, когда есть возможность пообщаться один на один и задать конкретные вопросы.
 
Поэтому всегда недоумевал, зачем люди покупают видео с конференций :D
С видео не поговоришь.
 
Я думаю, что группа людей, которая не умеет работать с запросами, и группа тех, кто идет на конференцию разработчиков за 5тр не пересекаются.
Ну, во-первых, 5 т.р. = это не такие прям деньги. Многие студии посылают своих студентов.
Все то же самое можно сказать и про мастерклассы по свинксу, например.

Во-вторых, группа людей, которые думают, что умеют работать с запросами, не слишком пересекается с группой тех, которые умеют
 
ну вообще не 5тр, а 8,5 с учетом мастер классов
+ 10-15 к на перелет (ну не одни же москвичи идут)
 
Разве возможна инъекция если для всех переменных запроса используется addslashes??? Мне кажется никак не возможно.
 
Сверху