+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Défi sécurité. (/showthread.php?tid=2359)
RE: Défi sécurité. - keke - 06-02-2008
Une solution pourrait-elle être d'avoir un serveur de meilleur qualité pour éviter des problèmes de latence ?
N'existe-t-il pas une option Apache ne tolérant qu'un seul traitement à la fois ?
J'avoue que je suis pas assez calé dans le domaine pour l'appréhender correctement, mais il serait interressant pour tous de trouver une (la) solution la plus optimum.
kéké.
PS : Il est vrai que les tricheurs sont malins, mais l'idée n'est pas tant de blinder son application contre toute triche, que de mettre en place un système pour les repérer. Quelques exemples sur mon jeu : le multi-compte n'est pas interdit, mais toutes mes fonctions sont prêtes pour les détecter ; La progression (xp, carac, argent) des joueurs est sauvegardé régulièrement. Je peux ainsi rapidement voir les joueurs qui gagnent trop et tracer leurs historiques (sur 7 jours).
RE: Défi sécurité. - uriak - 06-02-2008
Et comment faites-vous pour tracer la progression ? Des tables avec entrée à chaque date ? des fichiers de logs ?
RE: Défi sécurité. - Roworll - 06-02-2008
De mon coté, je stocke dans des fichiers textes au format CSV.
Pour l'analyse,; il me suffit de récupérer le fichier puis de l'importer via Excel pour travailler dessus.
RE: Défi sécurité. - keke - 06-02-2008
Base de donnée avec joueur, jour, avancement dans chaque domaine (sous format numérique).
Depuis migration GET -> POST je n'ai pas vu de joueur tricher ... mais je recoupe pas les multi-comptes ...
Salut !
Kéké.
PS : j'évite autant que possible le fichier plat.
RE: Défi sécurité. - NicoMSEvent - 06-02-2008
Citation :j'évite autant que possible le fichier plat.surtout que excell est limité a 65.535 lignes... (je dépasse les 100.000 lignes de log par mois :p)
pour le moment, je trace que la durée d'exécution des requetes, leurs fréquences, et celles qui ont échoués.
RE: Défi sécurité. - Roworll - 06-02-2008
Pour le moment, j'atteins péniblement les 200 lignes par semaine (Version de Developpement oblige)
Comme il est vrai que Excel est limité, j'ai prévu d'utiliser LogParser pour la suite.
Je m'en suis déjà servi au boulot, c'est assez cool.
RE: Défi sécurité. - Amrac - 09-02-2008
Pour tracer la progression, je charge en local les sauvegardes de ma base de données et j'ai un script qui switch entre les sauvegardes pour comparer ce que le joueur possède à différent moment et déterminer si c'est possible ou non.
Sinon pour la solution:
keke a écrit :Une solution pourrait-elle être d'avoir un serveur de meilleur qualité pour éviter des problèmes de latence ?Ca signifierais que tu sois obligé de baisser la charge maximal de tes serveurs. Tu augmente donc significativement ton ratio Joueurs/Dépense serveur.
De plus, ca ne ferait que réduire la probabilité que ca ce produise. Même si tu as un très bon serveur, les joueurs risque de te le saturer quand même en spammant.
uriak a écrit :Pour ce cas particulier il y a une autre solution : ne pas détruire/créer d'armée, mais l'affecter à une attaque ou à un joueur. Il n'y a plus de "créer" ni de "DELETE" seulement un "UPDATE" qui s'il est appelé 2 fois ne sera pas dramatique. Par contre ça oblige à réviser le schéma SQL derrière...L'idée est bonne, mais comme tu le dis, c'est du boulot, et ce n'est valable qu'ici...
Comme possible solution je retient:
-Les transactions. Je les utiliserais personnellement sous forme de "mini-transaction". Le select et le delete à la suite.
-En cas de problème, s'arranger pour que la situation soit défavorables aux joueurs. Ca diminue de façon drastique les tentatives, mais par contre vous allez avoir de temps en temps des innocents qui vont se plaindre sur votre forum. (vécu)
-Effectuer les deletes immédiatement aprés le select quand c'est possible (ca rejoin un peu le premier point).
Aprés réflexions, voici la solution que je vais implémenter:
En début de script, avant même la connexion à la BDD, j'instaure un système de vérou via la session.
Le script ressemblera globalement à ca:
Code PHP :
<?php
if(isset($_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']])) //Si on à déjà accéder à cette page.
{
if($_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']] > time()) //Si le verrou est encore fermé, il s'agit d'un spam
{
echo 'Merci de patienter, traitement en cours.';
$_SESSION['penalite']++;//A chaque spam, je lui met une seconde d'attente en plus.
exit();//On casse l'execution de la page.
}
}
//Si on arrive jusqu'ici, alors le verrou n'est pas fermé. On enregistre la date d'expiration du nouveau verrou, en prenant en compte les éventuels pénalitées.
$_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']] = time() + 2 + $_SESSION['penalite'];
Vue que la toute premiere chose faite est de mettre le verrou, je pense limiter les accés concurrent aux scripts, de plus je décourage rapidement les joueurs avec des délai d'attente toujours plus long s'il tente de forcer le script. (pénalités)
Je vais y ajouter un système de session unique. Finit les doubles (voir triple) session pour tout péter.
Le principe est simple, chaque session posséde un Identifiant de session, lors de la connexion d'un joueur, j'enregistre l'identifiant de session du joueur dans la base de données.
A chaque page, je vais vérifier que l'identifiant de session correspond toujours a celui inscrit dans la BDD. Si ce n'est pas le cas, je lui affiche un message d'erreur du style "Quelqu'un viens de se connecter sur votre compte.", et je détruit sa session.
Au niveau économie de ressource, je dispose déjà d'une requete faite sur toutes les pages pour vérifier si le joueur a de nouveau message. En pratique, c'est un simple select qui prend le champ 'NbrMessageNonLu' dans la table Membre. J'ai donc juste a ajouter la selection de l'identifiant de session, ce qui n'est pas un problème.
Beaucoup de jeux font des actions récurrentes a chaque page, comme l'affichage du nombre de ressources, je pense que vous pouvez facilement trouver une requête où y greffer l'identifiant de session sans avoir besoin de créer une nouvelle requête.
Je pense qu'avec ces deux script, je bouche la faille sans manger de ressource, qu'en pensez vous?
Désoler pour les postes hyper long, mais j'ai un conseil a vous faire partager:
Lorsque vous bannisez des tricheurs, ne donnez jamais la moindre indication sur le bug. Même si celui-ci est corrigé. Il y a 6 jours environ, en justifiant la raison des bans, j'ai expliqué comment ils ont produit le bug. Le script mis en cause étant désactivé, je me suis pas fait de soucis. Or, depuis que j'ai expliqué le bug, le serveur subit de rude montés en charge jusqu'ici jamais atteintes, alors que le trafic n'as pas changé.
Je vous dirais une fois le système anti-spam si c'est revenu à la normal...
RE: Défi sécurité. - Plume - 09-02-2008
Je trouve que c'est plutôt ingénieux. Pour ma part, je ne vois pas de contre à cette mesure. Peut-être que d'autre trouveront quelque chose. Les ID de sessions sont couramment utilisés. Donc là par contre, c'est pas trop trop inconnu
Pour les charges serveurs, après les changements, avertis de la mesure que tu as prises en évoquant les sanctions encourues à chaque tentative de triches. Trace les actions à ce niveau pour le repérage, mais j'crois savoir que tu le fais déjà
L.
RE: Défi sécurité. - NicoMSEvent - 09-02-2008
Citation :Je vais y ajouter un système de session unique. Finit les doubles (voir triple) session pour tout péter.ça j'utilisais déjà pour éviter que quelqu'un soit connecté 2x à deux endroits différents.
Le principe est simple, chaque session posséde un Identifiant de session, lors de la connexion d'un joueur, j'enregistre l'identifiant de session du joueur dans la base de données.
A chaque page, je vais vérifier que l'identifiant de session correspond toujours a celui inscrit dans la BDD. Si ce n'est pas le cas, je lui affiche un message d'erreur du style "Quelqu'un viens de se connecter sur votre compte.", et je détruit sa session.
Les id de sessions me servent aussi pour détecter les multi-comptes :
entre 2 connections, je vide la session, mais je ne la détruit pas.
Si la personne se reconnecte avec un autre compte, j'ai 2 comptes avec le même ID de session, et il me suffit de rajouter une ligne dans le log quand c'est détecté. C'est aussi bête que ça
RE: Défi sécurité. - LittleQI - 09-02-2008
Je viens proposer ma solution.
Dans tous les autres langages quand on ne veut pas qu'un script soit executé 2 fois en meme temps, on utilise tout simplement les MutEx (Exclusion Mutuelle). Hors à ma connaissance pas de MutEx en PHP mais par contre il y a les Sémaphores (et le MutEx n'est rien d'autre qu'un semaphore binaire).
Il suffit de s'en servir ainsi
Code PHP :
<?php
$semaphore = sem_get(1); //on recupere la semaphore qui a la clef 1
sem_acquire($semaphore); //on essaye de recupérer le semaphore, si celui ci est deja pris, le code patientera ici jusqu'à ce qu'il se libère
//ici le code critique
sem_release($semaphore); //on libère le semaphore pour qu'unautre utilisateur puisse le récupérer
Voila, ça permettra donc d'executer ton code critique jamais deux fois en mme temps sur ton serveur. Encore mieux, si tu veux tout simplement que ce ne puisse pas etre executé 2 fois en meme temps uniquement par le meme utilisateur, il te suffit de mettre l'ID du joueur en clef de semaphore.
Je ne l'ais encore jamais utilisé en PHP mais dans d'autres langages. Mais aux vues du manuel PHP (http://fr2.php.net/sem) c'est bien comme ça que fonctionnent les semaphore dans ce langage.