Bonjour,

J'ai lu qu'il fallait se méfier de l'utilisateur du programme. Dans quels cas ? Je n'en ai qu'un seul en tête :
Quand on demande à l'utilisateur une entrée qui est un choix entre "oui" et "non", il faut se méfier si l'utilisateur entre autre chose. En faisant une boucle do while par exemple. Sinon ça plante le programme je suppose.

Avez-vous d'autres exemples où il faut se méfier de l'utilisateur ?

J'ai l'exemple parfait

J'ai fait un chat IRC avec avatars, musiques etc, et tout fonctionne avec des lignes de 'code' genre

MS#Personnage#Emote#Texte#couleurdutext#%

Du coup, je dois toujours prévoir qu'un utilisateur va utiliser un nom qu'il ne lui appartient pas, ou qu'il va toujours faire ce que j'ai planifié, donc sécurités PARTOUT dans le prog.

Car sinon, y'a toujours un mec qui va péter ton prog

Du genre, le mec peux se faire assigner le perso 'Personnage1' et essayer de telnet en utilisant le pseudo 'Personnage2', du coup y'aurais deux mecs avec le même perso, tu vois le genre?

Si t'es dans un langage assez n'as niveau faut vérifier que le type de donnée en entrée corresponde à ce que tu attends (si tu demandes un nombre l'utilisateur risque d'écrire autre chose).

Si tu utilises un buffer de taille statique envisage la possibilité que l'utilisateur entre une chaîne de caractère plus longue que la taille du buffer.

http://imgs.xkcd.com/comics/exploits_of_a_mom.png

never trust user input

Même pas besoin que ça soit une input direct, de la part de l'utilisateur.

Si ton programme fait appel à des ressources externes, toussa toussa, l'utilisateur y accède, les modifs et hop.

Ou sinon, dans le cas d'un jeu, l'utilisateur tue quelqu'un dans le jeu et gagne 500exp. Un paquet est envoyé au serveur. Ok.
Mais si l'utilisateur capture ce paquet, et décide de le rejouer à l'infini ?
Il gagnera plein d'exp, sans pour autant avoir joué.
Il peut même modifier le comportement du jeu, sans avoir à accéder au serveur trop souvent ( pour pas être repéré et banni ) mais cette technique n'aura pas de conséquence sur le serveur et les autres joueurs, juste sur son jeu.

Jre reprend l'exemple: Il tue quelqu'un, il gagne 500exp, une requête est envoyé au serveur, le serveur lui envoie la réponse...

il peut rejouer les réponses du serveur, lui permettant de faire tout ce qu'il veut, mais à l'intérieur de son propre jeu. Il pourra par exemple, tester de nouvelles armes auquel il n'a pas accès normalement...etc.

never trust user

Des que t'as un champ ou l'utilisateur peut rentrer quelque chose, il faut le vérifier (genre si il doit rentrer un nombre mais que sans faire exprès il rentre aussi une lettre, il faut lui signaler et ne pas accepter la saisie pour ne pas faire planter le programme par exemple).

Aprés, t'as le cas d'une appli en ligne (jeu ou logiciel en ligne) ou là faut carrément se méfier du client et de tout ce qu'il envoie. (Quelqu'un peut très bien se connecter avec un client modifié pour exploiter certaines failles etc..)

Never Ever Trust User Input.

C'est la base. Tous tes champs doivent comporter des controles sur le type et le contenu des données.
Si tu attends un chiffre, tu auras des lettres.
Si tu attends une date, elle ne sera pas au bon format.
Si tu attend un texte, tu n'auras rien.

Si tu fais du web, ne te base pas sur les données du browser comme l'user agent ou le referer

Et quelque soit le champ, protège le aussi des injections de code, en plus de te premunir contre les données erronnées.

Donc pour repondre a ta question :

J'ai lu qu'il fallait se méfier de l'utilisateur du programme. Dans quels cas ?

Dans absolument tous les cas