Отличен ли фильтр_var?

Ответ 1

Чтобы защитить от SQL-инъекции, используйте подготовленные инструкции, если это возможно. Если нет, используйте mysql_real_escape_string для строк, (int) casting или intval() для целых чисел (float) или floatval() для float и addcslashes ($ input, '% _') для строк, которые будут использоваться внутри операторов LIKE. Все становится еще сложнее при попытке избежать строк, которые будут использоваться внутри операторов RLIKE.

Для фильтрации содержимого HTML лучшим будет strip_tags (без передачи $allowable_tags), но... вам может не понравиться/не нужно, и в этом случае наиболее доступным решением является:

$escaped = htmlspecialchars($input, ENT_QUOTES, $your_charset);

Более надежным решением было бы использовать библиотеку, например HTML-очиститель

Функции фильтра в порядке, но некоторые из них более валидаторы, чем фильтры. В зависимости от ваших потребностей вы можете найти некоторые из них полезными.

Ответ 2

Вы настраиваете filter_var, используя его с константами FILTER_*. Похоже, вы ищете sanitisation данных (фактически настраивая данные, чтобы сделать их безопасными *), а не проверка (проверка данных безопасна).

Различные фильтры могут помочь с различными задачами. В то время как mysql_real_escape_string подходит для дезинфекции данных, чтобы предотвратить внедрение SQL, это не подходит для вывода данных, которые могут содержать HTML. Вот несколько фильтров, которые я бы использовал для повседневных задач:

• FILTER_SANITIZE_SPECIAL_CHARS - полезно для отображения (без удаления) кода HTML, предотвращения атак XSS и преобразования символов в объекты HTML.
• FILTER_SANITIZE_STRING с флагами STRIP_LOW/HIGH - фактически удаляет HTML (см. strip_tags).
• FILTER_SANITIZE_URL - делает URL-адреса безопасными *.
• FILTER_SANITIZE_EMAIL - делает почтовые адреса безопасными, хотя я бы предпочел использовать его кузена проверки, прежде чем хранить адрес.

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

Ответ 3

Все зависит от того, что вы подразумеваете под действительным URL-адресом или действительным электронным письмом.

Например [email protected] - ну, вы можете отфильтровать домены верхнего уровня, чтобы исключить .c, но список доменов верхнего уровня не является постоянным. Кроме того, все символы действительны. Хотя это выглядит странно и почти наверняка недействительно, многие регулярные фильтры также подтвердят его.

С адресом электронной почты [email protected] или url http://., если они отображаются или используются в ссылках, они не принесут никакого вреда, даже если они не отправятся.

Я думаю, что часть проблемы - вопрос о том, насколько вы свободны от своих фильтров. Если большой проблемой является XSS или SQL-инъекция или иным образом предотвращает опасный ввод, независимо от того, может ли это значение использоваться, может быть неактуальным, поэтому такой фильтр может сделать трюк.

Если вы хотите убедиться, что это значение не просто безопасно, но и полезно, это более хитрый зверь.

Ответ 4

Это действительно зависит от того, что вы пытаетесь сделать, я не могу ответить, не зная специфики. Возможные фильтры и их эффекты перечислены здесь: Типы фильтров

Ответ 5

Просто основанный на небольшом тестировании, я пришел к выводу, что константы filter_var не заслуживают доверия.

Например:

filter_var('[email protected]', FILTER_VALIDATE_EMAIL); // valid
filter_var('http://.', FILTER_VALIDATE_URL); // valid
filter_var('[email protected]', FILTER_SANITIZE_EMAIL); // [email protected]
filter_var('http://.', FILTER_SANITIZE_URL); // http://.

Это явно недопустимые значения, но передайте константы filter_var. Не доверяйте filter_var.