Является ли filter_var хорошим способом?

Question

Хорошо ли filter_var для фильтрации данных? Какие плохие данные будут отфильтрованы? Я использую mysql_real_escape_string, но мне интересно, поможет ли добавление filter_var?

Answer 1

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

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

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

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

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

Answer 2

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

Различные фильтры могут помочь с различными задачами. Хотя 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 - делает адреса электронной почты безопасными, хотя я предпочел бы использовать его двоюродного брата для проверки перед сохранением адреса.

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

Answer 3

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

Например, a@b-.c - вы можете отфильтровать домены верхнего уровня, чтобы исключить .c, но список доменов верхнего уровня не является постоянным. Более того, все символы действительны. Даже если это выглядит странно и почти наверняка недействительно, многие фильтры регулярных выражений тоже его проверят.

С электронной почтой a@b-.c или URL http://., если они отображаются или используются в ссылках, они не причинят вреда, даже если они никуда не денутся.

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

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

Answer 4

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

Answer 5

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

Например:

filter_var('a@b-.c', FILTER_VALIDATE_EMAIL); // valid
filter_var('http://.', FILTER_VALIDATE_URL); // valid
filter_var('a@b-.c', FILTER_SANITIZE_EMAIL); // a@b-.c
filter_var('http://.', FILTER_SANITIZE_URL); // http://.

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