13-07-2017, 11:42 AM
incodewetrust a écrit :Salut,
Par rapport à ce sujet, http://www.jeuweb.org/showthread.php?tid=11912, ou j'ai préférer ne pas m'incruster pour garde une bonne visibilité, je voulais savoir, au vu de ton expérience, ce que tu pensais des scan réalisé via des logiciel de type vega pour tester la sécurité de ses propres jeux.
J'ai utilisé ce logiciel sur mon jeu sans trouver de faille (enfin des très légère sur des outils externes tel le forum) mais et je voulais savoir du coup dans quelle mesure je pouvais me fier à ces résultats et voir quelles solution légères tu recommanderais au niveau sécurité d'un petit jeu web. Je parle bien de sécurité "extérieure" (niveau contrôle des données pour éviter la triche je considère que c'est ok).
Sachant qu'actuellement il y'a PDO et requêtes préparer pour éviter les injections sql, htmlspecialchar des sorties à risques (champs de type texte). J'ai lu qu'il y avait des procédure de token qui pouvaient être mises en place contre le vol de session et compagnie mais cela ne m'a pas semblé approprié par rapport à la problématique d'un petit jeu web à priori peu/pas exposé à ce type d'attaques. Ceci dit, je me trompe peut-être.
Par contre je pense être insuffisamment préparé à contrer des attaques de type bruteforce qui pourrait davantage être une menace légitime (robot ou joueur cherchant à récupérer le mot de passe d'un rival 1) et du coup je m'expose sans doute à du DDOS. Comme je suis sur mutualisé je me dit que le DDOS est aussi géré par mon hébergeur mais il y'a peut-être des choses à faire à mon niveau.
Voila aucune urgence et n'hésite pas à me dire si tu n'as pas le temps ou autre.
Je te quote, car je pense que les discutions sont toujours plus instructives en publiques qu'en privé (ie: le prochain qui se pose la question, ou n'en avait même pas eu l'idée, pourra y trouver de l'intérêt). L'intention de ne pas vouloir rendre les sujets "bordéliques" est bonne, mais moi, je n'ai aucun scrupule à le faire
J'aime mieux le bazar (même si, ici, je pense que cela reste assez dans le sujet initial pour ne pas être considéré comme "bordélique") que l'absence d'info.Bref, passons à ma réponse:
Vega, je ne le connais pas. Mais le Checkmarx qu'on a au taff sert surtout à cocher des cases "False Positive". Pour ma part, je trouve ces logiciels inutiles. Ils peuvent être éventuellement intéressants pour des gros projets d'entreprises (et encore!) mais sur du petit jeu web, ils font faire perdre du temps pour rien (installation, prise en main, lancement des scans, planning de scans réguliers, vérification des rapports régulièrement, etc... tout ça bouffe du temps). A la limite, si l'outils est déjà maîtrisé, il peut être mis en place (car le coût devient quasi nul). Par exemple, j'ai mis SonarQube sur mes projets, qui sert plus la propreté du code que la sécurité même s'il peut servir à détecter certaines erreurs de ce style. Je ne l'ai pas tellement mis parce que c'est "rentable" ou "intéressant", mais juste parce que je savais le faire au taff, donc, 2h pour le refaire à la maison et c'est plié (et divisé par mon nombre de projets, cela devient encore plus rentable!).
Ce qui est rentable, c'est de comprendre quelques règles de base de sécurité (j'essaierai de faire un article plus concrêt là dessus, si besoin; en attendant, tu devrais trouver quelques éléments de base dans ce qui existe https://toile.reinom.com ).
En pratique, 3 règles suffisent à solder la quasi totalité des failles:
• Injection => séparer les données des commandes [ie: requêtes préparées, templates] ou encoder les données quand on les insère dans un flux de commandes [ie: htmlentitites, XSS]
• Client/Server total separation => checker toute entrée serveur [ie: POST, GET, mais aussi paramètres de procédures stockées côté SQL], toute entrée client [ie: données traitées par le JS], et éventuellement les sorties [ie: redirections]), ne pas présumer qu'une requête cliente a été volontaire [ie: XSRF]
• Don't do custom security => Utiliser les lib et méthodes/process existants, surtout niveau session, authentification, mot de passe
Quand ces règles sont respectées, on est quasi sûr d'être safe, sutout pour des jeux web amateurs où on aura plus de chances de croiser un WhiteHat qu'un BlackHat (et dans ce cas, le bannir reste possible sans trop de soucis).
Après, ce sont des problèmes de failles métier (vérifier que les règles du jeu sont bien codées et appliquées, et qu'on ne peut pas les détourner).
Pour répondre plus spécifiquement au token, pour un jeu web amateur, c'est probablement surfait. Une requête POST est nécessaire dans tous les cas, mais pas le token. EN revanche, les actions critiques comme la suppression du compte, pourraient avec un token. Mais tu peux te contenter d'un token "figé", stocké en BDD et lié au compte du joueur (cela suffira pour mitiger les éventuelles attaques).
Enfin, pour le bruteforce et le DDOS, je procède comme toi: OVH se débrouille et le mitige. J'ai parfois des pics dans mes stats qui indiquent que l'hébergeur s'est chargé de trouver les parades nécessaires. Je n'ai donc jamais eu de soucis de mon côté. Sans compter que si j'en ai, je peux sans soucis restaurer la BDD, ou delete les messages spammés, etc. La malveillance est quand même rare dans un jeu web amateur, et même si des joueurs frustrés peuvent devenir malveillants, cela ne durera souvent pas.