Bonjour à tous !
 
Avant de détailler ma question, j'explique un peu sur quoi je travaille
Je collabore à la création d'un jeu de création de ville. Pour construire certains bâtiments, des vérifications de technologies sont nécessaires.
Ces vérifications sont faites une première fois lors de l'affichage de la page (si les technos sont pas disponibles, le bouton de construction n'apparaît pas).
Bon je simplifie un peu, c'est juste pour que vous imaginiez.
 
 
En théorie, un joueur malintentionné pourrait copier mon code source généré et le bidouiller pour envoyer au serveur un ordre de construction bien que les conditions ne soient pas satisfaites.
 
Cependant, j'ai mis ce code en tête de toutes mes pages :

et ensuite tout le traitement, l'affichage...
 
la variable $_SESSION['sessid'] est générée lors de la connexion.
Donc théoriquement, ils ne peuvent pas envoyer leur propre formulaire...si ?
 
 
Du coup, ai-je besoin de vérifier qu'ils possèdent bien les technos lors du traitement du formulaire ?

leur propre formulaire => Quel formulaire ?

Ok je suis pas clair    
 
Imaginons que lors de la génération de la page j'ai un formulaire dans lequel un bouton permettant la construction ne soit pas présent car le joueur ne possède pas les technos requises.
 
Le joueur peut copier ce formulaire et ajouter le bouton lui-même puis envoyer ce formulaire "modifié" non ?

bah ils peut modifier tous les champs POST, même les hidden quoi

Voilà mais étant donné le code que j'ai indiqué, je voulais savoir s'il a toujours cette possibilité d'envoyer son propre formulaire ou s'il va être éjecté par le if de la ligne 6.
 
Pour moi, la réponse est oui (il va être éjecté) mais je ne suis pas un pro de la sécurité,loin de là, y a peut-être un truc qui m'a échappé et qui pourrait lui permettre de passer à travers ce if et donc envoyer tout ce qu'il veut...
 
Ça me permettrait d'éviter des requêtes qui du coup deviendraient inutiles.

nop, ton IF ne laisse pas passer les usurpations d'identité si tu veux tout savoir

Ok ça va m'éviter du boulot redondant.
 
Merci !

Euh, ce bout de code n'empêche pas d'envoyer son propre formulaire... il vérifie juste qu'on envoi bien le cookies de session qu'on s'est vu attribué à la connexion.
Tu dois vérifier à nouveau que les règles du jeu sont respectées lors de la réception du formulaire. Ne jamais faire confiance aux données provenant de l'extérieur !

Mais si cet identifiant de session n'est pas envoyé (ou ne correspond pas), le joueur est redirigé vers la page d'accueil.
 
Donc les données ne sont pas traitées...ou je me trompe ?
 
Ok j'ai compris en faisant un petit test : même sans connaître la variable de session on peut envoyer le formulaire (tant que la session n'a pas été fermée). Donc mon truc protège du vol de session mais n'empêche pas les malins de trafiquer leur compte.
 
Il ne me reste plus qu'à tout vérifier    
 
Merci à toi donc d'avoir amené le doute  

Il faut toujours tout vérifier. Avec une extension FireFox comme Tamper Data ou un prog genre Fiddler, on peut intercepter la requête HTTP (donc avec identifiant de session et tout), et modifier les valeurs des champs avant envoi.
 
Ou alors on peut toujours faire un formulaire customisé. Vu que la requête sera envoyée à ton serveur, le navigateur incluera les cookies éventuellement présents, donc l'identifiant de session. Pour se protéger de ça (c'est une faille baptisée CSRF, Cross-Site Request Forgeries), il faut générer un token unique qui sera mis en input hidden. Et vérifier lors de la réception de la requête que ce token existe et est valide. Ainsi un formulaire bricolé ailleurs n'incluera pas ce token et sera donc invalide.

Je viens de me renseigner un peu à ce sujet et de cogiter 2 minutes.
 
Par rapport au token : je ne vois pas en quoi il empêche une personne de bricoler un formulaire. Bien sûr ce sera plus gênant mais il lui suffit d'afficher le formulaire, prendre le token dans le source HTML et le mettre dans son formulaire à chaque fois
 
Sinon, ben oui ça y est je suis en train de rajouter les vérifications dans le traitement de mon formulaire. Heureusement j'en avais encore écrit que 2.

Je ne vois pas bien non plus comment le token peut empêcher ça... à part si le code du token est créé à partir des valeurs possibles possibles du formulaire, mais ça semble très compliqué ?

Nan justement, tu peux pas le prendre le token, vu qu'il est sur un autre domaine.
 
Genre imagine dans ton jeu t'as un bouton "supprimer ville." Pour supprimer une ville faut envoyer une requête POST sur http://tonsite/ville/suppression.php, avec dans $_POST un champ 'confirmer.'
 
Alors tu peux faire un formulaire sur un autre site simplement :

Le mec met ce formulaire sur son site, et t'envoie le lien par mail "hé regarde c'est super cool." Toi tu cliques et *boom* ta ville est supprimée.
 
Donc le truc est de rajouter un token unique, uniquement valable pour toi et ce formulaire. L'autre naze ne peut évidemment pas récupérer ce token, vu qu'il est à usage unique, et impossible à récupérer (étant sur un autre domaine).

Ok j'ai compris, merci pour les explications !

FlorentG > Certe ça protège des messages du genre "regarde comme c'est cool cette page" mais en quoi ça empêche le joueur de se rajouter le bouton permettant de créer une usine "high tech" alors qu'il en est encore à l'étape du "je créé la première ferme du village"? L'id de session sera le bon et le token aussi vu que le serveur lui en aura fournis qui sont valide.
 
bigcrunch > Si tu veux éviter les tricheurs alors fait tous les tests nécessaires même ceux qui ont déjà été fait pour créer la page précédente. Si tu veux à la fois éviter les tricheurs et éviter de refaire 36 fois la même requête, alors stocke toi les valeurs pertinentes dans la session.
Par exemple si tu stockes, dans la session, la liste des bâtiments que le joueur courant à le droit de créer, alors tu n'auras plus qu'à regarder dans la session pour savoir s'il y a tentative de création de bâtiment non autorisé.

Oui c'est sûr, mais comme on avait branché sur les formulaires externes