+- 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 : Sécurité: Utilisation de logiciels tiers (/showthread.php?tid=7835)
Sécurité: Utilisation de logiciels tiers - MeTaLLiQuE - 09-07-2017
Bonjour,
Il me reste plus que quelques modules côté in-game et quelques modules côté panel admin avant que mon jeu ne soit terminé et qu'il puisse accéder au statut de Bêta et ouvrir officiellement mon jeu.
Pendant toute la durée du développement, j'ai testé, vérifié mainte et mainte fois mes fichiers afin de m'assurer qu'il n'y ait pas de faille (mais bon, le risque 0 n'existe pas, il doit y en avoir ^^).
Je me posais la question de : L'utilisation de logiciels de sécurité tiers payant est-il envisageable / intéressant ?
Plus généralement, utilisez-vous des logiciels tiers (genre HTTPCS.com) pour vous aider à démasquer quelques failles cachées ? Si oui, lesquels ?
Merci,
RE: Utilisation de logiciels tiers - Xenos - 09-07-2017
Salut,
pour ma part:
• Les services payants n'ont aucun intérêt pour des projets de jeu amateurs: il y aura bien plus intéressant à faire (ie: le coeur de métier, à savoir le gamedesign, l'équilibrage de jeu, le background, le gameplay, etc)
• Les services gratuit vont remonter des blindes de faux positifs, et peuvent servir pour les débutants qui n'ont aucune idée de "est-ce que je suis une passoire ou pas en fait?". C'est toujours un plus de savoir s'en servir (niveau CV, cela peut servir), mais il n'est généralement pas nécessaire d'y consacrer plus d'une soirée
• Les outils automatisés en général ne passeront pas la barrière d'un design sécurisé. Je ne connais *aucun* soft (gratuit ou payant) capable de faire l'analyse métier du code. C'est à dire qu'il y a des outils qui vont tenter des injections SQL pifométriquement (ceux-là sont simplement contrés par de bonnes pratiques de code), mais je ne connais *aucun* outil qui sera capable de te dire "tu as mal implémenté telle règle du jeu" ou "le joueur peut tricher en faisant telles actions". Ce sont des analyses à faire humainement (les éventuelles automatisations ne sont pas rentables pour des jeux amateurs)
Au final, une structure de code propre et "bien faite" permettra d'être quasi sûr de l'absence de faille système (ou failles d'implémentation, "dues au fait que le jeu est fait dans un ordinateur"). En revanche, pour être sûr de ne pas avoir fait d'erreur business (par exemple, un joueur qui peut faire un déplacement sans avoir les points d'action nécessaires) ni d'erreur de design (un joueur qui peut détourner une règle pour gagner un avantage), là, je ne connais pas d'outil fiable.
Les seuls qu'on pourrait te proposer, c'est "de faire des tests automatisés" (ie: un test qui met en place un jeu avec un joueur sans point d'action, qui tente de le déplacer, et qui vérifie que le jeu lui dit "non"), mais c'est totalement sur-dimensionné pour un jeu (en gros, compte 2x le temps de dev du jeu pour faire ces tests)
Pour ma part, la structure des projets me semble safe ( https://toile.reinom.com/prawd/ ) mais elle gagnerai éventuellement à être relue par un autre. En revanche, il traîne certainement des petites failles, que je corrige au fil de l'eau (exemple: Alucard m'a remonté qu'on pouvait poster un message dans une Roleplay Room de Iamanoc alors qu'on n'était pas dans cette room; la raison était simple: j'ai oublié d'implémenter cette règle, et là, il est très très compliqué et coûteux de vouloir le détecter automatiquement).
Pour info (donc, on n'a plus de côté subjectif dans les lignes suivantes), il existe des outils de sécurité qui ont souvent 3 approches: black box (le soft essaie de trouver une faille comme le pirate le ferait), whitebox (l'outil a accès à tout le code de l'application, et toutes les informations nécessaires), et greybox (un mix des deux). Au taff, l'outil whitebox (Checkmarx) qu'on nous a forcé à utiliser (pour raisons politique) ne sert à rien: beaucoup trop de faux positifs (le soft détecte une faille alors qu'il n'y en a pas) et beaucoup trop de faux négatifs (le soft ne détecte pas des failles qui pourtant existent). Au final, seul l'humain peut vraiment faire ce taff, et ça, ça coûte beaucoup de temps!
Perso, si tu veux que je te fasse une revue de sécu, je veux bien y consacrer un peu de temps (comme j'avais fait sur Medicinal Ganja [Buffalo Soldier! in the heart of America...] ou d'autres). Whitebox ou blackbox (ie: avec ou sans code source). Et comme je suis un commercial pourri, je demande rien en échange (mais du coup, je n'offre pas de garantie officielle
)
RE: Utilisation de logiciels tiers - MeTaLLiQuE - 09-07-2017
Yop,
Comme d'habitude : Merci pour la qualité de tes messages
.Ouais bon, en gros vaut mieux que je continue ce que je fais actuellement à savoir : Faire mes tests tout seul et m'amuser avec mes différents champs ^^
Je ne dirai pas non pour que tu y jettes un coup d'oeil à l'occasion quand il sera terminé
Merci encore
RE: Sécurité: Utilisation de logiciels tiers - Xenos - 09-07-2017
De rien. N'hésite pas à me contacter si besoin (Discord Xenos#8094 ou à défaut, par mail xenos alouette reinom.com).
N'attends pas trop que "le jeu soit terminé", car en pratique cela n'arrivera jamais
Et plus tôt les problèmes de structures/d'archi seront trouvés, plus tu pourras les corriger aisément (souvent, si l'archi est simple et bien pensée, les failles ne sont que des "erreurs d'étourderies", qui se voient facilement et se corrigent encore plus vite).
RE: Sécurité: Utilisation de logiciels tiers - MeTaLLiQuE - 10-07-2017
Je viens de t'envoyer un mail
Fais ça quand tu peux hein, pas pressé
RE: Sécurité: Utilisation de logiciels tiers - Xenos - 13-07-2017
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.