Форум PHP

Подскажите когда лучше использовать htmlspecialchars, nl2br, trim и str_replace ? До добавления в MySQL или после?
А то у меня какая-то путаница получается =(

для работы с MySQL ни одна из этих функций не требуется.

Как это не требуется?
Даже в книжке "Самоучитель PHP5" используют htmlspecialchars при разработке гостевой книги.
А где их тогда можно использовать?

>Как это не требуется?
Так. Не требуется.

>Даже в книжке "Самоучитель PHP5" используют htmlspecialchars при разработке гостевой книги.
Как бы по-политкорректнее сказать... Эта книга имеет много плюсов. Доступность изложения неподготовленному читателю, легкость усвоения материала, широкий охват средств языка и сопутствующих инструментов. Начать программировать на php, прочитав её - очень легко. Но и минусы тоже есть. В частности, паттерны обработки данных, применявшиеся авторами на момент написания этой книги, далеки от идеала.

>А где их тогда можно использовать?
Там, где их действия затребованы.

htmlspecialchars - там где нужно преобразовать plain text в html-представление либо подготовить строку значения атрибута к записи в тело тега (т.е. перед выводом в браузер).

nl2br - там, где требуется перед парой CR LF добавить тег <br/>

str_replace - там, где необходимо в строке одну подстроку заменить другой подстрокой

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

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

Можно. Но не нужно. С данными потом работать становится очень трудно.

К сожалению, достаточно часто так действительно делают.
Случай 10% - это признак отсутствия опыта у разработчика.
Случай 90% - слизанный с первого под копирку код.

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

Специально для апологетов паттерна "защитим все параметры сразу и навсегда!" придумана задача 21 в одноименном разделе. Попробуйте решить её чисто. Получится - подолжим дискуссию.

Т.е. получается в базу надо записывать текст таким какой он есть? Вместе с html кодом и спецсимволами ?
А не будут ли слишком большие скрипты?

Приведите пожалуйста пример гостевой книги. Где в ней использовать привиденные выше функции и как лучше реализовать BBcode?

>Приведите пожалуйста пример гостевой книги

В каком смысле?
Написать?

Нет. Просто порядок обработки текста. Какие функции применять до занесения в БД, а какие после. А то тяжело учиться на догадках.

смотрите задачу 21.
http://www.softtime.ru/forum/read.php?id_forum=7&id_theme=38424

<?php   if (!get_magic_quotes_gpc())   {     $name = mysql_escape_string($name);    }  ?>

я только это нашла... этого хватит? ммм?
я б еще trim() добавила... особенно, если БД для авторизации...

этого хватит?
Для чего?

>Для чего?

для безопасной записи в БД...

для безопасной записи в БД

OK. Чем небезопасны пробелы с начала и в конце строки для записи в БД?

>OK. Чем небезопасны пробелы с начала и в конце строки для записи в БД?
Тут нельзя быть столь категоричным.
Большинство ключевых, то есть не-BLOB/TEXT полей (CHAR, VARCHAR например) допускают вольные трансформации окружающих пробелов.

Уязвимости, конечно, нет. Но неустойчивая работа с ключами - налицо.

Большинство ключевых, то есть не-BLOB/TEXT полей (CHAR, VARCHAR например) допускают вольные трансформации окружающих пробелов.
В том-то и дело. Делай-не делай trim() перед записью в какой-нибудь VARCHAR - пробелы в начале и в конце все равно пропадут. Так что лучше не делать, чем делать.

Но неустойчивая работа с ключами - налицо.
Какая?

>>Но неустойчивая работа с ключами - налицо.
>Какая?
посчитайте md5 до внесения и после извлечения из таблицы.
Убедил?

>>Но неустойчивая работа с ключами - налицо.
>Какая?
посчитайте md5 до внесения и после извлечения из таблицы.
Убедил?

посчитайте md5 до внесения и после извлечения из таблицы.
Да это понятное дело. Пробелы удалит сама СУБД. Я имею ввиду какая же неустойчивая работа с ключами, если я не буду использовать trim(). Мы вроде об этом говорим.

>посчитайте md5 до внесения и после извлечения из таблицы.
>Да это понятное дело. Пробелы удалит сама СУБД. Я имею ввиду какая же неустойчивая работа с ключами, если я не буду использовать trim(). Мы вроде об этом говорим.

$login = $_POST['login']; $md5_php = md5(login); $esc_login = mysql_escape_string($login); mysq_query("INSERT INTO users (login) VALUES('$esc_login')"); echo mysql_result(mysq_query("SELECT login FROM users WHERE MD5(login) = '$md5_login'"),0);

Да, действительно.

Да, для строковых параметров хватит.
>я б еще trim() добавила...
Добавьте - это не принципиально, просто иногда требуется оставлять данные именно в том виде, которые ввёл пользователь, особенно если в конце не пробельные символы, а переводы строк.

>Да, для строковых параметров хватит.
как это понять? а для каких не хватит? =)

>>я б еще trim() добавила...
>Добавьте - это не принципиально, просто иногда требуется оставлять данные именно в том виде, которые ввёл пользователь, особенно если в конце не пробельные символы, а переводы строк.

т.е. если я использую <textarea> - лучше не использовать trim()???//

>>Да, для строковых параметров хватит.
>как это понять? а для каких не хватит? =)
Для числовых - SQL-инъекции по числовым параметрам осуществляются без использования кавычек. В случае числовых параметров можно использовать преобразование вида

<?php   $id = intval($id); ?>

