Фильтрация данных?

Question

[Sasha333]

Понимаю, что вопрос уже объезжен вдоль и поперек, но тем ни менее. Везде есть расхождения кто рекомендует на вводе в бд фильтровать, кто рекомендует хранить обе версии (safe / unfiltered), кто-то рекомендует только выводе фильтровать + кэш.
Хотел бы узнать верный метод с учётом того, что необходимо отфильтровать такие данные:
1. Логин / пароль, вообще есть ли смысл фильтровать пароль кроме как htmlspecialchars, так-как по сути я нигде вывод ответа его не предоставляю, то есть пароль проверяется функцией password_verify.
2. Сайт является мониторингом игровых серверов, информация обновляется раз в минуту, то же название игровых серверов может содержать различные спецсимволы которые хотелось бы показывать гостям сайта, но и не допустить xss атак.

p.s. Как уже выше отметил, информация обновляется раз в минуту, по этому кэширование на 1 минуту всего, будет ли адекватной нагрузка на ресурсы при фильтрации на выводе даже с учётом кэширования?
Проект делаю как учебный, фреймворки не использую.
Мое мнение, что всё таки надо делать минимальную фильтрацию где это необходимо, то есть например при регистрации через preg_match разрешить в логин и имя только a-zа-яё0-9, email через встроенный filter_var($email, FILTER_VALIDATE_EMAIL), пароль htmlspecialchars для перестраховки. Где я зарание знаю какой тип данных должен получить проводить по маске в аналогии как описал для имени и логина.

Comments

[FanatPHP]

пароль htmlspecialchars для перестраховки - серьёзно? Вот прямо после всего того что сам же выше написал?

Answer 1

[Сергей delphinpro]

пароль htmlspecialchars для перестраховки

зачем?
htmlspecialchars кодирует служебные символы html. Зачем ее применять для пароля?
И вообще, пароль у вас никогда нигде не хранится в открытом виде, только его хеш и то внутри системы.

минимальную фильтрацию где это необходимо

верное направление мысли.

Необходимо в двух местах:
1. запись базу
2. вывод на страницу

Чтобы защититься от sql-injection при записи, используйте подготовленные запросы.
Чтобы не сломать верстку при выводе данных — используйте htmlspecialchars при рендере страницы. А лучше возьмите шаблонизатор. Они все по умолчанию эскейпят вывод.

разрешить в логин и имя только a-zа-яё0-9

Это уже не фильтрация, а валидация данных, к безопасности особого отношения не имеет и выполняется в других местах приложения.
Простой пример. Пользователь отправил форму.
Вы первым делом сделаете проверку всех полей на допустимые значения, на заполненность и т.д., и если что вернете посетителя обратно на форму с указанием ошибки. Данные здесь не изменяются.
Если все в порядке, вы будете писать эти данные в базу. Как я уже написал, используя подготовленный запрос. Опять же, ничего менять в них не требуется.
Потом, вы будете эту информацию где-то выводить на странице. Вот здесь уже, перед выводом, вы прогоните все через htmlspecialchars, возможно какие-то еще корректировки сделаете.

Но, опять же вы пишете про универсальную фильтрацию на все случаи. Так не бывает.
Если вы ожидаете во входных данных исключительно текст, то можно, например, смело резать все теги перед записью в базу. А если вы получаете их из визуального редактора, с разметкой, то резать теги уже не нужно.

Comments

[Sasha333]

Спасибо, много вопросов закрыли очень развернуто и доступно. Хотел бы услышать ещё есть ли смысл в кэшировании например при обращении к странице если время жизни кэша 1 минута? Или это не имеет смысла при минимальной посещаемости сайта например в 5000 хостов в сутки и например при каком-то не сильно мощном флуде?

Моя логика такова, что действительно при небольшом кол-ве юзеров онлайн кэширование имеет место быть только в моментах фронта например img/js, но не поможет ли мне кэширование снизить значительно нагрузку если зловредный посетитель сайта захочет сделать флуд этой страницы, то при каждом обновлении её будет происходить эта самая фильтрация, которая могла бы выполниться лишь раз в минуту и отдаваться как статическая информация html?

[Сергей delphinpro]

Sasha333, для грубого примера 5000 уников сгенерят полляма хитов в сутки. Это около 350 обращений в минуту или 5 в секунду. Если у вас есть тяжелые запросы к базе, можно их кешировать, в противном случае, как уже сказали, не стоит решать проблему, которой нет.

Answer 2

[FanatPHP]

Ты как и все пхпшники путаешь валидацию и форматирование данных.

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

