Я написал следующую функцию, в которую можно передавать запрос, а на выходе получить экранированный запрос.
Экранированы будут только те символы, которым содержатся в $_GET или  $_POST.




Давайте обсудим такой подход... Т.к. если перед каждым запросом делать отдельно mysql_real_escape_string() или intval(), то работы много и можно что-нибудь пропустить. В результате повышается вероятность взлома.

Добавлено @ 21:10 
Для тех, кто не в курсе о чем речь и для чего это делается, читайте тут: http://de.php.net/manual/ru/function.mysql...cape-string.php
Там также описано, как можно легко взламывать скрипты, если не проверять переменные от юзеров.  

при входных данных вида:

функция кажись работать не будет (поскольку заменяются все вхождения "',`")

я бы посоветовал использовать шаблон Table Data Gateway и забыть про sql-код в самих скриптах
вкратце можно почитать здесь: http://www.martinfowler.com/eaaCatalog/gateway.html
 

Что-то я сомневаюсь, что такие входные данные могут быть. 

и все же функция небезопасная
при любом совпадении значения одной из переменных с частью строки запроса (если эта часть содержит спецсимволы) получится ошибка

если влом писать по шлюзу на каждую сущность БД, можно использовать PEAR::DB
функции prepare/execute

Добавлено @ 10:56 
я про PEAR::DB
смайлы отключить забыл...

ничего не при любом. Глюк только при передачи спец. символов может быть. А когда ожидаешь прихода спец. символов, то всегда можно их экранировать ДО передачи в функцию. Часто ли вы передаете в ГЕТ или ПОСТ запросе спец. символы? Ответ: оооооооооооочень редко.

А служебные слова INSERT, SELECT и т.п., все равно не экранируются ведь. Так, что все довольно надежно имхо.

Добавлено @ 11:06 

Не вижу необходимости.. 

хм... тогда я что-то не уловил, зачем нужно повторное экранирование?... 


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



ты про PEAR или про шлюзы данных? 

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

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

Ты говоришь, что от юзера могут прийти спец. символы который не надо экранировать, а моя функция все равно их заэкранирует. Где ты видешь тут проблему? Экранирование происходит только в запросе. И экранируется как раз те спец. символы, которые способны "поломать" запрос. Так, что все правильно.



Я про Pear в данном случае. Про шлюзы данных - я не понял, что ты имел ввиду.

Добавлено @ 16:11 

А она и выполняет. Читай выше. Экранируются только символы  в запросе, которые его могут "поломать". 

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


не говорил я такого...
проблема появляется, когда одна из переменных совпадает с какой-либо частью запроса
например, вряд ли стоит заменять в sql-запросе все кавычки на mysql_real_escape_string('\'');


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

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

Да... вот я и привел функцию, которая могла бы в такой класс войти.




Хм.... вот двойные кавычки. Да... Они могут часто в запросе приходить. Ты уверен, что двойные тоже экранируются? 

ты что... ни в коем случае
иначе смысла писать такие классы - ноль
она же готовый sql-запрос принимает

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


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

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

Добавлено @ 11:24 
Нужно или по отдельности экранировать, что небезопасно или же в моей функции все сразу. 

если ты не экранируешь данные до вызова функции - эта функция может работать неправильно и выдать битый sql-запрос
если ты экранируешь данные до вызова функции - то вызывать ее второй раз нельзя, поскольку данные проэкранируются еще раз и на месте каждой одинарной кавычки получится \\\' 

Не может,  т.к не будет найдено совпадение.




Двойное экранирование невозможно, если пользоваться моей функцией.
  

элементарный пример: $_POST['a'] = " ' " (пробелы только для удобочитаемости)

и вообще, давай определимся - данные из $_GET ($_POST) должны экранироваться до вызова функции, или нет? 

Пример хороший, но практически нереальный. Это исключение. Видимо имеет смысл добавить в функцию соответствующую проверку.
Это лучше, чем экранировать все по одиночке. Еще пример можешь привести?



нет, не должны. Только в функции пусть экранируются.  

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

вообщем, мое личное мнение: метод небезопасный и не универсальный

есть же два чудных варианта: PEAR и шлюзы данных (относительно последнего - есть несколько типовых решений) 

Приведи их!



Ты ошибаешься.


чепуха. Я уже несколько раз показывал, что как раз это более безопасное решение.




а аргументировать ты так и не смог.

 

" ' "
" ',' "
" (' "
" ',`"




сразу становится понятно, что метод безопасен, надежен и универсален...

