Форум PHP

Для обнаружения и замены символов <, >, ", ', $, ` на html-сущности я использовал функции htmlspecialchars(); и str_replace(); , но мне сказали, что это примитивно и опасно, т.к. пользователь может ввести спецсимволы не только в ascII, но и например в HEX. Вопрос: как защититься более эффективно, обнаружив и заменив ВСЕ вышеперечисленные спецсимволы в переменных, полученных от юзверя?

Применять htmlspecialchars() непосредственно перед выводом в поток браузера.

Символы "$", и "`" нет необходимости приводить к ampersand-encoding представлениям. htmlspecialchars() этого и не делает. А вот Вы забыли, собственно, символ "&" (ampersand).

и например в HEX
Не знаю точно, что они имели ввиду. Если HEX-представление для SQL-запроса вроде 0x6A65657A, то так ввести не получится, если строка обрамлена кавычками. Если не обрамлена, то это баг, позволящий в большинстве случаев произвести взлом. Либо не экранируются бекслеши, что тоже является серьезным багом.

А вообще да, htmlspecialchars() нужно применять на выходе.

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

Так никогда не надо делать.

то есть перед записью в базу применяем mysql_escape_string(); (кстати, ` экранирует?) а после выборки уже str_replace(); и htmlspecialchars(); верно?

перед записью в базу применяем mysql_escape_string()
Да. Только не забывайте правильно принимать данные. Если включен magic_quotes_gpc, то бекслеши удвоятся. Нужно удалять бекслеши, поставленные magic_quotes_gpc.

кстати, ` экранирует?
Нет.

после выборки уже str_replace()
Для каких целей?

А так верно.

Кавычки в запросах я применяю всегда =)

str_replace(); для замены ' и $. А ` значит придется заменять ДО записи в базу? Хотя если BBcode перед записью обрабатывать... че то не выйдет... Совсем запутался сорри=)

str_replace(); для замены ' и $
А зачем их заменять?

У функции htmlspecialchars() вторым аргументом можно указывать режим.

<?php echo(htmlspecialchars("  '   ", ENT_QUOTES)); ?>

Поэтому если вдруг значение параметра value в HTML-теге "input" обрамлено одинарными кавычками, то перед этим нужен именно режим ENT_QUOTES.

А ` значит придется заменять ДО записи в базу?
А заменять-то зачем вообще?

Хотя если BBcode перед записью обрабатывать
Тогда придется возиться с обратной обработкой HTML-тегов в bb-теги при редактировании.

Мда... С htmlspecialchars(); понятно, а вот в запросах я использую так же и `, поэтому избавляюсь от нее. А вообще, если не трудно, можно порядок действий для ПОЛНОСТЬЮ безопасной записи и вывода с учетом BBcode модуля? Что то в голове никак не уложится:)

Ну вот, рабочий день окончен, щас попробую систематизировать полученные знания:)
Значит
1. Экранируем кавычки;
2. Заменяем `;
3. Пишем в базу.
После выборки производим замену htmlspecialchars(); и выводим результат.
А вот BBcode что то никак не укладывается. Только перед выводом- что существенно замедлит работу скрипта!

Насчет безопасности вот почитайте:
http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=40528
http://softtime.ru/forum/read.php?id_forum=1&id_theme=37378
http://softtime.ru/forum/read.php?id_forum=1&id_theme=37543
http://softtime.ru/forum/read.php?id_forum=1&id_theme=33322
http://softtime.ru/forum/read.php?id_forum=1&id_theme=28504

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

2. Заменяем `;
с какой целью?

Спасибо, буду разбираться. Trianon, из-за того, что ` используется в запросах к БД.

Вот я, например, знаю, что в запросах к БД используется слово select.
А применив слово delete (или, о ужас, слово drop) можно вообще таблицу убить.
И что? Людям теперь словами select, delete и drop пользоваться нельзя?
А как же тогда то, что я сейчас написал, прошло?
А как же Вы смогли изобразить этот символ ` в своей реплике?

<?php $query="SELECT * FROM `table` WHERE `nick`='$nick'"; ?>

