Я написал следующую функцию, в которую можно передавать запрос, а на выходе получить экранированный запрос.
Экранированы будут только те символы, которым содержатся в $_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) должны экранироваться до вызова функции, или нет? 

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



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