Discussion :

[philippe6]

Bonjour,

Je ne sais pas si je suis sur le bon forum et je ne sais pas non plus, si je peux poser cette question ici, mais c'est un thème que j'ai rencontré sur un site (payant) soutenu par le ministère de l'enseignement, (je crois), donc il n'y aurait pas de mal à poser cette question :
Si un utilisateur vient à modifier les valeurs des attributs après le point d'intérrogation de l'URL, il va bien sûr envoyer une page non attendue par le concepteur, mais cela ne peut concerner qu'un seul client, ou bien ne faudrait-il pas que la malveillance se situe chez l'hébergeur !?

J'espère que cette question ne dépasse pas la charte du forum,

Cordialement,

Philippe

[Celira]

Genre par exemple sur une url du genre :

http://www.developpez.net/forums/search.php?searchid=9985743

Ajouter quelque chose comme ça :

http://www.developpez.net/forums/search.php?searchid=9985743&admin=true

C'est parfaitement faisable au niveau individuel (n'importe quel utilisateur est capable d'ajouter "&admin=true" à la fin d'une url dans la barre d'adresse de son navigateur) et je suppose qu'il doit être possible de faire un script qui le fait automatiquement si on a accès à l'hébergeur.

D'où la règle de base du développement Web : "Never Trust User Input" (ne jamais faire confiance à l'utilisateur)

[sabotage]

J'ajoute que c'est la même chose sur un formulaire.
Par exemple si le formulaire propose une liste de choix, rien n’empêche l'utilisateur d'envoyer un choix qui n'est pas prévu dans la liste.
Il faut donc vérifier si les données reçus sont conformes.

[philippe6]

Merci à vous.
L'informatique est resté théorique pour moi, puisqu'après un DUT, je ne l'ai pas pratiqué dans ma vie professionnelle et mes questions sont peut-être incongrües,

Philippe

[sabotage]

Ce n'est pas une question incongrue, c'est au contraire un point important qui risque justement d'être négligé.

[Shuty]

"Ne jamais faire confiance aux saisies faites par l'utilisateur".

Que ce soit provenant de méthode GET / POST. Il faut toujours contrôler les flx entrant car on peut se retrouver avec de grosses failles de sécu (sql /xss / crsf...)