$nick="aaa' OR `nick`='admin"; как Вам такое значение?
В одной из вышеприведенных тем была Ваша реплика о безопасности с такой фразой: "...С
программным
исключением
возможности
подключения
файлов из
целевой папки в
поток кода..."
1) Как это делается?
2) Что допустимо и что не допустимо в сценарии, чтобы этого избежать?

P.S. Кажется, начинаю понимать:
главное- экранирован ' , а ` не опасен, т.к. закрыт после имени столбца=)
Ну, с прогрессом меня;)

>

<?php >$query="SELECT * FROM `table` WHERE `nick`='$nick'"; >?>

>$nick="aaa' OR `nick`='admin"; как Вам такое значение?

А никак. Здесь Вы играете незаэкранированным символом ' апостроф, а вовсе не символом ` обратная косая кавычка.

>В одной из вышеприведенных тем была Ваша реплика о безопасности с такой фразой: "...С
>программным исключением возможности подключения файлов из целевой папки в поток кода..."
>1) Как это делается?
например, не применять операторы подключения кода (include / include_once / require / require_once) - вообще. Или хотя бы не применять их с параметрами, в которых фигурируют входные аргументы.

Ограничить загрузку файлов пользователя определенными папками.
Сохранять файлы под собственными именами.
Запретить выдачу апачем файлов из этих папок с произвольными MIME-типами
Запретить интерпретацию php в этих папках.
и т.д.


>2) Что допустимо и что не допустимо в сценарии, чтобы этого избежать?
В общем случае - ничего не допустимо. Всё что допустимо - допустимо в индивидуальном порядке.

Многое для меня прояснилось в этом вопросе. Но есть еще непонятки: mysql_real_escape_string это та же mysql_escape_string с расширенной функциональностью или она применяется специфически?
Может, лучше применить именно mysql_real_escape_string ?
И еще- как же все таки с ВВ кодами? Если Вы рекомендуете прописать htmlspecialchars(); именно на выходе, то придется делать обработку ПОСЛЕ ее вызова, а т.к. будут использованы regexp'ы, это существенно замедлит вывод страницы. Как обычно поступают в подобных случаях? Подскажите, опыта маловато....

mysql_real_escape_string() имеет смысл применять при работе с некоторыми особыми многобайтовыми кодировками, где какие-то символы состоят из байтов, которые будут экранированы обычной mysql_escape_string().

Что касается bbCode: да, надо преобразовывать теги перед выводом.
Но это не существенно замедлит генерацию страницы, если, конечно, RegEx написаны грамотно.

Вывод из всего вышесказаного:

<?php if(!empty(trim($_POST['a']))) { if(get_magic_quotes_gpc()) $_POST['a']=stripslashes($_POST['a']); $into_query=mysql_escape_string($_POST['a']); //запрос INSERT с записью $into_query } ?>

Вывод информации

<?php  //данные из таблицы считаны в $a $a=htmlspecialchars(stripslashes($a)); //функция MyTags($val) определена ранее, производит обработку []-тэгов $a=MyTags($a); echo $a; ?>

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

А почему бы не преобозовать BB при добавлении в БД?

А зачем ? Я лично вообще сторонник того,чтобы инфа хранилась как есть,без искажений.А уж при выводе или др.использовании делай с ней что хошь...А то потом вылазят всякие баги типа при выводе обрезанного анонса новости получишь не вышел новый автомобиль "Лада"...,а вышел новый автомобиль "Лада&quo...

Или к примеру у меня тэг[mail]...[/mail] заменяется на ссылку <a href="mailto.php?id= И вдруг мне понадобилось файл mailto.php перенести из главного каталога в каталог ext.Во ВСЕХ сообщениях останется некорректная ссылка и для норм.работы мне придется менять ВСЕ сообщения,вместо того,чтобы изменить ОДНУ строку в файле обработки bb-кода на выходе...То же со смайлами...

Poison, при обработке htmlspecialchars(); перед выхлопом сообщение с тэгами превратится в пособие по HTML для новичков...
Ralph, действительно, я об этом и не подумал! Изменения в обработке не затронут сами сообщения)
Вобщем, все понятно, все работает на ура, спасибо всем, кто принял участие!

$a=htmlspecialchars(stripslashes($a));
Уберите stripslashes()