Der folgende Inhalt behandelt verschiedene Konzepte und Taktiken zur Verbesserung der Sicherheit und zur Minderung von Betrug in Ihren Roblox-Spielen. Es wird dringend empfohlen, dass alle Entwickler diese durchlesen, um sicherzustellen, dass Ihre Spiele sicher und fair für alle Benutzer sind. Überprüfen Sie die Seitenleiste auf zusätzliche Sicherheitsthemen.
Bevor wir in spezifische Taktiken eintauchen, um sicher zu entwickeln und Betrug zu verhindern, ist es wichtig, die grundlegenden Prinzipien der Roblox-Sicherheit zu verstehen. Ein sicheres Spiel basiert auf einer Denkweise, die feindliche Aktionen antizipiert. Bevor Sie auch nur eine Zeile Code schreiben, müssen Sie diese grundlegenden Prinzipien verinnerlichen. Sie sollten jede architektonische und gestalterische Entscheidung, die Sie treffen, beeinflussen.
Vertraue niemals dem Client
Dies ist das grundlegende Prinzip. Ein entschlossener Ausnutzer hat die vollständige Kontrolle über seinen lokalen Zustand und den Netzwerkverkehr. Da Ausnutzer dieses Maß an Kontrolle haben, wird jede Sicherheitsmaßnahme, die auf clientseitiger Durchsetzung beruht, letztendlich umgangen. Dies ist keine Einschränkung von Roblox: Es ist eine grundlegende Realität von Client-Server-Architekturen. Gehen Sie davon aus, dass jedes Stück Daten, das vom Client gesendet wird, manipuliert, gefälscht oder mit böswilliger Absicht gesendet wurde. Dies umfasst die Möglichkeit:
- Jedes replizierte LocalScript oder jedes ModuleScript zu dekompilieren, selbst wenn sie niemals auf dem Client ausgeführt werden
- Netzwerkbesitz über ihren Charakter und alle nicht verankerten Teile zu übernehmen
- Client-initiierten Ereignisse wie Touched-Ereignisse oder ProximityPrompt-Aktivierungen in beliebiger Reichweite oder Häufigkeit auszulösen
- Die Position, Physik oder Interaktionen ihres Spielers mit der Welt zu ändern
- RemoteEvents und RemoteFunctions mit beliebiger Häufigkeit und beliebigen Argumenten (außer dem ersten Spielerargument) auszulösen oder aufzurufen
- Alles in ihrem lokalen DataModel zu ändern, ohne erwartete Ereignisse auszulösen
- Das Verhalten von lokal laufendem Code beliebig zu ändern
Aufgrund dessen muss alle kritische Logik serverseitig validiert oder ausschließlich auf dem Server ausgeführt werden. Die Konsequenzen dieser Kontrolle sind in Netzwerkbesitz, Bewegungsvalidierung und Physik-Ausnutzung und Zugriffskontrolle und Vertraulichkeit detailliert beschrieben.
Serverautorität
Der Server muss die endgültige Quelle der Wahrheit für alle Simulationszustände, Regeln, Spielerfortschritte und kritischen Entscheidungen sein. Die Rolle des Clients besteht darin, die Welt darzustellen und Benutzereingaben an den Server zu senden.
Die Rolle des Servers ist es:
- Eingaben vom Client zu empfangen
- Zu validieren, dass die angeforderte Aktion möglich und zulässig ist
- Die Aktion auszuführen und seinen autoritativen Zustand zu aktualisieren
- Die Ergebnisse an alle relevanten Clients zu replizieren
Wenn ein Spieler beispielsweise sagt: "Ich möchte eine Bloxy Cola kaufen", muss der Server den tatsächlichen Preis des Artikels, das Geld des Spielers und die physische Entfernung des Spielercharakters zum Geschäft kennen, bevor er die Transaktion validiert und genehmigt. So viel wie möglich sollte der zu validierende Zustand ausschließlich vom Server und nicht von Clients verwaltet werden. Im Beispiel, wenn die Bloxy Cola-Transaktion genehmigt wird, sollte der Server den Preis der Bloxy Cola vom Geld des Spielers abziehen, jedoch kann der Server nicht unbedingt immer den Charakter des Spielers kontrollieren.
Sicherheit durch Design
Integrieren Sie Sicherheitsüberlegungen von Anfang an in das Design Ihres Spiels, anstatt zu versuchen, sie später als nachträglichen Gedanken hinzuzufügen.
- Bedrohungsmodell für jedes neue Feature. Stellen Sie sich für jedes neue Feature folgende Fragen:
- Wie könnte ein Angreifer dies ausnutzen, wenn er die volle Kontrolle über seinen Client hat?
- Wenn ein Client beliebige Werte für beliebige Parameter, die in dem Feature verwendet werden, senden könnte, was wäre das schlimmste mögliche Ergebnis?
- Was passiert, wenn dieses Feature 1.000+ Mal pro Sekunde verwendet wird? Was ist die maximale Rate, mit der es verwendet werden sollte?
- Könnte ein Ausnutzer dies verwenden, um das Erlebnis eines anderen Spielers zu ruinieren?
- Wie viele Ressourcen könnte dieses Feature im schlimmsten Fall realistisch nutzen?
- Welche minimalen internen Informationen oder Zustände muss ich für dieses Feature offenlegen?
- Verantwortlichkeiten frühzeitig aufteilen. Halten Sie Logik und Daten von Tag eins in ServerScriptService. Platzieren Sie sie niemals in replizierten Containern wie ReplicatedStorage oder Workspace.