Au début du guide, nous disions que le filtrage des données est la pierre angulaire de la sécurité des applications WEB dans n'importe quel langage et sur n'importe quelle plateforme. Cela inclut la vérification des données saisies vers et depuis l'application, et une bonne conception logicielle peut aider les développeurs à :
garantir que le filtrage des données ne peut pas être contourné,
garantir que les informations illégales n'affectent pas les informations juridiques et
identifier la source des données.
Il existe différents points de vue sur la manière de garantir que le filtrage des données ne peut pas être contourné, et deux d'entre eux sont plus généraux que d'autres et offrent un niveau d'assurance plus élevé.
Méthode de planification Cette méthode est planifiée avec un seul script PHP (via URL). Toutes les autres opérations sont incluses en utilisant include ou require si nécessaire. Cette approche nécessite généralement que chaque URL reçoive une variable GET distincte pour l'envoi. Cette variable GET peut être considérée comme une conception plus simplifiée qui remplace le nom du script. Par exemple :
http://example.org/dispatch.php?task=print_formdispatch.php est le seul fichier racine (racine du document). Cela permet aux développeurs de faire deux choses très importantes :
implémenter un traitement de sécurité global dans dispatch.php au début et s'assurer que ces traitements ne peuvent pas être contournés.
Il est facile de déterminer où le filtrage des données est nécessaire, en particulier pour certaines opérations de flux de contrôle spécifiques.
Voir l'exemple suivant pour une discussion plus approfondie du script dispatch.php :
<?php/* Global Security Handling*/switch ($_GET['task']){case 'print_form':include '/inc/presentation/form.inc '; break;case 'process_form':$form_valid = false;include '/inc/logic/process.inc';if ($form_valid){include '/inc/presentation/end.inc';}else{include '/ inc/ présentation/form.inc';}break;default:include '/inc/presentation/index.inc';break;}?>S'il s'agit du seul script PHP accessible au public, vous pouvez être sûr que ce programme La conception garantit que le traitement de sécurité global initial ne peut pas être contourné. Cela permet également aux développeurs de voir facilement le flux de contrôle de tâches spécifiques. Par exemple, il est facile de le savoir sans parcourir tout le code : lorsque $form_valid est vrai, end.inc est le seul affiché à l'utilisateur puisque c'est avant que process.inc soit inclus et vient d'être initialisé à false ; peut être déterminé que la logique interne de process.inc le définira sur true ; sinon le formulaire sera à nouveau affiché (éventuellement avec un message d'erreur associé).
Notez que si vous utilisez un fichier de directives de répertoire tel que index.php (au lieu de dispatch.php), vous pouvez utiliser l'adresse URL comme celle-ci : http://example.org/?task=print_form .
Vous pouvez également utiliser la redirection ApacheForceType ou mod_rewrite pour ajuster l'adresse URL : http://example.org/app/print-form .
Une autre façon d'inclure des méthodes consiste à utiliser un seul module responsable de toute la gestion de la sécurité. Ce module est inclus au début (ou tout au premier plan) de tous les scripts PHP publics. Reportez-vous au script suivant security.inc
<?phpswitch ($_POST['form']){case 'login':$allowed = array();$allowed[] = 'form';$allowed[] = 'username' ; $allowed[] = 'password';$sent = array_keys($_POST);if ($allowed == $sent){include '/inc/logic/process.inc';}break;}?>Dans ce cas , chaque formulaire soumis est considéré comme contenant la valeur de vérification unique du formulaire, et security.inc traite indépendamment les données du formulaire qui doivent être filtrées. Le formulaire HTML qui implémente cette exigence est le suivant :
<form action="/receive.php" method="POST"><input type="hidden" name="form" value="login" /><p>Nom d'utilisateur : <input type="text" name="username" /></p><p>Mot de passe :<input type="password" name="password" /></p><input type="submit" / > </form>Un tableau appelé $allowed est utilisé pour vérifier quelles variables de formulaire sont autorisées. Cette liste doit être cohérente avant le traitement du formulaire. Le contrôle des processus décide ce qu'il faut exécuter, et process.inc est l'endroit où arrivent les données filtrées réelles.
Notez qu'une meilleure façon de garantir que security.inc est toujours inclus au début de chaque script consiste à utiliser le paramètre auto_prepend_file.
Exemple de filtrage La création d'une liste blanche est très importante pour le filtrage des données. Puisqu'il est impossible de donner des exemples pour chaque donnée de formulaire que vous pourriez rencontrer, quelques exemples peuvent vous aider à avoir une compréhension générale.
Le code suivant valide l'adresse email :
<?php$clean = array();$email_pattern = '/^[^@s<&>]+@([-a-z0-9]+.) +[ az]{2,}$/i';if (preg_match($email_pattern, $_POST['email'])){$clean['email'] = $_POST['email'];}?> ci-dessous Le code garantit que le contenu de $_POST['color'] est rouge, vert ou bleu :
<?php$clean = array();switch ($_POST['color']){case 'red':case 'green ' :case 'blue':$clean['color'] = $_POST['color'];break;}?>Le code suivant garantit que $_POST['num'] est un entier :
<?php$ clean = array ();if ($_POST['num'] == strval(intval($_POST['num']))){$clean['num'] = $_POST['num'];} >Ce qui suit ? le code garantit que $_POST['num'] est un float :
<?php$clean = array();if ($_POST['num'] == strval(floatval($_POST['num ']))){ $clean['num'] = $_POST['num'];}?> Chaque exemple utilise le tableau $clean avant la conversion du nom. Il s'agit d'une bonne pratique permettant aux développeurs de déterminer si leurs données sont potentiellement compromises. Ne sauvegardez jamais les données dans $_POST ou $_GET après les avoir validées. En tant que développeur, vous devez toujours vous méfier des données enregistrées dans des tableaux super globaux.
Il faut ajouter que l’utilisation de $clean peut aider à réfléchir à ce qui n’a pas été filtré, ce qui s’apparente davantage au rôle d’une liste blanche. Peut améliorer le niveau de sécurité.
Si vous stockez uniquement des données validées dans $clean, le seul risque lié à la validation des données est que l'élément du tableau auquel vous faites référence n'existe pas, et non des données dangereuses non filtrées.
Timing Une fois que le script PHP commence à s'exécuter, cela signifie que toutes les requêtes HTTP sont terminées. À ce stade, l'utilisateur n'a aucune possibilité d'envoyer des données au script. Par conséquent, aucune donnée ne peut être saisie dans le script (même si register_globals est activé). C'est pourquoi l'initialisation des variables est une très bonne pratique.