Слушайте, они же за это вроде как еще и деньги берут.
Ну, как обычно.
Жаль, я хотел бы присутствовать на этом докладе.
Очень беспокоюсь за схватку "искейпинга" с "препаредами" - а вдруг препареды таки победят? Это что ж тогда будет?
Интересно, нет ли у коллеги аккаунта в ЖЖ, например.

> Слушайте, они же за это вроде как еще и деньги берут.

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

А тут человек вроде как, гм, накопил экспу, и хочет ею поделиться. Другой вопрос, что до систематизации, или, например, чтения мануалов - он так и не дошел :)

> Интересно, нет ли у коллеги аккаунта в ЖЖ, например.

http://phorror.livejournal.com
или здесь http://phpclub.ru/talk/threads/%D0%BF%D1%80%D0%BE-%D0%B8%D0%BD%D1%8A%D0%B5%D0%BA%D1%86%D0%B8%D0%B8-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B5%D1%81%D0%BD%D0%BE-%D0%BB%D0%B8.67907/

есть

Круто.
Я просто хотел узнать, а от какого же типа инъекций не защищают prepared statements.

prepared statements работают только с данными.

Стоп, это же моя фраза.
Совершенно верно, prepared statements работают только с данными.
Я бы даже сказал так - к моменту подстановки данных в запрос его разбор уже завершен.
В связи с этим, никакой sql injection невозможен по определению.

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

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

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

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

В любом случае, вопрос был не о решении проблемы, а о её постановке. Пример я привёл :)

Про путь интересно.
Он мне кажется прямым: привожу пример, когда prepared statements не работают, и показываю, как поступать в таких случаях.

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

prepare("SELECT * FROM users WHERE name = $name")
никогда не видел? тогда ты живёшь в идеальном мире.

Видел, конечно.
Но сам такое не пишу - это ужасно же.

на самом деле это не так уж смешно.
как я отметил выше, альтернативу prepare("SELECT * FROM users ORDER BY `$colname`")
придумать трудно.

Главное - не брать этот $colname из данных, полученных от пользователя :)

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

Не, ну при чем здесь пользователи? :)
Мы говорили о запросах.
Конкретно этот являет нам пример случая, когда даже при наличии prepare переменная в запросе является не головотяпством, а необходимостью.

сортировку, кстати, удобнее не в формочку вводить, а гетом передавать.

а формочки не только постом приходят...

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

а злобный хакер здесь при чём? :)
prepare("SELECT * FROM users ORDER BY `$colname`") пишет не хакер, а программист.

при том что injection сам по себе не случается.

и я так пишу. но sql injection не происходит. surprise?

а SQL injection, выполненный при помощи prepared query, я бы, наверное, хотел посмотреть.
+1 :)

С помощью непараметризованной хранимки - за милую душу. Дело-то не в хранимках и не в эскейпах, а в том что ОБЫЧНО в хранимках параметры подставляются отдельно, но есть целая куча народу которая уверена, что если конкатенировать, а потом сделать prepare - то угроза иньекта исчезнет >_>

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

Так типично уводят куки админов (sanitization в админках всегда проще, чем в юзерских частях приложения, поэтому через юзерскую что-то записывается, а потом в каком-нибудь вьювере логов, приделанном сбоку на коленке - исполняется)

Да легко. Формируем запрос из строки, предоставленной пользователем, prepare, execute.
Похоже, товарищ не различает prepared query и binding в них.

> искейпинг нужен для входящих данных

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

> препареды "быстрее"

это, наверное, зависит от реализации?

> запрос из комикса про мальчика Bobby Tables сможет нанести хоть какой-то вред стандартному PHP/MySQL приложению

вот это кстати да. mysql_exec (или как его там) в PHP берёт 1 выражение, то есть буквально тот запрос не прокатит, он сругнётся на ";"

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

А, наверное.

это, наверное, зависит от реализации?

Ну здесь он прав, во-первых, они не быстрее, во-вторых, есть ситуации, в которых они еще и медленнее.

Если запрос выполняется один раз, то prepare+execute будет медленнее, естественно.

Я другое имел в виду - если в колонке распределение значений неравномерно, у prepared query план запроса может получаться хуже.
Но MySQL, вроде, вообще плевать хотел на такие тонкости, он не собирает и не учитывает статистику по колонке.

а биндинга в вашей похапени нет? или это как-то по другому называется?

есть в отдельном модуле по имени mysqli

но нормальный студент до него документацию дочитать не способен?

Да вы что, кто ж документацию-то читает..

и автор мегастатьи "социальная сеть за 15 минут" тоже.

вот так оне и пишуть... http://ru-php.livejournal.com/1528278.html

ну вот, спугнули :(

У меня копия есть, если что: http://dil.livejournal.com/1007678.html

всё ок с записью :)

Access is denied.
You do not have access rights to view this entry.

ну так только для ценителей!
а вы к ним, видимо, не относитесь.

всем спасибо, все свободны (http://blogs.yandex.ru/commentcopy.xml?f=af080e75f83ae3cbd5ee46ad6669ccd0&m=http%3A%2F%2Fru-php.livejournal.com%2F1528278.html%3Fthread%3D22902486&q=K3icY2RgBEIQYAJjNyDJBuY7MjAxwiU5IZJsxalFZalFAko5mWWpWfmlRXmJOXrJ%2BbkMELDjwLLfrAwMjAh9LBiGIkli2siKYSN7WmpqSnxmCoeSmbGpgYWRGapVDJwwcSWQhhBGBiTg5uYINJNT11DPAAwYcJrOpmRqZGRhiWY2O0RUiZ0CkzmUjIzMDQ0tDDDcDRWnyN2cSsbmFhZmlsYmaMZzwSWUuCgwn0vJ0MDE2MTY0MgYzQJuhIwSN2EbWCDizECGG1FMRqgIkBZET21KgmR4iTm3uFhcKTTSwMfV19U90jjcwt2w0CQjMqBAPx3NbxI4lClJEGMvhj8AUOBviQ%3D%3D)

Ох, а он ещё и сегодняшний к тому же!
Красота да и только :)

Но вот вообще я бы банил людей удаляющих свои псты из комьюнити, гы гы

можно вступить в сообщество, и станет видно.

но зачем?

а меня что, оттуда исключили?

Я думаю, препареды мешают "самовыражаться в коде".

И ещё было бы интересно задать товарищу вопрос про вторичную инъекцию..
Это когда данные, первоначально полученные от пользователя, искейпятся и успешно записываются в базу, а потом, когда они берутся обратно из базы - не искейпятся. Вот тут-то Bobby Tables и срабатывает.

это первый пункт.

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

об этом и речь.

php сосёт, mysql сосёт

Ага, а смерть неизбежна.

мы на препейдах получаем ускорение в 100 раз. Но у нас не php и не mysql

да, я тоже замечал что предоплаченные дешевле.
не на 2 порядка, но

чего тру PHP-шники действительно не понимают - это концепции fail early вообще и типов в частности. Помню в ru_php долго обсуждали, как же правильно "искейпить" числа. Договорились, по-моему, до того что к ним надо + 0 приписывать.

там же, блин, приведение типов есть.

4я неделя на питоне
смеюсь с проблем похапе
удивляюсь простоте, гибкости и скорости разработки на питоне

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