Требуется помощь
Feb. 1st, 2006 10:24 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
romikchefЭтот вопрос для меня настолько важен, что даже пишу в этом журнале.
Вопрос, естетственно, только для тех, кто на этих галерах.
Столкнулся я с большой проблемой. Это всё связано с факом про кавычки, слеши, PHP и Mysql.
Проблема - с определением субъекта прослешивания и окавычивания.
Поясню, почему проблема большая.
Сначала в факе я писал, что достаточно таким образом обработать данные - и всё будет зашибись.
Gотом до меня дошло, что это только строковые литералы можно защитить таким образом, а остальные части запроса надо защищать по-другому.
Сейчас собрался сесть таки переписывать, и столкнулся с вопросом:
Как обобщить тип данных, который требуется прослешивать и окавычивать?
Желательно, определение должно занимать не больше одной строки. Но не в ущерб точности.
Пусть больше. Но лишь бы это было ЧЁТКОЕ, всеобъемлющее определение!
Иначе у меня и вовсе почва уходит из-под ног.
Я-то хотел разделить рекоменации по защите запросов на две части - чёткую и нечёткую.
Чёткая - прослешивание литералов. Нечёткая - всё остальное.
но если нет точного определения для первой части, то и она становится нечёткой!
А выражение "данные", как и "строковый литерал" само по себе никакого смысла не несёт.
Хотел написать "всё, связанное со значением поля", но во-перваых, это криво, а во-вторых, как быть с литералами, не имеющими отношения к полям - SELECT 'aaa';?
http://community.livejournal.com/ru_php/552359.html
Вопрос, естетственно, только для тех, кто на этих галерах.
Столкнулся я с большой проблемой. Это всё связано с факом про кавычки, слеши, PHP и Mysql.
Проблема - с определением субъекта прослешивания и окавычивания.
Поясню, почему проблема большая.
Сначала в факе я писал, что достаточно таким образом обработать данные - и всё будет зашибись.
Gотом до меня дошло, что это только строковые литералы можно защитить таким образом, а остальные части запроса надо защищать по-другому.
Сейчас собрался сесть таки переписывать, и столкнулся с вопросом:
Как обобщить тип данных, который требуется прослешивать и окавычивать?
Желательно, определение должно занимать не больше одной строки. Но не в ущерб точности.
Пусть больше. Но лишь бы это было ЧЁТКОЕ, всеобъемлющее определение!
Иначе у меня и вовсе почва уходит из-под ног.
Я-то хотел разделить рекоменации по защите запросов на две части - чёткую и нечёткую.
Чёткая - прослешивание литералов. Нечёткая - всё остальное.
но если нет точного определения для первой части, то и она становится нечёткой!
А выражение "данные", как и "строковый литерал" само по себе никакого смысла не несёт.
Хотел написать "всё, связанное со значением поля", но во-перваых, это криво, а во-вторых, как быть с литералами, не имеющими отношения к полям - SELECT 'aaa';?
http://community.livejournal.com/ru_php/552359.html
no subject
Date: 2006-02-01 04:37 pm (UTC)Это просто нелогично.
Мы должны составить синтаксически верный запрос, а уж откуда данные пришли - дело десятое.
Я бы тогда уж обозначил весь этот зоопарк, как "всё, что не было hardcoded программистом".
Но здесь, как я уже говорил, другая засада. среди этого "всего" попадаются вещи, которые НЕ НУЖНО прослешивать. Которым это не поможет!
SELECT * FROM table WHERE $field='$value'.
ыц?
пришло извне? пришло
обкавысить можно? НИЗЯ!
как грамотно объяснить юзеру, что первое должно быть результатом выбора из пре-кодед переменных, а второе - подлежит прослеш-обкавыч?
no subject
Date: 2006-02-01 04:56 pm (UTC)Объяснить просто. Имена полей, таблиц, инструкций (ключевые слова), знаки препинания в SQL не являются параметрами. Параметрами могут быть только данные. Например, если ты компилируешь запрос в prepare, ты не можешь оставить плейсхолдеры для полей - только для их значений. Вот и все. Все остальное - параметры (не уверен до конца насчет параметров LIMIT, т.к. это - нестандартная SQL-конструкция, но это частный случай).
Ну а насчет обкавычивания именно параметров, это тоже не очень хорошая идея. Если она в данное время работает на MySQL с любым типом данных, это не гарантирует, что оно будет работать где-то еще, даже, возможно, в будущих версиях MySQL. SQL, все же, строго типизированный язык сам по себе, и неявные преобразования типов в большинстве случаев - скорее прихоть разработчиков.
no subject
Date: 2006-02-01 05:11 pm (UTC)Про остальное я должен подумать.
То есть, у тебя получилось объяснение от противного - ты перечислил всё, что не данные. Остальное, следовательно, надо обрабатывать...
>Ну а насчет обкавычивания именно параметров, это тоже не очень хорошая идея.
то есть, ты предлагаешь мне поностью сменить текущую парадигму фака, в котором написано, что обкавычиваем/слешим мы всё подряд?
Хм.
Надо, блин, пааадумать...
no subject
Date: 2006-02-01 06:00 pm (UTC)пляшем не от категории "данные-не данные", а строго от типа.
если у нас ожидается инт - кастим в инт.
если ожидается строка - кавычим.
всё остальное - ...
опять закавыка получается с определением...
no subject
Date: 2006-02-02 11:09 am (UTC)1. Есть конструкции языка SQL - наименования объектов, ключевые слова, операторы. Эти нельзя ни кавычить, ни слешить, эти - как ёжики, с ними надо осторожно.
2. Все остальное - параметры (данные). По возможности нужно использовать механизм передачи параметров через плейсхолдеры, если это поддерживается базой. Тогда ничего слешить и кавычить не надо, об этом позаботится библиотека доступа к базе, в соответствие с ожидаемым типом параметра (она знает, какому типу принадлежит какой-то параметр, даже если ты сам этого не знаешь, т.к. у нее есть метаданные). Если такого механизма нет, то надо кавычить и слешить все параметры в расчете на то, что она (как MySQL, например) сама разберется с типами и сделает неявное приведение типа, если понадобится.