По моим предположением, если через GET или POST злоумышленник такое отправит, то взлом скрипта не произойдет. Запрос просто не выполнится, что и требуется. Согласен? Где опастность?


На практики же приведенные тобой символы передавать нет никакой необходимости НИКОГДА. Поэтому я, как разработчик, ни с какими ограничениями не сталкиваюсь. Зато уверен, что неэкранированным НИЧЕГО не пройдет. Надежность повышается.

    

А я как то вообще не ломаю себе голову по поводу всего этого...
идем в пхп.ини и ставим magic_quotes=on
И все уже в скрипт попадает "слешованое".
 

экранирует не все. что mysql_escape_string 

Если в БД будет ложится то что приходит от клиента через GET/POST/Cookies data то этого хватит.
В дургих случаях, когда например данные поступают из потока(файла) - согласен, надо использовать свой механизм. 

Блин, да любой нормальный сайт должен поддерживать '. Допустим нужно в БД занести имя компании, а оно выглядит типа

Brother's Company

И все, ошибка. Примеров таких полно. И тебя пользователи просто засыпят письмами.

З.Ы. Не уверен насчет русских сайтов, но на английские точно (у них же ' весьма сильно используется в языке)
 

А оно поддерживается без проблем. 

Кстати, кто-нибудь знает, зачем mysql_real_escape_string экранирует \r\n ?

Из комментариев в манеале:


Если их не квотить запрос может получиться вида:

Т.е. \n\r будут относиться не к тексту, а к запросу, т.е. в базу вставиться единая строка, безе переводов строк..

Я тоже не согласен с таким подходом. Если вызывать эту функцию, то она проэкранирует все без исключения входные параметры, но ведь некоторые параметры могут не использоваться в запросе, тогда их придётся обратно деэкранировать, а это лишняя работа.
ИМХО надо просто писать класс абстракции БД и в него вшивать проверки. Это, конечно, тоже не очень красивый вариант (его сложно грамотно реализовать), но более удобного вариант для пользователя (для пользователя класса \программиста\) и не придумаешь.

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

А по поводу того, что:



Взломщики придумывают всегда самые нереальные входные параметры. Это неоспоримо.

Это вы по отношению к какой функции?

К предложенной WOWA

\правка\
Уф... после бурного НГ внимательность на нуле. =) не считается

Это сообщение отредактировал(а) coyl - 4.1.2007, 00:50

да, это недостаток конечно.. 

Сейчас я думаю, что самым мудрым решеним является создание функций для Инсерта и Апдейта отдельных.

И передавать значения в функции через массив.

типа:



А функция update тогда уже заэкранирует все эти символы. Точно также и с Инсертом.
Кроме того, тут очевидный плюс то, что легче переменные указывать.. Меньше вероятность ошибки, когда через INSERT что-то не в тот столбец  запишешь.

Что вы думаете по этому поводу?

Это уже реализовано в PDO.

Опасность состоит в том, что любая ошибка может повлечь другую ошибку. К примеру при дальнейшем использовании результата ПХП вывалит ошибку, что это неправильный результат, укажет месторасположение скрипта.
Да и, например, если система находится, скажем, в стадии тестирования и вывод ошибок класса ДБ включен, то злоумышленник получит строку запроса, из которой узнает часть структуры базы. Это на первый взгляд кажется не значимым, но любой, кто сталкивался непосредственно с взломом систем, знает, что любая информация может быть полезной в этом деле и что хорошо защищённые системы должны давать минимум информации о своём внутреннем устройстве, естественно, не в ущерб удобности и функциональности.

Ты имеешь ввиду подстановку значений через PDO::prepare() ?




Так, как тут обновить более двух столбцов? Придется ведь имхо составлять новый запрос для этого.

Да.


А ты как хотел?
В конце концов никто не мешает сделать что-то вроде:

так:

Такой способ применяется тут: http://dklab.ru/lib/DbSimple/

Добавлено @ 15:12 
ведь так гораздо удобнее?

Wowa, при условии, что PDO работает также и запрос выглядит нагляднее, ИМХО, при условии, что он "вшит" в систему, DbSimple - не конкурент в принципе...

Кстати в моем фреймворке я так и делаю.
Только еще боле просто.
Каждая таблица - класс наследуемый от базового таблицы, имеющего методы put, get и еще пару-восемь других полезных.
При создании класса таблицы задается имя реальной таблицы.
Так что в итоге все выглядит еще проще и нагляднее.



Функция insert сама разбирает массив, сама делает mysql_escape_string.