Der folgende Inhalt behandelt verschiedene Konzepte und Taktiken zur Verbesserung der Sicherheit und zur Minderung von Betrug in Ihren Roblox-Erfahrungen. Es wird dringend empfohlen, dass alle Entwickler diese durchlesen, um sicherzustellen, dass Ihre Erfahrungen für alle Benutzer sicher und fair sind. Überprüfen Sie die Seitenleiste auf zusätzliche Sicherheitsthemen.
Bevor wir uns spezifischen Taktiken zuwenden, um sicher zu entwickeln und Betrug zu verhindern, ist es wichtig, die grundlegenden Prinzipien der Roblox-Sicherheit zu verstehen. Eine sichere Erfahrung basiert auf einer Denkweise, die feindliche Aktionen antizipiert. Bevor Sie eine einzige Zeile Code schreiben, müssen Sie diese grundlegenden Prinzipien verinnerlichen. Sie sollten jede architektonische und gestalterische Entscheidung, die Sie treffen, beeinflussen.
Vertrauen Sie 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 sich auf die Durchsetzung auf der Client-Seite verlässt, letztendlich umgangen. Dies ist keine Einschränkung von Roblox: Es ist eine grundlegende Realität von Client-Server-Architekturen. Gehen Sie davon aus, dass jede Datenübertragung vom Client manipuliert, gefälscht oder mit böswilliger Absicht gesendet wurde. Dies schließt die Möglichkeit ein,:
- Jedes replizierte LocalScript oder jedes ModuleScript zu dekompilieren, selbst wenn es niemals auf dem Client ausgeführt wird
- Netzwerk-Eigentum über ihren Charakter und любые nicht verankerten Teile zu übernehmen
- Client-initierte Ereignisse wie Berührungsereignisse oder ProximityPrompt-Aktivierungen in beliebigem Umfang oder Frequenz auszulösen
- Die Position, Physik oder Interaktionen ihres Spielers mit der Welt zu verändern
- RemoteEvents und RemoteFunctions mit beliebiger Frequenz und willkürlichen Argumenten (außer dem ersten Player-Argument) auszulösen oder zu invoken
- Alles in ihrem lokalen DataModel zu ändern, ohne erwartete Ereignisse auszulösen
- Das Verhalten von lokal laufendem Code willkürlich zu verändern
Aufgrund dessen muss gesamte kritische Logik serverseitig validiert oder ausschließlich auf dem Server ausgeführt werden. Die Konsequenzen dieser Kontrolle sind detailliert in Netzwerkbesitz, Bewegungsvalidierung und Physik-Ausnutzung und Zugriffskontrolle und Vertraulichkeit beschrieben.
Serverautorität
Der Server muss die letztendliche 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 zum Beispiel ein Spieler 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 Spielers zum Laden 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 den Clients verwaltet werden. Im Beispiel, wenn die Transaktion für die Bloxy Cola genehmigt wird, sollte der Server den Preis der Bloxy Cola vom Geld des Spielers abziehen; der Server kann jedoch nicht immer die Kontrolle über den Charakter des Spielers behalten.
Sicherheit durch Design
Integrieren Sie Sicherheitsüberlegungen von Anfang an in das Design Ihrer Erfahrung, anstatt zu versuchen, sie später als nachträglichen Gedanken hinzuzufügen.
- Bedrohungsmodell für jedes neue Feature. Für jedes neue Feature stellen Sie sich folgende Fragen:
- Wie könnte ein Angreifer dies ausnutzen, wenn er die vollständige Kontrolle über seinen Client hat?
- Wenn ein Client jeden Wert für alle in diesem Feature verwendeten Parameter senden könnte, was wäre das schlimmstmö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 sinnvoll nutzen?
- Welche minimalen internen Informationen oder Zustände muss ich für dieses Feature offenlegen?
- Verantwortlichkeiten frühzeitig aufteilen. Bewahren Sie Logik und Daten von Anfang an im ServerScriptService auf. Platzieren Sie sie niemals in replizierten Containern wie ReplicatedStorage oder Workspace.