Sécuriser un jeu en ajax?

bonjour,

j'expérimente un jeu en javascript, avec stockage des scores coté serveur.

dans mon code js j'ai introduit le code suivant, lorsqu'un coup du jeu est exécuté:

$.ajax({
  url : "hello.php",
  data : { piecesGood : correctPieces, nbreCoups : nombreDeCoups },
  type : "post"
});

le fichier hello.php est tout bête pour l'instant:

<?php 
echo "correct-pieces: ". $_POST['piecesGood'];
echo "nombre de coups: ". $_POST['nbreCoups'];
?>

donc quand mon code ajax est appelé, je récupère bien les deux variables dans le fichier php et je pourrais donc en faire ce que je veux.

Cependant, je me suis amusé à taper ceci dans la console de Firebug:

$.ajax({
  url : "hello.php",
  data : { piecesGood : 12, nbreCoups : 60 },
  type : "post"
});

et bien sur mes valeurs 12 et 60 sont envoyées vers le serveur.... ce qui présente une faille de sécurité évidente...

Peut on résoudre ce genre de problème lorsque l'on utilise les techniques ajax?

Merci

Salut.

Je t'avoue que je ne me suis jamais amusé sur du post en ajax, mais ça ressemble un peu à une faille CSRF. Peut-être pourrais-tu chercher à ajouter un jeton dans ton post ajax ? Mais il faudrait le créer en php, l'envoyer en js, pour le reposter en php, c'est un peu tirer par les cheveux.

SolidSnake a écrit :
Salut.
Je t'avoue que je ne me suis jamais amusé sur du post en ajax,

ça serait pire avec du get, surement !

SolidSnake a écrit :
Salut.
Peut-être pourrais-tu chercher à ajouter un jeton dans ton post ajax ? Mais il faudrait le créer en php, l'envoyer en js, pour le reposter en php

mais alors je l'envoie en js de quelle façon?

La meilleure solution que je vois c'est de crypter tes données, pour éviter une manipulation trop simple.

Je m'étais penché déjà sur la question et j'étais tombée sur le système Jcryption : http://www.lafermeduweb.net/billet/jcryption-encryptez-les-donnees-passees-en-get-et-post-avec-jquery-525.html

Donc cryptage en javascript et décryptage coté php 4 derrière ^^

lionel_css3 a écrit :
mais alors je l'envoie en js de quelle façon?

Tu pourrais la récupérer en Ajax au format JSON par exemple.

Sinon à voir effectivement si tu peux crypter tes données comme le suggère Lothindil.

Jeton ou cryptage, ça n'empêchera pas le joueur de manipuler les données comme il veut. Il peut le faire avant le cryptage, ou tout simplement utiliser la même méthode de cryptage.

