Le contenu suivant couvre divers concepts et tactiques pour améliorer la sécurité et atténuer la triche dans vos jeux Roblox. Il est fortement recommandé à tous les développeurs de lire ces informations pour s'assurer que vos jeux sont sécurisés et équitables pour tous les utilisateurs. Consultez la barre latérale pour des sujets de sécurité supplémentaires.
Avant de plonger dans des tactiques spécifiques pour développer de manière sécurisée et prévenir la triche, il est essentiel de comprendre les principes fondamentaux de la sécurité Roblox. Un jeu sécurisé repose sur un état d'esprit qui anticipe les actions adversariales. Avant d'écrire une seule ligne de code, vous devez internaliser ces principes fondamentaux. Ils doivent informer chaque décision architecturale et de conception que vous prenez.
Ne jamais faire confiance au client
C'est le principe fondamental. Un exploiteur déterminé a un contrôle total sur son état local et le trafic réseau. Étant donné que les exploiteurs ont ce niveau de contrôle, toute mesure de sécurité qui repose sur l'application côté client sera finalement contournée. Ce n'est pas une limitation de Roblox : c'est une réalité fondamentale des architectures client-serveur. Supposons que chaque morceau de données envoyé par le client a été manipulé, fabriqué ou envoyé avec une intention malveillante. Cela inclut le pouvoir de :
- Décompiler tout LocalScript ou ModuleScript répliqué, même s'ils ne s'exécutent jamais sur le client
- Prendre le contrôle réseau de leur personnage et de toutes les parties non ancrées
- Déclencher des événements initiés par le client tels que des événements Touched ou des activations de ProximityPrompt à n'importe quelle portée ou fréquence
- Modifier la position de leur joueur, la physique ou les interactions avec le monde
- Déclencher ou invoquer des RemoteEvents et RemoteFunctions à n'importe quelle fréquence avec des arguments arbitraires (à l'exception du premier argument Player)
- Changer quoi que ce soit dans leur DataModel local sans déclencher d'événements attendus
- Altérer arbitrairement le comportement de tout code s'exécutant localement
En raison de cela, toute logique critique doit être validée côté serveur ou exécutée exclusivement sur le serveur. Les conséquences de ce contrôle sont détaillées dans Network Ownership, Movement Validation, and Physics Exploits et Access Control and Confidentiality.
Autorité du serveur
Le serveur doit être la source ultime de vérité pour tous les états de simulation, règles, progression des joueurs et décisions critiques. Le rôle du client est de rendre le monde et d'envoyer les entrées utilisateur au serveur.
Le rôle du serveur est de :
- Recevoir les entrées du client
- Valider que l'action demandée est possible et permise
- Exécuter l'action et mettre à jour son état autoritaire
- Répliquer les résultats à tous les clients concernés
Par exemple, si un joueur dit "Je veux acheter un Bloxy Cola", le serveur doit connaître le vrai prix de l'article, l'argent du joueur et la distance physique du personnage du joueur par rapport au magasin avant de valider et d'approuver la transaction. Autant que possible, l'état à valider doit être maintenu exclusivement par le serveur et non par les clients. Dans l'exemple, si la transaction de Bloxy Cola est approuvée, le serveur doit soustraire le prix du Bloxy Cola de l'argent du joueur, cependant, le serveur ne peut pas nécessairement toujours contrôler le personnage du joueur.
Sécurité par conception
Intégrez les considérations de sécurité dans la conception de votre jeu dès le début, plutôt que d'essayer de les ajouter plus tard comme une réflexion après coup.
- Modélisez les menaces de chaque nouvelle fonctionnalité. Pour chaque nouvelle fonctionnalité, demandez-vous :
- Comment un attaquant pourrait-il exploiter cela s'il a un contrôle total de son client ?
- Si un client pouvait envoyer n'importe quelle valeur pour n'importe quel paramètre utilisé dans la fonctionnalité, quel serait le pire résultat possible ?
- Que se passe-t-il si cette fonctionnalité est utilisée plus de 1 000 fois par seconde ? Quelle est la fréquence maximale à laquelle elle devrait être utilisée ?
- Un exploiteur pourrait-il utiliser cela pour ruiner l'expérience d'un autre joueur ?
- Combien de ressources, dans le pire des cas, cette fonctionnalité pourrait-elle raisonnablement utiliser ?
- Quelle est la quantité minimale d'informations internes ou d'état que je dois exposer pour cette fonctionnalité ?
- Partitionnez les responsabilités dès le début. Gardez la logique et les données dans ServerScriptService dès le premier jour. Ne les placez jamais dans des conteneurs répliqués comme ReplicatedStorage ou Workspace.