Старый 02.11.2011, 00:17   #11
Demon1X
 
Аватар для Demon1X
 
Регистрация: 10.07.2010
Сообщений: 56
Репутация: 5
По умолчанию

Хотелось бы уточнить такой момент. Когда лучше использовать htmlspecialchars() перед записью данных полученных от пользователя в БД, или каждый раз обрабатывать ею , эти данные когда выводим?

А то когда читал статьи по XSS в инете, многие рекомендуют обрабатывать данные при выводе из БД. Но ведь первый вариант проще т.к. обработка этой функцией будет происходить только один раз, а во втором случае каждый раз при выводе страницы с этими данными.
Demon1X вне форума   Ответить с цитированием
Старый 02.11.2011, 11:39   #12
oRb
 
Аватар для oRb
 
Регистрация: 01.07.2010
Сообщений: 319
Репутация: 138
По умолчанию

Цитата:
Сообщение от Demon1X Посмотреть сообщение
Хотелось бы уточнить такой момент. Когда лучше использовать htmlspecialchars() перед записью данных полученных от пользователя в БД, или каждый раз обрабатывать ею , эти данные когда выводим?

А то когда читал статьи по XSS в инете, многие рекомендуют обрабатывать данные при выводе из БД. Но ведь первый вариант проще т.к. обработка этой функцией будет происходить только один раз, а во втором случае каждый раз при выводе страницы с этими данными.
Данные должны хранится в том виде, в котором они были получены. Пример - выставление счета клиенту в html формате и в plain text'е. В первом варианте нужна обработка через htmlspecialchars, во втором - нет.
__________________
Не оказываю никаких услуг.
I don't provide any services.
oRb вне форума   Ответить с цитированием
Старый 02.11.2011, 17:35   #13
nobody
 
Аватар для nobody
 
Регистрация: 05.07.2010
Сообщений: 176
Репутация: 130
По умолчанию

Собственно данным из базы, как верно подметили доверять нельзя, не только потому что возникнут проблемы если в будущем будет надобность что-то дописать, вот более жесткий пример:
Допустим я имею доступ к бд, да я конечно могу поменять пасс админу/слить и все такое, но ты еще предоставляешь выполнение команд:
Код:
45         $query="SELECT * FROM `main` WHERE `id_dog`='$id_dog'";
61         $ip=$user['ip'];

417        exec("grep $ip blablab-la");
ip у тебя varchar(15), в обычном случае даже есть alter_priv

p.s. это кстати попадает под мой вчерашний вопрос
Цитата:
такой вопрос, как "по-умному" называть уязвимости которые стают доступны при уже некотором повышении прав
__________________
Sad panda
nobody вне форума   Ответить с цитированием
Старый 04.11.2011, 11:28   #14
Demon1X
 
Аватар для Demon1X
 
Регистрация: 10.07.2010
Сообщений: 56
Репутация: 5
По умолчанию

Цитата:
На что нужно рассчитывать в последнюю очередь, так это на конфигурацию серверов. Грамотный код должен быть неуязвим при любом раскладе конфигов.
Советуете все необходимые настройки заранее забивать в конфиг, через ini_set() ?

Цитата:
Сообщение от nobody Посмотреть сообщение
Собственно данным из базы, как верно подметили доверять нельзя, не только потому что возникнут проблемы если в будущем будет надобность что-то дописать, вот более жесткий пример:
Допустим я имею доступ к бд, да я конечно могу поменять пасс админу/слить и все такое, но ты еще предоставляешь выполнение команд:
Код:
45         $query="SELECT * FROM `main` WHERE `id_dog`='$id_dog'";
61         $ip=$user['ip'];

417        exec("grep $ip blablab-la");
ip у тебя varchar(15), в обычном случае даже есть alter_priv
Такой расклад маловероятен, но на всякий случаи прикрутил проверку на валидность ip.

В общем если я вас правильно понял - лучше ставить под сомнение ВСЕ данные пришедшие не только от пользователя, но и от самой БД.

Обрабатывать при выводе в браузер и составление SQL-запросов, все данные которые взяты из полей не только с пользовательской инфой (поля в которые записывается информация полученная от пользователя), но со служебной (данные в которых генерятся самим скриптом или забиваются биллингом). Так?
Demon1X вне форума   Ответить с цитированием
Старый 04.11.2011, 14:48   #15
M@ZAX@KEP
 
Аватар для M@ZAX@KEP
 
Регистрация: 24.07.2010
Сообщений: 139
Репутация: 5
По умолчанию

Цитата:
Советуете все необходимые настройки заранее забивать в конфиг, через ini_set() ?
Это было бы ещё глупее)) Советую код писать так, чтобы в нём не было дырок. А не надеяться на то, что будет выключен вывод ошибок, register_globals, allow_url_include, включен magic_quotes_gpc и грамотно поставлен open_basedir.
M@ZAX@KEP вне форума   Ответить с цитированием
Старый 04.11.2011, 15:38   #16
nobody
 
Аватар для nobody
 
Регистрация: 05.07.2010
Сообщений: 176
Репутация: 130
По умолчанию

Цитата:
Сообщение от Demon1X Посмотреть сообщение
Такой расклад маловероятен, но на всякий случаи прикрутил проверку на валидность ip.

В общем если я вас правильно понял - лучше ставить под сомнение ВСЕ данные пришедшие не только от пользователя, но и от самой БД.

Обрабатывать при выводе в браузер и составление SQL-запросов, все данные которые взяты из полей не только с пользовательской инфой (поля в которые записывается информация полученная от пользователя), но со служебной (данные в которых генерятся самим скриптом или забиваются биллингом). Так?
Ну проверка на валидность это уже лишнее, для ип в базе поле типа bigint(14), на пхп - ip2long/long2ip.

Простой дейстововать по здравой логике, в базе хранить то что передал пользователь в чистом виде, а при выводе в зависимости от типа обрабатывать всякими приведениями к (int) или htmlentities
__________________
Sad panda
nobody вне форума   Ответить с цитированием
Старый 04.11.2011, 16:24   #17
Demon1X
 
Аватар для Demon1X
 
Регистрация: 10.07.2010
Сообщений: 56
Репутация: 5
По умолчанию

Цитата:
Сообщение от M@ZAX@KEP Посмотреть сообщение
Это было бы ещё глупее)) Советую код писать так, чтобы в нём не было дырок. А не надеяться на то, что будет выключен вывод ошибок, register_globals, allow_url_include, включен magic_quotes_gpc и грамотно поставлен open_basedir.
эммм... возможно несколько не корректно сформулировал вопрос))

Стоит ли прописывать такие настройки в конфиге, если ты заведомо пишешь код без дырок?
Demon1X вне форума   Ответить с цитированием
Старый 05.11.2011, 19:17   #18
M@ZAX@KEP
 
Аватар для M@ZAX@KEP
 
Регистрация: 24.07.2010
Сообщений: 139
Репутация: 5
По умолчанию

Demon1X, нет потому что не на всяком хосте можно вот так вот рулить конфигами через ini_set.
M@ZAX@KEP вне форума   Ответить с цитированием
Ответ

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход



Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Перевод: zCarot