Все остальное - это валидация. Делается по желанию. Не обязательно, но рекомендуется.
К безопасности отношения не имеет.
Просто чтобы программа работаела логичнее и предсказуемее.

Про кэширование вообще забудь, это ты наслушался дуремаров-теоретиков, которые сайт у мамки на ноутбуке видели два раза в жизни.

Comments

[Sanes]

Тоже путаешь?

[Sasha333]

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

[FanatPHP]

Какую нагрузку? У тебя есть нагрузка? Нету. Вот и расслабься.
С чего ты взял что фильтрация создает хоть какую-то нагрузку? Со слов каких-то незнаек?

[Sasha333]

FanatPHP, я возможно неверно выразился в своем вопросе, а суть его в том, что при htmlspecialcharts на вывод всей информации из бд не будет ли высокой нагрузки на ресурсы например при флуде. Ясно что при 10 хостах одновременно нет смысла даже заморачиваться над такими вопросами, но как выше упомянул при флуде в теории кэширование отрубит все запросы до 1 в минуту на страницу. Вы же в агрессивном тоне отвечаете по поводу кэширования, мне интересно чем аргументируется Ваша позиция.

[FanatPHP]

позиция аргументируется тем, что ты вообще никакого представления не имеешь о таких вещах как нагрузка, фильтрация, кэширование, флуд - это для тебя абстрактные понятия, которые ты наделяешь выдуманными свойствами
агрессивность тона вызвана только тем фактом, что никакой нагрузки "htmlspecialcharts" не создаёт. Вообще.
Я на спор найду 10 мест в твоем нубском говнокоде, которые создают нагрузку в 1000 раз большую, чем ту, которую в теории может создать эта несчастная строковая функция. Но реальные проблемы тебя же не волнуют. - тебе подавай "фильтрацию", которая - ах! просто убьёт сервак. И ты ходишь теперь всех донимаешь - решите мне проблемы которых у меня никогда в жизни не будет, но мне про них какой-то идиот в уши надул и я теперь спать не могу, мне флуды кругом мерещатся!

[FanatPHP]

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

[Сергей delphinpro]

Sasha333, Прислушайтесь к Фанату. Он пишет резко, но почти всегда по делу.

Answer 3

[microbot]

1. Можно сделать хэндлер для обработки входящих запросов и на нем все post и get данные проверить.
2. Получать, хранить и выводить данные можно как угодно, только нужно придерживаться нескольких принципов. Получаешь - обрабатывать (например: preg_replace('/[^\d]/', '', $string) - убираешь все, кроме цифр). Если в БД пишешь, то используешь экранирование спец. символов SQL - mysqli_real_escape_string($string). Для вывода на страницу всегда htmlspecialchars($string).
3. Вообще, можно скачать фреймворк какой-нибудь и посмотреть, как у них устроены подобные валидации, фильтрации и экранирования. Laravel, Yii, CodeIgniter, Symphony и т.к.

Comments

[FanatPHP]

послушай, зачем ты питаешься писать ответ по теме, в которой ничего не смыслишь?
ну ерунду же пишешь.
экранирование спец. символов от инъекций не защищает
чтобы изучить "какой-нибудь фреймворк" надо несколько месяцев
ты тоже путаешься между валидацией и защитой
а главное твой "хендлер" - это самый ад. в пхп уже был такой, назывался "волшебные кавычки". Их выпилили, после того как весь мир стал показывать пальцем.

[microbot]

FanatPHP, отклоняешь - предлагай, а в нашем случае: "Просвещай")

[FanatPHP]

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

[AUser0]

microbot, да не обращай внимания, он просто не умеет готовить mysql_real_escape_string().

Answer 4

[Антон Шаманов]

про sql-инъекции почитай, если у тебя хотя бы 1000 обращений в минуту, то конечно кеш имеет смысл, кеш не должен быть монолитным

Comments

[Sasha333]

Спасибо за ответ, речь шла не о монолитном кэше, а кэшировании отдельной страницы например чтобы при флуде этой страницы фильтрации и запросы к бд выполнялись например лишь 1 раз в минуту вместо 10000 раз в минуту. В целом я понял ещё из ответов выше где я делаю лишние действия и откровенные глупости.

[AUser0]

Просто сохраняй где-нибудь на диске файл с результатом работы (HTML), и если с момента последнего изменения файла прошло больше 59 секунд - генерируй и записывай и отдавай пользователю новый HTML. А если меньше 60 секунд - просто выводи содержимое файла (там же HTML?).

[Антон Шаманов]

AUser0, для каждого пользователя свой вариант сохранять что ли? проще тогда уж использовать заголовок etag и хранить на стороне пользователя