2009-04-27 9 views
0

Je me demande comment mettre en place une manière intelligente d'avoir toutes mes entrées 'propres', une procédure à exécuter au début de chaque script. Je pensais que pour créer une classe pour le faire, puis, ajouter un préfixe 2 lettres au début de chaque entrée pour identifier le type d'entrée, par exemple:Est-ce que cela peut être un moyen efficace et fiable pour purifier l'entrée de l'utilisateur?

in-mynumber 
tx-name 
ph-phone 
em-email 

Ainsi, au sommet de mes scripts je lance simplement une fonction (par exemple):

function cleanInputs(){ 
    foreach($_GET AS $taintedKey => $taintedValue){ 
     $prefix = substr($taintedKey, 0, 2); 
     switch($prefix){ 
      case 'in': 
       //I assume this input is an integer 
       $cGet[$taintedKey] = intval($taintedValue); 
       break; 
      case 'tx': 
       //i assume this input is a normal text 
       //can contains onely letters, numbers and few symbols 
       if(preg_match($regExp, $taintedValue)){ 
        $cGet[$taintedKey] = $taintedValue; 
       }else{ 
        $cGet[$taintedKey] = false; 
       } 
       break; 
      case 'em': 
       //i assume this input is a valid email 
       if(preg_match('/^[a-zA-Z0-9-_.][email protected][a-zA-Z0-9-_.]+.[a-zA-Z]{2,4}$/', $taintedValue)){ 
        $cGet[$taintedKey] = $taintedValue; 
       }else{ 
        $cGet[$taintedKey] = false; 
       } 
       break; 
     } 
    } 
} 

..so je vais créer d'autres tableaux 2, cget $ et cPost $ avec les données propres respectivement de _GET et $ _POST, et dans mon script i Je vais même penser à ajouter un deuxième préfixe pour déterminer la longueur maximale de l'entrée ... par exemple: tx-25-name ..mais je ne suis pas très sûr de ça .. et si je prends de cette façon, peut-être une approche POO sera meilleure.

Que pensez-vous de cela? Semble-t-il un bon moyen d'utiliser? Les points négatifs que je peux réellement voir (je n'ai pas encore utilisé de cette façon, est juste une merveille de ce matin) 1. Le préfixe, et donc les procédures, doivent être nombreuses si je veux que mon application ne soit pas très restrictif; 2. Les noms de mes variables envoyées deviendront un peu plus longs (mais nous parlons de 3-6 caractères, cela ne devrait pas être un problème)

Toute suggestion est vraiment appréciée!

EDIT:

Je ne suis pas triyn de réinventer la roue, mon post was't sur le sistem à l'entrée désinfectante, mais est sur la procédure pour le faire. J'utilise htmlpurifier pour gérer l'injection de xss dans les données html, et bien sûr j'utilise les requêtes paramétrées. Je me demande simplement s'il est préférable de prendre une entrée par entrée, ou de les désinfecter tous au début et considérer qu'ils nettoient dans le reste du script. La méthode i thougt n'est pas miraculeuse et rien de nouveau sous le soleil, mais je pense que tronquer l'entrée si n'est pas dans le format que l'aspect, peut être utile ...

Pourquoi vérifier l'injection sql dans le ' name 'field, qui doit contenir juste des lettres et le caractère apostrophe? Supprimez simplement tout ce qui n'est pas lettre ou apostophe, ajoutez des barres obliques pour le dernier et lancez une requête paramétrée. Ensuite, si vous présentez un e-mail, supprimez tout ce qui n'est pas un e-mail.

+0

Je ne vois rien d'intrinsèquement mauvais dans votre approche, et je pense que c'est une bonne idée. – stefs

+0

aussi, je pense que vous êtes bourré. mais je comprends, je suis aussi un programmeur. – stefs

Répondre

0

L'idée est bonne en soi, mais je me demande si ce sera vraiment très utile. D'une part, les injections SQL et les injections HTML peuvent (devraient) être protégées d'une autre manière.Les injections SQL sont empêchées par des requêtes paramétrées (un must-have de nos jours); et les injections HTML sont empêchées par la méthode htmlspecialchars(), qui doit être appelée juste avant la sortie de la chaîne à l'utilisateur. Ne stockez pas de chaînes codées dans la base de données ou (pire encore) - encodez-les dès leur réception. Travailler avec eux sera un enfer plus tard.

En dehors de ces deux attaques par injection, que fera votre méthode? Eh bien, il peut faire des expressions rationnelles pour des choses comme des chiffres, des numéros de téléphone, des courriels, des noms et des dates. Mais c'est à peu près tout. Malheureusement, ce n'est qu'une partie de toutes les validations que vous devrez faire. Les autres cas courants que vous ne pouvez pas valider sont la vérification croisée des entrées (date de début avant la date de fin) et la vérification de la présence d'une valeur dans une liste de valeurs prédéfinies autorisées (par exemple, pour un élément <select>). Et il y a un nombre infini d'étapes de validation personnalisées que vous aurez dans votre application. Vaut-il la peine de scinder toutes les validations en "validation de type générique" et "validation de règle personnalisée"? Je ne sais pas. Peut-être. Ou peut-être que cela va faire un plus gros gâchis.

+0

D'accord. J'ai tendance à simplement préfixer mes noms d'entrée de formulaire avec le type d'entrée attendu, c'est-à-dire s, i, b pour string, integer ou boolean. C'est vraiment un aide de mémoire plus qu'une mesure préventive dure et rapide. –

0

Qu'est-ce que vous essayez de faire? Si vous devez désinfecter l'entrée pour enregistrer des données dans la base de données, il n'y a rien de mieux que des requêtes paramétrées.

Voir this pour un exemple.

+0

qui est? (requêtes paramétrées qui est ...) – Svish

+0

Les requêtes paramétrées ressemblent à ceci: ExecuteQuery ("INSERT INTO MyTable (Champ1, Champ2) VALUES (?,?)", $ Param1, $ Param2); L'idée est que la chaîne de requête contient des marqueurs (comme les signes de question) qui correspondent aux paramètres donnés plus loin. La requête est envoyée comme ceci au serveur, qui l'analyse également avec tous les points d'interrogation. Quand il est temps d'exécuter, le serveur reçoit également les valeurs de paramètre * séparément de la requête *. Il n'y a aucun risque d'injection. –

+0

La syntaxe précise de cette opération varie pour différents serveurs de base de données. Pour MySQL, vous pouvez voir un exemple ici: http://php.net/manual/en/mysqli.prepare.php –

2

Il existe de nombreux well-made PHP tested classes qui désinfectent déjà les entrées. Pourquoi en faire un autre? Par ailleurs, la désinfection des entrées est plus que la simple vérification des types de données. Cela implique de vérifier les injections sql, les attaques xss, etc ...

+0

+1 pour recommander le code existant qui a fait ses preuves. Si vous dépendez de la vérification explicite des vecteurs d'exploits connus, vous rencontrez un problème. –

+0

Je ne suis pas triyn pour réinventer la roue, mon poste ne parlait pas du système d'entrée d'assainissement, mais de la procédure à suivre. J'utilise htmlpurifier pour gérer l'injection de xss dans les données html, et bien sûr j'utilise les requêtes paramétrées. Je me demandais simplement s'il valait mieux prendre une entrée par entrée, ou les désinfecter tous au début et considérer qu'ils nettoient dans le reste du script. – Strae

Questions connexes