Pour de la sécurité, il faut déporter la logique du jeu sur le serveur, ou au moins la valider sur le serveur. Dans le cas présent, j'ignore le type de jeu, mais vu qu'on a un nombre de coups, il y a quelque chose de possible. Envoyer au fur et à mesure chaque coup au serveur, ou alors stocker chaque "coup" en js et envoyer la liste au serveur qui validera. (on pourra toujours envoyer au serveur quelque chose que l'on a pas fait, mais si on a la liste des coups pour obtenir le meilleur score, on a plus besoin de tricher )

kustolovic a écrit :
Dans le cas présent, j'ignore le type de jeu, mais vu qu'on a un nombre de coups, il y a quelque chose de possible.

Le jeu c'est la transposition d'un puzzle coulissant, composé d'une grille de cases que l'on peut déplacer une par une dans les directions x et y, avec un trou dans la matrice des cases pour permettre le déplacement.(l'illustration montre la version "physique" du puzzle)
C'est le projet n°1 du très bon livre jQuery Hotshots



et si je change le nom de variables par des chaines du genre ngt-ty48DerRRraqqp78jiDDeErt et si je supprime tous les retours chariots pour rendre le code illisible, ça peut le faire aussi?
Je crois qu'il existe des utilitaires pour ça, des scambleurs de javascript..

(edit) ... le vrai nom est "jeu de Taquin"
Modifié par lionel_css3 (06 Dec 2013 - 09:52)

Le mieux seraient de ne pas envoyer le score, mais bien les coups.

La structure que je ferais :
-> en session tu mets la matrice de base. dans un array par exemple

$array = array(
0=>array('x'=>3,'y'=>1),
1=>array('x'=>3,'y'=>2), 
2=>array('x'=>1,'y'=>3),...
)

Avec 0 qui est la case vide et 1 à ... qui sont tes cases, dans l'ordre qu'elle devrait avoir au final.
Tu places aussi une variable de sessions "coup" que tu fixes à 0

-> A chaque coup, tu envois en javascript la case qui bouge.

-> coté serveur, tu vérifies que cette case est bien adjacente à la case vide (X+/-1 ou Y +/-1)
--> Si non, tu génères une erreur.
--> Si oui
-->-> Tu changes les données dans la session (inversion des coordonnées de 0 et de la case en question),
-->-> Tu incrémentes la variable des coups
-->-> Tu vérifies si le puzzle est fini. S'il est fini, tu calcules le score, tu l'ajoutes en BDD
-->-> Tu renvois au javascript qu'il peut faire le changement d'image
-->-> Si le puzzle est fini, tu ajoutes au js l'affichage du score.


Et oui, c'est relou à faire, ça peut ralentir un poil le javascript, ça revient à faire un jeu php avec du javascript, mais à part en faisant confiance au serveur, j'ai jamais trouvé de véritable technique sécurisée... (je passe mon temps à faire ça pour mon jeu...)

a écrit :
et si je change le nom de variables par des chaines du genre ngt-ty48DerRRraqqp78jiDDeErt et si je supprime tous les retours chariots pour rendre le code illisible, ça peut le faire aussi?
Je crois qu'il existe des utilitaires pour ça, des scambleurs de javascript..

En français ça s'appelle des obfuscateurs. Mais ça revient au même que du cryptage, ça complique la triche sans pour autant la rendre totalement impossible.

Je plussoie kustolovic sur l'idée de fond.

Le navigateur, à l'origine, c'est juste un client totalement débile qui affiche tout ce que, et seulement ce que, le serveur lui demande d'afficher. Dès le moment où tu dotes le client d'une quelconque forme d'intelligence, tu lui donnes aussi par la même occasion la possibilité d'altérer cette intelligence, de la pervertir à son avantage . . . et donc de tricher à ton jeu; quelque soit les mécanismes de cryptage ou d'obfuscation que tu auras pu mettre en place.

Moralité, le seul moyen d'empêcher les gens de tricher est de faire en sorte que le client reste débile. La version extrême, ça veut dire, ne faites pas de jeu en js, ou limitez-vous à transmettre les input/output et rien d'autre sans donner aucune information sur la logique du jeu.
Modifié par QuentinC (06 Dec 2013 - 14:54)

est ce que avec node.js on pourrait, dans un cas comme celio là, cacher le code sur le serveur?

node.js, php, java, asp, ou tout autre langage serveur ne changera pas le problème, car ça n'a rien à voir avec le javascript qui est envoyé et exécuté par le client.

Il faut comprendre que l'on est plus possesseur du code une fois envoyé.

Pour faire un parallèle, imaginons qu'on envoie un jeu et des règles de jeu par la poste à quelqu'un, et qu'il nous transmette ses résultats par retour de courrier. Pour certains jeux, comme celui-là, cela reste possible, en demandant à la personne de renvoyer non pas le résultat final, mais la méthodologie utilisée pour résoudre le problème. Grâce à cette méthodologie, le serveur peut calculer un score.
Certains jeux se prêtent à ce genre de vérifications, d'autres pas.

Par exemple, je ne peux pas envoyer par la poste un jeu de fléchettes et vérifier que la personne a bien mis 5 fois au centre. En web, un jeu d’adresse ou de vitesse aura le même problème.

Pour les jeux video "classiques" sous forme d'application lourde, le jeu étant toujours exécuté chez le client, il reste toujours un risque (en allant grailler dans la mémoire RAM). Mais le code étant compilé et les sources non-publiques, il est simple de mettre en place quelques sécurités qui montent tellement la complexité d'une triche que ses possibilités tendent vers 0.
En javascript c'est impossible. Le code est opensource, et même en mélangeant toutes les techniques évoquées, on garde un risque non-négligeable.

Il reste néanmoins d'autres solutions:
– Accepter la triche.
– Avoir un système basé sur la confiance et la communauté, et virer les cas problématiques.
Modifié par kustolovic (06 Dec 2013 - 16:03)

a écrit :
Il reste néanmoins d'autres solutions:
– Accepter la triche.
– Avoir un système basé sur la confiance et la communauté, et virer les cas problématiques.

Ne compte pas sur la confiance de la communauté.

Dans le cadre d'un projet personnel, je fais tourner un jeu online avec 14000 joueurs. JE laisse une seule petite faille même assez bidon et je peux être sûr que quelqu'un me la trouve et l'exploite en 100 fois moins de temps qu'il ne faut pour la débusquer moi-même ou par la test-team et la débugger ensuite.

ET pour virer les cas problèmatique, ce n'est pas si simple malheureusement. La plupart des tricheurs/abuseurs s'y prennent comme des pieds / ne connaissent pas toutes les subtilités de l'informatique, donc sont plutôt faciles à bannir, mais il en reste toujours quelques-uns qui sont plus malins que toi pour passer toutes tes barrières et s'ils ne sont pas content, il y a une probabilité non nulle qu'ils reviennent pour pourrir tout le monde.
Modifié par QuentinC (06 Dec 2013 - 17:35)

En même temps, je n'ai jamais dis que c'était facile.
C'est possible, mais ça doit passer par plein de processus, de responsabilisation, d'écrèmage (viser une communauté spécifique, pas la quantité), d'appropriation, de communication (il faut trouver le bon ton, la bonne manière), etc. Il y a des cas de succès sur le net. Mais aussi beaucoup ou ce n'est pas le cas. Je ne l'ai jamais fait et ne pense pas en être capable d'ailleurs…

Lothindil a écrit :
La meilleure solution que je vois c'est de crypter tes données, pour éviter une manipulation trop simple.

A chaque fois que quelqu'un crypte des données un bébé cryptographe meurt.

a écrit :
A chaque fois que quelqu'un crypte des données un bébé cryptographe meurt.

Je ne comprends pas.

En Français on chiffre.

paolo a écrit :
En Français on chiffre.

Absolument. D'ailleurs on ne dis pas applet mais appliquette, on ne dit pas boot(strap) mais amorce, on ne dit pas spamming mais arrosage, on ne dit pas jingle mais indicatif, on ne dit pas hacker mais fouineur, on ne fait pas du push mais de la distribution sélective, on n'utilise pas un object oriented language, ni même un langage orienté objet, mais un langage à objets, on ne fait pas de l'opt-in ou de l'opt-out, mais de l'option d'adhésion ou de l'option de retrait, on ne dit pas registrar mais registraire, on ne dit pas world wide web, www ou web mais toile d'araignée mondiale ou TAM (t'es allé à ParisTAM cette année? J'implémente des TAM-services, je bosse dans le TAM, je suis intégrateur), et si on est tatillon on ne fait pas du HTML ou du CSS mais du LBHT ou de la FSC.

Ou alors on peut préférer juste communiquer dans un français «living standard».

@kustolovic

Non, chiffrer est le terme correct à employer, adopté par l'ensemble des publications et des professionnels de la discipline, d'où la remarque de jb_jfx et ma précision.
Ta remarque est d'autant plus hors de propos que les verbes anglais sont to encrypt et to cypher.

Mais libre à toi d'employer le terme qui te sied.
Modifié par paolo (08 Dec 2013 - 22:03)

chiffrer : encoder des données en utilisant une clé de chiffrement
déchiffrer : décoder des données à l'aide de la clé de chiffrement
decrypter : décoder des données sans connaitre la clé de chiffrement
crypter : encoder des données sans connaitre la clé de chiffrement ?!?

crypter est un non sens, ce mot ne veut absolument rien dire. Et comme l'a dit paolo, en anglais c'est encrypt et pas crypt (sauf en PHP )
Modifié par jb_gfx (08 Dec 2013 - 22:35)

Bah, c'est juste qu'il semble y avoir une sorte de guerre en France contre les termes «crypter, cryptage» dans une sorte de chasse aux sorcières à l'anglicisme (et pourtant c'est du grec Oo)

crypter: rendre un message secret.
chiffrement: procédé de cryptologie basé sur le remplacement d'un caractère(ou un autre élément de base) par un autre souvent à l'aide d'une clé.

Et «crypter» qui est un mot reconnu par son usage est un terme parfait adéquat dans une discussion informelle:

«Peut-être, si je crypte mes données cela pourrait fonctionner. Vous me conseillez de les chiffrer ou d'utiliser une autre méthode?»

Enfin bon ça devient un poil hors de propos et idéologique comme débat