Je dois construire une forme d'action qui vous ramène à exactement la même page - obtenir des paramètres inclus. Je pense que je peux dire quelque chose à l'effet de: Ceci semble fonctionner et tester le passage d'une couple d'attaques XSS semble réussir, car la sortie de Query_string semble être une URL codé. Cependant, le documentation PHP ne mentionne pas cela, alors je suis Pas convaincu que je peux faire confiance à ce comportement. est-il sûr d'utiliser Query_string comme je suis au-dessus? Sinon, que puis-je faire à la place? Les références à la documentation seraient appréciées. Mise à jour commutée sur script_name, juste mélangé lequel était ok et qui était mauvais dans ma tête, merci de m'attaquer. action = "" résout mon problème spécifique joliment, mais je suis toujours curieux si Query_string est pré-traité, il est donc prudent d'utiliser ou non, car il y a d'autres fois que vous voudrez peut-être ré- Utilisez la chaîne de requête, en supposant que c'est sûr de le faire.
5 Réponses :
Tout d'abord, vous ne pouvez pas faire confiance $ $ _Server ['php_self'] ( 1 ) - Utilisez $ _Server [" script_name "] à la place.
Comme pour $ _Server ['Query_string'], vous devez le traiter comme une autre entrée utilisateur. Filtrez-le avant de l'utiliser dans votre sortie. Je ne recommanderais pas une sorte de filtre général dans ce cas. Il serait préférable de réassembler la chaîne de requête à partir de pièces spécifiques que vous attendez d'être là.
S'il est exploitable par XSS, vous devez d'abord savoir quelle attaque. Dans le code Publié ici, il n'y a qu'un Attaque simple en utilisant le php_self.
Mais, pour éviter tout problème, vous pouvez simplement laisser l'action de formulaire en blanc. Cela enverra le formulaire à la même page, y compris la chaîne de requête.
Je ne peux pas penser à aucune attaque qui fonctionnerait hors main, mais Pourquoi ne pas simplement quitter le paramètre action vide et laisser le navigateur décider? Vous pouvez utiliser JavaScript pour appliquer correctement ce comportement sur le côté client si vous souhaitez être doublement sûr. php_self est vulnérable et que vous utilisez Query_string sans filtrage quel que ce soit, ce qui semble impair.
Vous ne devez jamais faire confiance à $ _Server ['Query_string'] car il peut être utilisé pour les attaques XSS.
Dans votre cas, on pourrait exploiter la vulnérabilité avec: P>
http://your.server.com/your_script.php?"><script>alert(111);</script>
Merci, / ceci / est ce que je demandais. Nous ne pouvons pas faire confiance à la variable car il est content de dépendre du navigateur, excellent.
+1 Veuillez noter l'élément d'information important. Ce n'est pas que vous ne pouvez pas utiliser les données; C'est seulement que vous ne pouvez pas confiance it :)
Ceci est un autre de ces instances où utiliser PHPS Ceci est dû aux raisons indiquées ci-dessus - vous dites que vous faites confiance aux données externes, quand, si elle peut être entrée ou manipulée. Par les utilisateurs, vous ne pouvez pas. lire plus ici filtre_input est la voie à suivre. Mon IDE Netbeans (déteste ou l'aimer) se plaint toujours chaque fois que j'ouvre du code qui accède à $ _ Post , $ _ get , $ _ / code> et et $ _ Cookie directement sans passer par filtre_input .
N'assume jamais. Vous ne savez jamais ce que ces escrocs peuvent venir!
Bien sûr que non :) c'est les valeurs brutes de l'URI
Si vous souhaitez soumettre votre utilisateur à la même page, vous n'avez même pas besoin de spécifier quelle action ...
Pourquoi ne pas simplement laisser l'action de formulaire en blanc? Cela enverra un message à la même page, y compris la QueryString.
Vous savez
php_self est vulnérable, non? Comme les commentaires ci-dessus disent qu'il est préférable de quitter l'action en blanc.Faire des
Action Blank ne signifie pas que vous êtes à l'abri des attaques XSS supposées, mais cela vous donne le même comportement.