Que devez-vous vérifier dans les champs de texte du formulaire HTML?

Question

J'écris un script PHP pour récupérer des données de boîte de texte à partir d'un formulaire soumis. Ce sont des zones de texte simples et je ne veux pas accepter les balises HTML. Je pense que je devrais au moins utiliser strip_tags() et addslashes(). Rien d'autre? Cela ne me dérangerait pas de restreindre l'entrée à alphanumériques, devrais-je utiliser une expression régulière pour rechercher des caractères non standard?

Il s'agit d'une forme simple qui est envoyée par courriel à la personne qui la traite. (Pas de base de données, malheureusement.) Et ce sont des données simples, prénom et nom de choses.

Editer: Je voudrais aussi savoir précisément ce que je devrais rechercher. Quel est le consensus sur un filtrage d'entrée raisonnable?

Answer 1

Utilisez le PHP filter functions.

Vous pouvez les utiliser pour désinfecter les entrées et valider les entrées (par exemple, les adresses e-mail).

Il existe deux approches de la validation (cela s'applique également à la sécurité et à bien d'autres choses). Premièrement, vous pouvez autoriser n'importe quoi à l'exception de ce qui est explicitement interdit.

Ou vous pouvez par défaut ti interdisant tout sauf ce qui est spécifiquement autorisé. En règle générale, cette dernière approche est plus sûre et devrait être utilisée sauf dans les cas où vous avez une raison impérieuse de ne pas le faire (par exemple, il est trop difficile de savoir ce qui est autorisé, vous faites une application pour les utilisateurs qui ne sont pas considéré comme une menace pour la sécurité et ainsi de suite).

Vous devez faire attention cependant. Pour les noms de personnes, des caractères comme 'et - sont parfaitement valables mais les implémentations naïves peuvent les restreindre. Ce que vous voulez éviter en général est:

• injection SQL: toujours utilisation mysql_real_escape_string() sur toute entrée; XSS (Cross Site Scripting): en règle générale, vous devriez supprimer les balises HTML de l'entrée de l'utilisateur. Vous devrez bien sûr parfois les autoriser (par exemple des boîtes d'éditeur de texte enrichi) mais même dans ces cas vous aurez une liste de balises que vous autorisez et vous devrez éliminer tous les autres (en particulier les balises); et
• Tpiquement, vous devez supprimer les caractères bas (sous ASCII 20 ou plus); et
• En fonction de vos exigences d'internationalisation, vous pouvez supprimer les caractères élevés (au-dessus de ASCII 127).

Une bonne valeur par défaut à utiliser est:

$var = filter_var($var, FILTER_SANITIZE_STRING); 

mais ramasser le bon filtre pour la situation.

Answer 2

Ceci est une question très commune avec beaucoup de réponses pas si claires. Des fonctions comme addslashes() peuvent faire plus de mal que de bien dans certaines configurations. Certaines règles de base à suivre lors de la saisie de l'utilisateur, c'est de ne faire confiance à rien et si ce n'est pas dans le format que vous attendez, n'essayez pas de le réparer, mais faites juste une erreur.

Si vous avez seulement besoin de caractères alphanumériques, une simple regex va gérer cela, mais un peu plus d'informations vous aideraient.

Qu'allez-vous faire avec les données?Comment gérez-vous actuellement (ou planifiez-vous de) gérer l'entrée, par exemple, l'utilisateur soumet un formulaire, vous traitez le formulaire et stockez les données dans un DB pour les afficher ultérieurement (comme un moteur de commentaires). Editer: Si c'est aussi simple que d'envoyer une boîte de texte par e-mail pour un humain à traiter. Mes plus grandes préoccupations seraient XSS et l'injection d'en-tête smtp (en fonction de la façon dont l'email est envoyé). Essayez et allez avec la solution la plus simple, Si vous avez juste besoin de recevoir des données alphanumériques pour l'instant, utilisez une regex et acceptez seulement cela. Une autre solution serait d'utiliser htmlentities avec ENT_QUOTES.

Answer 3

Je ne veux pas accepter les balises HTML. Je pense que

Peut-être, mais pas si vous voulez permettre aux gens de taper « < «/»> » caractères qui signifient simplement moins que et supérieur, je devrais au moins utiliser strip_tags() et Aren » Rien à voir avec les tags. Lors de la saisie de champs de texte libre, vous ne voulez pas vraiment filtrer beaucoup plus que les caractères de contrôle non-retour (que vous ne voulez généralement pas) et, si vous utilisez UTF-8, séquences invalides/redondantes.

Ensuite, lorsque vous la sortie de la valeur à la page que vous aurez bien sûr ne pas oublier d'utiliser htmlspecialchars() de sorte que « < » obtient échappées à « & lt; » et apparaît comme un littéral « < » à l'écran, à droite ? Vous devez utiliser htmlspecialchars() chaque fois que vous affichez une valeur de texte en HTML dans un modèle, que cette chaîne provienne d'une soumission de formulaire, de la base de données ou d'un autre emplacement.

Pour les champs non-libres où vous voulez que toutes les entrées correspondent à un format restreint particulier, alors oui, une expression rationnelle peut être un bon moyen de faire correspondre cela.

et addslashes().

addslashes() est presque toujours la mauvaise chose. Une bonne règle est: ne l'utilisez pas. Addslashes() est inadéquat pour l'échappement SQL, car il ne correspond pas au format d'échappement littéral de la chaîne SQL, vous pouvez donc construire des chaînes qui sont encore dangereuses quand addslashed. Lorsque vous utilisez MySQL, vous devez utiliser mysql_real_escape_string() à la place. D'autres bases de données ont leurs propres fonctions d'échappement. Utilisez-les (ou, plus facilement, utilisez des requêtes paramétrées afin de ne pas avoir à extraire du texte manuellement vers SQL).

(addslashes() est insuffisant pour HTML échapper parce qu'il ne tente pas de faire quoi que ce soit avec les caractères spéciaux HTML à tous. Ce n'est pas ce qu'il est pour.)

Dans tous les cas, en essayant de faire face à output- s'échapper à l'étape de filtrage d'entrée est en arrière. Au lieu de cela, gardez toutes les chaînes internes à votre application en tant que texte brut, et échappez-les à la sortie de l'application: mysql_real_escape_string quand elles sortent pour prendre part à une requête SQL, htmlspecialchars() quand elles vont sur une page HTML, et ainsi de suite.