Traitement chaines entrées

Bon,

Je sais bien que ce sujet serait mieux dans PHP, mais je pense que le niveau ici sera meilleur. J'ai jamais vraiment eu de réponses à certaines questions, j'ai l'impression que seuls les scripteurs postent sur internet (sans blague).

En général, sur des variables d'entrée de type $_POST, je m'attends à une chaine de caractères écrite à la main (venant d'un formulaire etc), ou du même type. Cette chaine représente un danger potentiel, mais on va dire que chaque utilisateur des chaines d'entrée se doit de gérer ses propres vulnérabilités.

Toutefois, certains dangers sont communs, et l'on peut même définir ce qu'est une chaine UTF8 (par exemple) valide. Ce qui diffère d'une chaine de caractère plutôt de type binaire.

A mon sens, j'aurais donc tendance à :

- Nettoyer la chaine de caractère des caractères de controles non imprimables tel que le caractère nul. Comme je le disais, on n'enlève pas nul parce qu'il est dangereux, mais tout simplement parce qu'il va prendre de la place dans la base de données (par exemple) pour rien, et qu'aucun humain censé penserait à l'insérer dans un texte. Il s'agit donc de le supprimer des variables chaines UTF-8 et laisser à disposition dans une autre variables une copie entière binaire (on sait jamais, on pourrait toujours en avoir besoin).

- Vérifier l'encodage. Oui, je me suis demandé un jour "ca fait quoi de passer du iso à un code utf8". En fait, pas spécialement grand chose. J'avais déjà vu des opérations utf8 sur de l'iso se transformer en catastrophe : une chaine vide était retournée. D'autres on des valeurs fausses (strlen par exemple). Or, d'une part on attend de l'utf8, donc c'est pas valide, et si on l'affiche par la suite, on aura quelque chose d'invalide, d'autre part, on a un problème de sécurité général. Qui peut dire quelle sera la réaction exacte d'une fonction avec une chaine totalement invalide dessus ? Difficile ... Et deuxio, les faux utf-8, composés d'ensembles plus grand qu'ils devraient (exemple un . codé sur deux octets). mb_ propose une extension pour cela, et elle semble fonctionner à la fois pour un ensemble d'octets invalides et aussi pour des caractères plus long que prévus (mais surement pas dans des cas plus fins, à voir).

D'après vous, ce ne serait pas normal de mettre ces deux "nettoyeurs" en entrée ? J'ai l'impression que tout le monde utilise directement les variables, quitte à se contenter d'un nettoyage par liste blanche.

Tchao ;) Je participerai aussi sur les exceptions car je pense sérieusement à écrire ou à reprendre une petite classe pour que toutes les erreurs (même NOTICE) se "transforment" en Exception. La gestion des erreurs en PHP est une abération, et là ce n'est pas une question, c'est une certitude ;)

a+

Je suis tout à fait d'accord avec ce que tu dis et pour te répondre, avant d'utiliser Zend, j'effectué moi même les deux nettoyage que tu explique ici.

D'ailleurs mes variables $_GET ou $_POST passaient obligatoirement dans une fonction faisant les nettoyages spécifiques afin de récupérer un résultat propre et ne risquant pas de corrompre la sécurité.

Par contre qu'appelles tu mettre les nettoyeur en entré? Tu veux dire avant d'envoyer?

Les erreurs en PHP et exceptions en PHP ne sont pas mal géré ce sont les utilisateurs qui ne les développeurs qui ne les gèrent pas ou mal.

Il est bon de faire comme Zend le fait d'envoyer toutes exception vers un controleur les gérant et les interprétant.

Non je ne parlais pas des exceptions justement.

Code:

---

fopen("http://abcdef",'r');

---

Par exemple, ce cas là. En admettant que l'on prévoit son échec :

if (!fopen(...))

Php émet quand même une erreur (pas exception), alors que tu prévois l'échec. Il faudra donc, soit ignorer l'erreur (mais alors comment la distinguer d'une erreur non prévisible vraiment), soit :

if (@!fopen())

Ce que je ne trouve pas particulièrement séduisant non plus. Alors que si fopen() émettait une exception :

Cas 1 : je ne prévois pas du tout que cette fonction échoue

fopen(...)

=> Paf, exception rattrapée par plus haut, affichage message de désolation à l'utilisateur, enregistrement dans les logs.

Cas 2 : je prévois que cette fonction, travaillant à distance, est susceptible d'échouer, et je veux le gérer

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

try {   fopen(...) fputs fclose   } catch (PhpErrorException $e) {   // Ici, ça me sert pas à grand chose mais bon ;)   }

---

En plus, un fopen() emet un WARNING pas un FATAL, ce qui fait que derrière il serait tout à fait possible de dire au client "on a bien enregistré votre information", puis quand il rappelle 'désolé, en fait non'.

Mon message n'empêche bien sûr pas de vérifier la présence du domaine avant, bien que selon certains cas, cela peut économiser des lignes :

Code:

---

1 2 3 4 5 6 7 8 9

try {   fopen('http://www.gougueule.fr','r'); fread...   } catch (...) { echo "Domaine n'existe pas, veuillez rectifier"; }

---

Par contre en faisant ça, et en sachant que PHP n'émet pas d'exception, il sera difficile d'analyser la raison réelle de l'échec, sauf éventuellement en enregistrant dans l'exception le type d'erreur émis, voire le message.

Bref, les exceptions permettent un développement strict (comme le typage fort), et même des oublis de déclaration de variable, qui peuvent entrainer des débogages douloureux, amènent à un échec certain.

Cela étant, c'est un autre sujet ^^

Ici dans ton cas ce n'est pas vraiment PHP en lui même qui pose problème mais la fonction fopen, tu peux si tu le désire créer une classe faisant cela ou encore tes propre fonction et gérer tous les types d'erreurs possible et envoyer des exceptions en fonction du résultat

oui le error handler php le permet. Ca ne m'empêche pas de critiquer le système d'erreur de php. Je n'en ai pas dit plus sur le premier post, car mon point de vue sur les exceptions est pas vraiment négociable (on ne sait jamais ;)). Par contre celui des entrées n'est pas forcément mûr.

En quelque sorte (je reviens au sujet initial), travailler des chaines en entrée sans les vérifier, les travailler avec des outils utf8, ça revient un peu à travailler une variable sans la vérifier avec des outils pour array. Et au contraire d'une variable, on ne peut pas être sûr du contenu une entrée (un formulaire par exemple).