К сожалению не нашел в нете подробно об этом.
Знаю что \  и '  а недавно заинтересовало, является ли } (фигурная скобка) опасным символом? Просто в моем движке он никак не экранируется/кодируется, а ведь есть запросы типа 

И вообще какие еще символы нужно преобразовывать?

Это сообщение отредактировал(а) anurbol - 10.5.2010, 15:12

Опасных символов нет вообще. Ты правда считаешь, что это вопрос "для профи"?

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

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

чтобы этого не происходило было введено простое правило экранирования служебных символов. (служебных, а не опасных!).
а чтобы лень программиста вообще ничем не тревожить были придуманы методы экранировки то что называется in one click, в данном случае в одну функцию. достаточно пропустить данные через mysql_real_escape_string($data); и всё заэкранируется где надо и как надо

про mysql_real_escape_string знаю давно, но мой использует не его, а просто во всех входящих $POST данных, ' и & перерабатывает в html сущности. Просто как бы хотел поинтересоваться у профи,  является ли { опасным (служебным если хотите) символом, mysql_real_escape_string его не обрабатывает.

Добавлено через 1 минуту и 2 секунды
просто где то давно об этом прочитал мимолетом, не обратил внимание, не знаю может то было просто мнение какого нибудь дилетанта на форуме. 

В приведенном вами примере при наличии данной строки в двойных кавычках php подставит переменную и соответственно убьёт символы фигурных скобок... непонятно в чем сложности? mysql эти скобки по барабану вроде как

— ты превращаешь код в полное дерьмо.

конечно, задать вопрос - "зачем?", бессмысленно?

сам посуди - пользователь вводил некий текст, который содержал кавычки. ты его переписываешь в хтмл-сущности. ладно, для отображения в некоем хтмл-теле страницы оно сойдёт. но если был ввод шаблона поиска? или данные в последствии будут отданы в качестве ленты куда-то ещё?
к примеру, человек вводит ... ООО "ГлавСтрой" .... ты его преобразуешь в ООО &quote;Главстрой, найдёт ли пользователь поиском этот текст?



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

Спасибо, что прояснили ситуацию, а насчет поиска, можно делать htmlspecialchars_decode и все.

— серьёзно?

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

и что я сегодня такой добрый?

anurbol, у языка SQL, как и языка HTML, есть свои правила. Которые нужно соблюдать при работе с этими языками. Нет общих правил "на все случаи жизни", которыми можно разом "заткнуть все дыры и там, и там".

Аналогия IRL: перед едой принято мыть руки с мылом, перед походом в театр принято чистить ботинки обувным кремом. Как выглядит человек, трущий руки смесью мыла с обувным кремом ("чтобы пойти в театр, а там поесть") - нелепо, правда? Но именно так выглядит со стороны "преобразование спецсимволов HTML в сущности во всех входящих данных", особенно если это позиционируется как "защита от иньекций" (к которым оно никаким боком).

Настоятельная просьба внимательно и вдумчиво прочитать PHP FAQ:  \"Кавычки \". Cоставление запросов, слеши, SQL Injection. От начала до конца.

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

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


В файле header.php (который подключается к абсолютно всем файлам) 
есть следующяя обработка



Ну а вот собственно сама функция.


Так вот, встает вопрос, неужели этого недостаточно, и все равно надо использовать mysql_real_escape_string() ? 
Раньше кстати я и обрабатывал все данные с ее помощью, а числовые с помощью intval или даже round(floatval($var),4)

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

Помогите!! Где я не прав??

Добавлено через 13 минут и 14 секунд
может просто 


переделать в
  
и все??

Это сообщение отредактировал(а) anurbol - 11.5.2010, 14:33

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

то есть в примитивном идеале, обработка выглядит так:



всё, ничего больше на входе с переменными происходить не должно. в итоге ты точно будешь знать, что у тебя есть переменная $_REQUEST['some_var'], которая не будет случайно отсутствовать в коде или иметь не ожидаемый тип

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

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

1) В нежелании разобраться, что делает и для чего нужна ф-ция mysql_real_escape_string, а что и для чего - htmlspecialchars;
2) В нежелании внимательно прочитать ссылку.

ну в вашем случае я бы еще исключил $_REQUEST в пользу $_GET $_POST