Фильтрация входных данных, хочу уточнить, как лучше?
Например у меня в коде есть такая строка $req = $_SERVER['REQUEST_URI']; переменная только в коде, в бд не записывается. Вопрос нужно как-то фильтровать такого рода входные данные как $_SERVER['REQUEST_URI'], которые в бд не записываются а только нужны в коде? Если не фильтровать такие входные данные, то есть ли какая нибудь угроза безопасности?
Что бы не парится, создай 1н способ фильтрации и пропускай через него.
Очищай полученные данные от скриптов и опасных символов, задавай ограничение на кол-во символов. Так-то про это можно долго писать + есть сетевые атаки и подделка .. кое как спасет токен и двух сторонние ключи.
Кратко - да.
Долго - зависит от использования. Если на основании значения вы динамически подключаете файлы, или выводите значение на страницу - то да, если же проверяете, например, регуляркой на наличие там какой-то подстроки, то можно и не проверять.
Фильтровать нужно всё, что участвует в выводе на страницу, ну и эскейпить строки при вставке в БД.
грубо говоря я проверяю регуляркой, но думаю буду фильтровать, и наверно теперь буду фильтровать все входящие данные, я думаю это никогда лишним не будет) спасибо)
Нужно фильтровать перед использованием. И фильтровать нужно всегда. Вопрос только как используются данные.
Для БД - prepared statements решают проблему фильтрации целиком и полностью
Для eval/exec нужно уже придумывать как фильтровать, проще вообще не использовать переменные полученные от пользователя для eval/exec.
Для фильтрации от XSS нужно чистить при выводе переменной.
А я предпочитаю не на выходе, а на входе фильтровать, чаще всего количество чтений превышает количество записей, да и мало ли как потом данные будут использоваться, лучше сразу обработать.
@nazarpc от XSS стоит фильтровать прямо при выводе только потому, что можно забыть это сделать где-то до. Да и это преобразования уровня представления. Вам в контроллере или где-то на уровне фронт контроллера не дано знать, что можно выводить во вью или нет.
