Est filter_var
est-il efficace pour filtrer les données ? Quel genre de mauvaises données filtrera-t-il ? J'utilise mysql_real_escape_string
mais je me demande si ajouter filter_var
vous aidera ?
Réponses
Trop de publicités?Pour se protéger des injections SQL, utilisez des instructions préparées si possible. Sinon, utilisez mysql_real_escape_string pour les chaînes de caractères, (int) casting ou intval() pour les entiers, (float) ou floatval() pour les flottants et addcslashes($input, '%_') pour les chaînes de caractères à utiliser dans les instructions LIKE. Les choses se compliquent encore plus lorsqu'on essaie d'échapper les chaînes à utiliser dans les instructions RLIKE.
Pour filtrer le contenu HTML, la meilleure solution serait strip_tags (sans passer $allowable_tags), mais... vous n'aimerez peut-être pas/ne voudrez peut-être pas, auquel cas la solution la plus abordable est :
$escaped = htmlspecialchars($input, ENT_QUOTES, $your_charset);
Une solution plus fiable serait d'utiliser une bibliothèque telle que Purificateur HTML
Les fonctions de filtrage sont acceptables, mais certaines d'entre elles sont plus des validateurs que des filtres. En fonction de vos besoins, vous pouvez trouver certaines d'entre elles utiles.
Vous ajustez filter_var
en l'utilisant avec le FILTER_*
constantes . On dirait que vous cherchez assainissement de données (en fait, ajuster les données pour les rendre sûres*) plutôt que de validation (vérification de la sécurité des données).
Des filtres différents peuvent aider à accomplir des tâches différentes. Alors que mysql_real_escape_string
permet d'assainir les données pour éviter les injections SQL, mais ne convient pas à la sortie de données pouvant contenir du HTML. Voici quelques filtres que j'utilise pour les tâches quotidiennes :
-
FILTER_SANITIZE_SPECIAL_CHARS
- utile pour afficher (et non supprimer) le code HTML, prévenir les attaques XSS et convertir les symboles en entités HTML. -
FILTER_SANITIZE_STRING
avec leSTRIP_LOW/HIGH
flags - supprime en fait le HTML (voirstrip_tags
). -
FILTER_SANITIZE_URL
- sécurise les URLs*. -
FILTER_SANITIZE_EMAIL
- sécurise les adresses e-mail, même si je préfère utiliser son cousin de validation avant de stocker l'adresse.
* J'utilise le terme "sécurité" dans un sens large, car je pense qu'on n'est jamais trop sûr.
Tout dépend de ce que vous entendez par "url valide" ou "e-mail valide". Par exemple, a@b-.c - vous pourriez filtrer les domaines de premier niveau pour exclure le .c, mais la liste des domaines de premier niveau n'est pas constante. De plus, tous les caractères sont valides. Même si cela semble bizarre et n'est presque certainement pas valide, de nombreux filtres regex le valideront également. Avec l'email a@b-.c ou l'url http://. S'ils sont affichés ou utilisés dans des liens, ils ne feront aucun mal, même s'ils ne mènent nulle part.
Je pense qu'une partie du problème est la question de savoir jusqu'à quel point vous voulez que vos filtres soient lâches. Si la préoccupation majeure est le XSS, l'injection SQL ou la prévention d'une entrée dangereuse, le fait que la valeur soit utilisable ou non peut être sans importance, et ce type de filtre peut donc faire l'affaire. Si vous voulez vous assurer que la valeur n'est pas seulement sûre mais aussi utilisable, c'est plus délicat.
Cela dépend vraiment de ce que vous essayez de faire, je ne peux pas vraiment répondre sans connaître les détails. Les filtres possibles et leurs effets sont listés ici : Types de filtres
Sur la base de quelques tests mineurs, je suis arrivé à la conclusion que filter_var
Les constantes de l'entreprise ne sont pas dignes de confiance.
Par exemple :
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://.
Ces valeurs sont clairement invalides, mais passent filter_var
Les constantes de l'entreprise. Ne pas faire confiance filter_var
.