Когда использовать filter_input ()

Ну, будут разные мнения.

Я считаю, что вы всегда должны использовать его (или, в общем, расширение filter ). Для этого существует как минимум 3 причины:

1. Санитарный ввод – это то, что вы всегда должны делать. Поскольку функция дает вам эту возможность, на самом деле нет причин искать другие способы дезинфекции ввода. Поскольку это расширение, фильтр также будет намного быстрее и, скорее всего, более безопасным, чем большинство PHP-решений, что, безусловно, не повредит. Единственное исключение – если вам нужен более специализированный фильтр. Даже тогда вы должны захватить значение с FILTER_UNSAFE_RAW фильтра FILTER_UNSAFE_RAW (см. № 3).

2. В расширении filter есть много плюсов. Это может сэкономить вам часы от написания кода санитарии и проверки. Конечно, он не охватывает каждый отдельный случай, но этого достаточно, чтобы вы могли больше сосредоточиться на конкретном файле фильтрации / проверки.

3. Использование этой функции очень хорошо, когда вы отлаживаете или проверяете свой код. Когда функция используется, вы точно знаете, какой будет вход. Например, если вы используете фильтр FILTER_SANITIZE_NUMBER_INT вы можете быть уверены, что на входе будет число – нет инъекций SQL, кода HTML или Javascript и т. Д. Если вы, с другой стороны, используете что-то вроде FILTER_UNSAFE_RAW то знаете что к ней следует относиться осторожно и что это может легко вызвать проблемы безопасности.

Как говорит Сверри М. Олсен, в этом есть разные мнения.

Я очень согласен с философией Filter Input, Escape Output .

Необходим ли filter_input (), если вы используете параметризованные запросы и htmlspecialchars () перед печатью любых данных, предоставленных пользователем?

Короткий ответ: ИМО, Нет. Это не обязательно, но может быть полезно в некоторых случаях.

Функция filter_input имеет много полезных фильтров, и я использую некоторые из них (например, FILTER_VALIDATE_EMAIL). Фильтры проверки пригодны для проверки ввода. Однако ИМО, те, которые преобразуют данные, должны использоваться только на выходе.

Некоторые люди рекомендуют избегать ввода. Действительно, примеры, приведенные на странице руководства filter_input , также поощряют это.

 $search_html = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_SPECIAL_CHARS); $search_url = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_ENCODED); 

Единственными примерами являются экранирование . Это в сочетании с именем функции ( вход фильтра), кажется, говорит о том, что экранирование входа является хорошей практикой. Требуется экранирование, но IMO следует делать перед выходом, а не на входе. По крайней мере, возвращаемые значения хранятся в соответствующих им переменных.

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

Например, Google Analytics обрабатывает ввод таким образом, который заставляет мои кодированные амперсанды (% 26) декодироваться до исключения параметров запроса. В результате у меня есть статистика для параметров запроса, которые на самом деле даже не существуют в моих URL-адресах. См. Мой вопрос по этому вопросу, который остается нерешенным.

Вы также можете прочитать « Почему« побег на входе »- плохая идея . Вот некоторые отрывки, с которыми я согласен, на всякий случай статья исчезает [акцент в оригинале].

[…] escape-on-input просто ошибочно […] это нарушение слоя – оно смешивает проблему форматирования вывода с обработкой ввода. Нарушения в слое делают ваш код намного сложнее понять и поддерживать, потому что вы должны учитывать другие слои, вместо того чтобы позволить каждому компоненту и слою выполнять свою работу.

а также

По умолчанию вы портили свои данные. Система […] теперь легла о том, какие данные пришли.

а также

Выход на вход не только не справится с проблемами более чем одного выхода, он фактически сделает ваши данные неверными для многих выходов.

а также

PHP использовал функцию, называемую магическими кавычками. Это была функция escape-on-input, которая […] вызвала всевозможные проблемы. […] Согласно Лердорфу, гораздо более новое расширение «фильтра» PHP – «magic_quotes done right». Но он по-прежнему страдает почти всеми описанными здесь проблемами.

Итак, как расширение фильтра лучше, чем магические кавычки (кроме того, что у него много разных фильтров)? Фильтры вызывают многие из тех же проблем, что и магические цитаты.

Вот используемые мной правила кодирования:

• значения в $ _POST, $ _GET, $ _REQUEST и т. д. не должны быть экранированы и должны всегда считаться небезопасными
• значения должны быть проверены ¹ перед записью в базу данных или сохранены в $ _SESSION
• значения, ожидаемые как числовые или логические, должны быть дезинфицированы ² перед записью в базу данных или сохранены в $ _SESSION
• доверять, что числовые и логические значения из базы данных и $ _SESSION действительно являются числовыми или логическими
• строковые значения должны быть экранированы SQL перед использованием непосредственно в любом SQL-запросе (не строковые значения должны быть дезинфицированы ² ) или использовать подготовленные операторы
• строковые значения должны быть экранированы HTML перед использованием в выводе HTML (не строковые значения должны быть дезинфицированы ² )
• строковые значения должны быть закодированы в процентах перед использованием в строках запроса (не строковые значения должны быть дезинфицированы ² )
• используйте соглашение об именах переменных (например, * _url, * _html, * _sql) для хранения преобразованных данных

терминология

Для моих целей здесь я определяю термины, используемые выше.

1. для подтверждения способов подтверждения любых допущений относительно данных, таких как наличие определенного формата или обязательных полей, имеющих значение
2. для дезинфекции средств для подтверждения значений в точности как ожидалось (т.е. $ id_num должен содержать только цифры)

Резюме

В целом (могут быть некоторые исключения), я бы рекомендовал следующее:

• использовать фильтры проверки на входе
• использовать фильтры очистки на выходе
• помните TIMTOWDI. Например, я предпочитаю htmlspecialchars () (у которого больше опций) через FILTER_SANITIZE_FULL_SPECIAL_CHARS или FILTER_SANITIZE_SPECIAL_CHARS (который избегает разрывов строк)