Когда фильтровать ввод пользователя
Рассмотрим этот код:
// store the $name into a database
$name = filter_input(INPUT_POST, 'name', FILTER_SANITIZE_STRING);
// already encrypted password (client-side) and will be salted or hashed again to store it into DB
$password = filter_input(INPUT_POST, 'password', FILTER_SANITIZE_STRING);
// just to check if the $lang is on the $language array i.e. in_array($lang, $language)
$lang = filter_input(INPUT_POST, 'language', FILTER_SANITIZE_STRING);
// just to echo something
$sth = filter_input(INPUT_POST, 'sth', FILTER_SANITIZE_STRING);
Здесь я попытался описать некоторые ситуации. И в каждой ситуации я фильтровал пользовательский ввод (в некоторых случаях это было необязательно). Мой вопрос заключается в том, когда фильтровать пользовательский ввод, поскольку кажется, что фильтрация пользовательского ввода не всегда необходима.
Решение
это может дать вам лучшее понимание проверки ввода:
Проверка входных данных является как самой фундаментальной защитой, на которую опирается веб-приложение, так и самой ненадежной. Подавляющее большинство уязвимостей веб-приложений возникает из-за сбоя проверки, поэтому очень важно правильно понять эту часть нашей защиты. Даже там, где мы, кажется, поняли это, нам нужно быть внимательными к следующим соображениям.
Об этом следует помнить при реализации пользовательских валидаторов или при использовании сторонней библиотеки валидации. Когда дело доходит до сторонних валидаторов, также учитывайте, что они, как правило, носят общий характер и, скорее всего, опускают ключевые процедуры валидации, которые потребуются вашему веб-приложению. Как и с любой библиотекой, ориентированной на безопасность, не забудьте лично проверить предпочитаемую библиотеку на наличие недостатков и ограничений. Стоит также иметь в виду, что PHP не стоит выше некоторых странных, возможно, небезопасных действий. Рассмотрим следующий пример из функций фильтрации PHP:
filter_var('php://', FILTER_VALIDATE_URL);
В приведенном выше примере фильтр проходит без проблем. Проблема с принятием URL-адреса php: // заключается в том, что его можно передать функциям PHP, которые ожидают получить удаленный URL-адрес HTTP, а не возвращать данные от выполнения PHP (через оболочку PHP). Недостаток в приведенном выше заключается в том, что в параметрах фильтра нет способа ограничения разрешенной схемы URI, и пользователи ожидают, что это будет один из http, https или mailto, а не какой-то общий специфичный для PHP URI. Это своего рода общий подход к валидации, который мы должны стремиться избегать любой ценой.
Более подробная информация доступна по адресу: http://phpsecurity.readthedocs.org/en/latest/Input-Validation.html
Другие решения
Других решений пока нет …