par
naholyr » 15 juil. 2007, 12:08
J'utilise donc preg_replace, et je disais que la première chose que j'ai fait, c'est d'empêcher l'utilisation de l'option e (qui permettrait aux utilisateurs d'exécuter n'importe quelle action en php). Seulement j'aimerai savoir s'il n'y a pas d'autres options (ou je ne sais quoi) qui permettraient à des utilisateurs malveillants (ou maladroits) de causer des quelconques problèmes autres que les erreurs d'interprétation de la regex qu'ils ont écrit...
En sécurité la première règle c'est
«tout interdire, et autoriser au cas par cas».
Donc plutôt que de te poser la question de «quelles options pourraient poser problème ?» demande-toi plutôt quelles options ne peuvent pas en poser, et n'autoriser que celles-là.
Pour le masque en lui-même, toujours le même raisonnement : je ne laisserais pas l'utilisateur entrer son propre délimiteur. Cela évite d'avoir à se demander quel délimiteur risque de poser problème. J'en fixe un, et l'utilisateur s'y conforme.
Ainsi l'entrée du masque se ferait avec deux champs :
L'utilisateur entre son masque, sans les délimiteurs (qui sont fixés à '/') dans le premier champ, et ses options dans le deuxième champ.
Si tu n'as décidé d'autoriser que les options 's', 'i', et 'm', alors tout ce qui n'est pas 's', 'i', ou 'm' sera simplement ignoré ou sera la cause de l'affichage d'un message d'erreur.
[quote="o7a.net"]J'utilise donc preg_replace, et je disais que la première chose que j'ai fait, c'est d'empêcher l'utilisation de l'option e (qui permettrait aux utilisateurs d'exécuter n'importe quelle action en php). Seulement j'aimerai savoir s'il n'y a pas d'autres options (ou je ne sais quoi) qui permettraient à des utilisateurs malveillants (ou maladroits) de causer des quelconques problèmes autres que les erreurs d'interprétation de la regex qu'ils ont écrit...[/quote]En sécurité la première règle c'est [b]«tout interdire, et autoriser au cas par cas»[/b].
Donc plutôt que de te poser la question de «quelles options pourraient poser problème ?» demande-toi plutôt quelles options ne peuvent pas en poser, et n'autoriser que celles-là.
Pour le masque en lui-même, toujours le même raisonnement : je ne laisserais pas l'utilisateur entrer son propre délimiteur. Cela évite d'avoir à se demander quel délimiteur risque de poser problème. J'en fixe un, et l'utilisateur s'y conforme.
Ainsi l'entrée du masque se ferait avec deux champs : [code]/ [ . . . ] / [ . . . ][/code]
L'utilisateur entre son masque, sans les délimiteurs (qui sont fixés à '/') dans le premier champ, et ses options dans le deuxième champ.
Si tu n'as décidé d'autoriser que les options 's', 'i', et 'm', alors tout ce qui n'est pas 's', 'i', ou 'm' sera simplement ignoré ou sera la cause de l'affichage d'un message d'erreur.