[Securité] Est-ce utile de filtrer une variable ni affichée ni insérée en BD

[JackBeauregard]

Bonjour,

- Admettons que vous avez un formulaire avec x champs.
- Le formulaire renvoit sur la même page.
- Sur cette page, vous testez la présence de la variable 'valider' issue de l'attribut "name" du bouton submit.
- Si cette variable est présente, vous déclenchez le script, puisque le formulaire a été soumis.
- Bien sûr vous filtrez toutes les entrées du formulaires, avec les expregs ou mysql_real_escape_string().

Mais la variable 'name' du bouton submit, est-ce utile de la "filtrer" ?
Pour moi non, puisqu'elle ne sert qu'à déclencher le script et n'est pas inclue dans la base de donnée et sa valeur n'est affichée nul part.
On ne teste que sa présence.

Qu'en pensez-vous ?

[Elwyn]

Ben non (si t'es en mode POST) dans ce cas un simple if(isset($_POST['valider'])) suffit, si t'es en GET la par contre filtre la

[JackBeauregard]

Oui je suis en mode POST et je fais comme tu dis.
Cela changerait quoi en mode GET ? Elle s'afficherait dans l'URL et le gars pourrait en profiter pour modifier sa valeur et expédier une requête SQL en rechargeant la page ? Qu'est-ce qui l'empêche de le faire en POST, puisque dans les deux cas, la variable n'est ni affichée ni envoyée en BD ?

[alain31tl]

Envoyé par JackBeauregard

Oui je suis en mode POST et je fais comme tu dis.
Cela changerait quoi en mode GET ? Elle s'afficherait dans l'URL et le gars pourrait en profiter pour modifier sa valeur et expédier une requête SQL en rechargeant la page ? Qu'est-ce qui l'empêche de le faire en POST, puisque dans les deux cas, la variable n'est ni affichée ni envoyée en BD ?

Tu parles de qui là, de toi ou des autres ?
Si tu veux essayer en Get, qui t'en empêche et de vérifier si c'est falsifiable ?
Ca te prend 1 minute pour modifier tes sources.

[JackBeauregard]

Je n'ai rien compris à ta réponse, tu n'as donc sans doute rien compris à ma question, mais c'est pas grave.

[Taum]

Salut,

Si tu testes juste la présence de la variable (isset) et que tu n'utilises nulle part son contenu, ça ne sert a rien de la filtrer évidement

Envoyé par Elwyn

si t'es en GET la par contre filtre la

Non, non et re-non : GET/POST(/COOKIE) même combat, les données sont envoyées par l'utilisateur et il peut y mettre ce qu'il veut.

[Elwyn]

Bref on s'en fou dans tous les cas tu demandes si la variable du submit est presente, si le mec s'eclate a la changer via l'adresse, elle n'est pas reconnue est basta. C'est tout. T'embetes pas avec tout ca

Et Taum imagine il demande if(isset($_GET['variable']) AND $_GET['variable'] == "submit"){ alors si l'utilsateur la change ca bug, mais qui irait faire ca oO

[JackBeauregard]

Imaginons la chose suivante :

- J'ai un formulaire avec la méthode GET.
- L'attribut name du bouton submitt est "valider".
- Après la validation, je test if(isset($_GET[valider]));

Ici $_GET['valider'] ne sert à rien d'autre qu'à vérifier que le formulaire est posté.
Toutes les autres valeurs du formulaires sont filtrées, puisqu'elles sont incluses.


Qu'est-ce qui empêche ici le pirate de trafiquer dans l'URL la valeur de $_GET['valider'] pour y entrer une requête sql afin de faire une injection ?

[Nasky]

Qu'est-ce qui empêche ici le pirate de trafiquer dans l'URL la valeur de $_GET['valider'] pour y entrer une requête sql afin de faire une injection ?

Personne ne peut l'empêcher de taper le code dans l'adresse. C'est ton code PHP qu'il faut sécuriser pour qu'il bloque ce genre d'attaques. Il existe sur le net pas mal de docs sur les SQL injections et notamment comment se protéger.

Nas'

[Dia_FR]

les injections SQL c'est possible que si la variable qui est trafiquée est envoyée à la BdD

si tu fais que tester l'existence d'une valeur, tu t'en contrefous de son contenu par rapport à tes requêtes SQL