FanatPHP, Ты сам то понимаешь что порешь? Причем часто.
Я тебе чёрным по белому пишу: что могу пользоваться только этой функцией в запросах и ты только лоб разобьёшь! И ничего больше.
Приведи пример где это НЕ поможет? Если откинуть неправильное использование этой функции в купе с кодировкой соединения с БД...и банальным НЕ обрамлением в ковычки в запросе...
FanatPHP, Ну и в довесок...давай я сделаю тестовую страницу с одним запросом принимающим GET/POST и обработаю только этой функцией...докажешь своё устойчивое НЕДОСТАТОЧНО ? :)
до меня разработчики написали filter_var с FILTER_SANITIZE_STRING. Сейчас обнаружилось что 30% токенов не сохранилось. Я просто предположил что фильтр мог обрезать токен в "" или null. Поэтому в базе он пустой.
Раз он пишется в базу, то тут, как минимум актуально, чтобы SQL-injection не прокатывало...а дальше - как выше написали: банальная проверка на актуальность этого токена...всё...
Пример "входящих" данных есть?
Точнее ты можешь сформулировать для себя "какие данные ты ожидаешь в приложении" ? Если можешь, то соответствующим образом и "фильтруй"...
Mirue, В моём понимании...эта "инструкция" постоянно расширяется, а местами становится не актуальной...
И, извиняюсь, "драконить" чела какими-то "писюльками" в виде "себе же инструкция" - ну не знаю...
Я бы смотрел на предыдущие его "заслуги" и текущие...
И, если в него есть "вера" ( или Катя:) ), то повесить на него ответственность за данное направление...пусть сам решает как обезопасить компанию...
Просто это тоже самое (как мне кажется):
Приехать повару на автосервис и советовать как лучше делать капитальный ремонт двигателя... :)
Ну и, если есть возможность, создать заведомо "дырявую" систему и дать ему пощупать...но эта лирика...))
Я тебе чёрным по белому пишу: что могу пользоваться только этой функцией в запросах и ты только лоб разобьёшь! И ничего больше.
Приведи пример где это НЕ поможет? Если откинуть неправильное использование этой функции в купе с кодировкой соединения с БД...и банальным НЕ обрамлением в ковычки в запросе...