- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Я не занимаюсь технической поддержкой сайтов, но так уж сложилось, что ко мне часто обращаются за помощью. С одной стороны отказывать неудобно, да и не выгодно с коммерческой точки зрения, с другой за большое спасибо в магазине тоже не расплатишься. Поэтому я решил написать универсальное решение, но столкнулся с некоторыми проблемами.
Суть решения заключается в том, чтобы отловить данные POST, GET, COOKIE и обработать их еще до того, как сайт произведет с ними какие-либо действия.
Вот собственно сам код
Тоже самое я сделал по аналогии с _GET и _COOKIE
Основные недостатки.
1) У меня так и не вышло обработать, а точнее перезаписать их внутри функции и передать _POST, _GET и _COOKIE в качестве переменных, а главное, как следствие, обработать многомерные массивы данных рекурсивно. Соответственно $_POST[][], $_POST[][][] и тд уже обработать не выйдет и каждый такой массив надо вставлять отдельно. Массив может быть бесконечно большой, а код получится бесконечно громозкий.
2) Не охота убирать функцию mysql_real_escape_string ведь никогда не знаешь, где ее забыли упомянуть, но возникает проблема излишнего экранирования символов.
3) strip_tags удаляет все теги. Мне бы не хотелось убирать все, а лишь самые опасные теги, но беда в том, что в дополнительных параметрах можно указать только теги, которые нужно оставить. Конечно, можно использовать регулярные выражения, но к сожалению, нет уверенности в том, что не забудешь что-нибудь важное, поэтому если у кого-то есть отличная замена этому, то предлагаю собрать все в кучу и избавиться от strip_tags
4) Ну и жду других советов по данному вопросу.
Соответственно $_POST[][], $_POST[][][] и тд уже обработать не выйдет и каждый такой массив надо вставлять отдельно
Не надо.
Результат
Универсальная защита от xss-атак и sql-инъекций
Ух.. уже 6 лет прошло /ru/forum/774368, а как вчера.. :)
ЗЫ. Кто хочет поржать - рекомендую полистать. Топик - классика жанра.
Для защиты от SQL-инъекций используйте подготавливаемые запросы.
Для защиты от XSS используйте функции filter_*
Прямое обращение к суперглобальным массивам - от лукавого.
Перезапись суперглобального массива $_POST - вообще тянет на уголовку.
Расширение mysql_ вроде ещё Иван Грозный запретил.
И вопрос: а что если в коде для получения переменных запроса используется filter_input/filter_input_array? Будет тогда Ваш код работать?
Перезапись суперглобального массива $_POST - вообще тянет на уголовку.
Мне как-то нужно было добавить функциональность в самописный движок, и для этого требовалось записывать в БД данные типа $_POST['name'][]. Написал, проверяю - шиш с маслом. Начал копать - оказывается, умник, который написал тот движок, на входе перезаписывал $_POST через array_walk(), и все мои переменные благополучно уничтожались. :(