>>>я б еще trim() добавила...
>>Добавьте - это не принципиально, просто иногда требуется оставлять данные именно в том
>>виде, которые ввёл пользователь, особенно если в конце не пробельные символы, а
>>переводы строк.
>т.е. если я использую <textarea> - лучше не использовать trim()???//
От ситуации зависит, но лучше не использовать, особенно, если переводы строк при выводе в окно браузера затем заменяются на <br>, например, при помощи функции nl2br().

>>>Да, для строковых параметров хватит.
>>как это понять? а для каких не хватит? =)
>Для числовых - SQL-инъекции по числовым параметрам осуществляются без использования кавычек. В случае числовых параметров можно использовать преобразование вида
>

<?php >  $id = intval($id); >?>

а можно вместо этого поставить проверку is_numeric() ?


>
>>>>я б еще trim() добавила...
>>>Добавьте - это не принципиально, просто иногда требуется оставлять данные именно в том
>>>виде, которые ввёл пользователь, особенно если в конце не пробельные символы, а
>>>переводы строк.
>>т.е. если я использую <textarea> - лучше не использовать trim()???//
>От ситуации зависит, но лучше не использовать, особенно, если переводы строк при выводе в окно браузера затем заменяются на <br>, например, при помощи функции nl2br().
я ее использую. вот небольшая проблема на счет этого:
можно ли чтоб функция заменяла на <br/> или это только вручную? а то в wml ошибку дает

можно вместо этого поставить проверку is_numeric() ?
При условии, что поле точно имеет числовой тип. Просто если новичёк поставит какой-то текстовый (такое, к сожалению, бывает), то можно записать в HEX-виде строку, т.к. HEX-числа вроде 0xFF эта функция пропустит.

можно ли чтоб функция заменяла на <br/>
На <br /> и заменяет. Точнее добавляет перед переводами строк, а не заменяет.

>можно вместо этого поставить проверку is_numeric() ?
>При условии, что поле точно имеет числовой тип. Просто если новичёк поставит какой-то текстовый (такое, к сожалению, бывает), то можно записать в HEX-виде строку, т.к. HEX-числа вроде 0xFF эта функция пропустит.
думаю тип поля поставить у меня хватит ума =)),
но я все равно передумала использовать is_numeric() , спасибо...


>HEX-виде строку, т.к. HEX-числа вроде 0xFF эта функция пропустит.

а если это сюда вставить? то он тем более пропустит в текстовом поле? или я ошибаюсь....

if (!get_magic_quotes_gpc())    {      $name = mysql_escape_string($name);     }

>можно ли чтоб функция заменяла на <br/>
>На <br /> и заменяет. Точнее добавляет перед переводами строк, а не заменяет.
извиняюсь... я решила что она заменяет на <br>, видать у меня ошибка другая..

хмм.. получается что мы используем htmlspecialchars перед выводом в браузер. Это понятно.
Подскажите как тогда реализовать [b][/b] и т.п. функции ? Ведь html не будет отображаться

почему не будет?
если я не ошибаюсь,

htmlspecialchars ничего с [b][/b] не сделает...
после htmlspecialchars заменяй [b] -> <b> и т.д.

>мы используем htmlspecialchars перед выводом в браузер
мы используем перед выводом в браузер htmlspecialchars для получения HTML-кода из plain-текста
После этого над полученным HTML-кодом можно применить BBCODE-преобразование.
Как вы его реализуете - дело ваше. Важно лишь, чтобы оно не допускало построение произвольного кода, ограничиваясь лишь теми формами, которые не создают потенциальных XSS- и JS-уязвимостей.

конечно, может я глупость ляпну... но мне не привыкать... =)

а если записи сжимать,
использовать gzip(), но не сильно (там вроде несолько уровней сжатия),
а после записывать в БД.

это сильно нагрузит сервер? если да, то есть ли разница, если я и так gzip использую...

>Как вы его реализуете - дело ваше. Важно лишь, чтобы оно не допускало построение произвольного кода, ограничиваясь лишь теми формами, которые не создают потенциальных XSS- и JS-уязвимостей.

можно подробнее? или где можно об этом почитать?

и вообще, защита сайта очень важная тема. можно было ВАМ (бывалым) написать какую-нибудь статейку...от XSS, JS и подобных уязвимостей... =)) если не трудно.

а то я даже не знаю что это такое... =)

>Ю.. ограничиваясь лишь теми формами, которые не создают потенциальных XSS- и JS-уязвимостей.
>можно подробнее? или где можно об этом почитать?
например здесь, на форуме.
http://softtime.ru/forum/srchform.php?&name=*XSS*&numberthemes=30&srchwhere=2&logic=1

>и вообще, защита сайта очень важная тема. можно было ВАМ (бывалым) написать какую-нибудь статейку...от XSS, JS и подобных уязвимостей... =)) если не трудно.

Мне? По-моему, это трудная и неблагодарная работа.

>Мне? По-моему, это трудная и неблагодарная работа.

почему же? =) Мы все скажем большоооооооЕ спасибо!!!
и если кто и будет подобную тему поднимать будем давать ссылку на статью...

а то так каждый день одну и ту же тему поднимаем в которых 70% содержит оффтопа и всякого спора...

Статей очень много. И сам факт того, что просят написать еще уже говорит о том, что никому до них дела нет. Иначе бы они давно прочитали и поняли, что такое XSS.

http://phpclub.ru/faq/wakka.php?wakka=XSS

=) с моим то трафиком...


http://softtime.ru/forum/read.php?id_forum=1&id_theme=1511
http://softtime.ru/forum/read.php?id_forum=1&id_theme=31643

вот и все что интересного нашла...

почему нельзя поднять эту тему? http://softtime.ru/forum/read.php?id_forum=1&id_theme=1511

=(((

там кто то обещал выложить в .doc