Zugriffskontrolle und Vertraulichkeit

Das Verständnis darüber, welche Informationen und Ressourcen für Clients sichtbar sind, ist entscheidend für die Aufrechterhaltung sowohl der Sicherheit als auch der Vertraulichkeit Ihres Spiels. Entwickler unterschätzen oft, wie viel für Ausnutzer sichtbar ist und an Clients repliziert wird. Ausnutzer haben die Möglichkeit, auf "eingeschränkte" Orte innerhalb Ihres Universums zuzugreifen, wenn sie einen einzigen Ort betreten können. Sie können jeden Inhalt sehen, der an ihren Client repliziert wird, unabhängig davon, ob er sichtbar oder derzeit in Verwendung ist. Darüber hinaus können Ausnutzer alle replizierten lokalen Skripte und ModuleScripts dekompilieren, selbst wenn diese niemals auf dem Client ausgeführt werden.

Client-seitige Teleportation innerhalb von Universen

Sobald sie sich in einem Universum befinden, können Clients zu jedem Ort innerhalb dieses Universums teleportieren, wodurch sie möglicherweise beabsichtigte Zugriffsrestriktionen oder Fortschrittsbarrieren umgehen. Dies kann auch zu unbeabsichtigten Leaks von unveröffentlichtem Inhalt führen, beispielsweise aus einem Entwicklungs- oder Staging-Spiel. Es ist wichtig zu verstehen, dass:

• Das Deaktivieren von "Direktem Zugriff" entfernt nur die Beitrittschaltfläche von Unterorten auf der Website — es verhindert nicht, dass Clients Teleportationen initiieren
• Gehen Sie davon aus, dass Ausnutzer die Existenz aller Unterorte innerhalb Ihres Universums entdecken werden
• Ein Client kann zu jedem Unterort teleportieren, wenn er auf einen einzigen Ort zugreifen kann, wie den Hauptort, unabhängig von Ihrem beabsichtigten Designfluss

Viele Entwickler versuchen, den Zugriff zu verhindern, indem sie unbefugte Benutzer von einem Unterort ausschließen. Dies kann zwar das Gameplay blockieren, verhindert jedoch nicht, dass Inhalte an den Client repliziert werden, da die Replikation beginnt, sobald der Spieler beitritt und bevor die serverseitige Ausschlusslogik ausgeführt werden kann.

Verwenden Sie sichere Teleportationen

Der effektivste Weg, unbefugten Zugriff über Teleportation zu verhindern, besteht darin, die Zugriffskontrolle für Orte auf Nur innerhalb des Universums sichern im Creator Dashboard einzustellen. Dies beschränkt alle Nicht-Startorte auf serverinitiierte Teleportationen, wodurch clientinitiierte Teleportationen auf Plattformebene blockiert werden, bevor der Spieler jemals dem Unterort beitritt. Da der Spieler nie beitritt, wird kein Inhalt an ihn repliziert.

Für Konfigurationsschritte und Migrationsanleitungen für bestehende Spiele, die clientinitiierte Teleportationen verwenden, siehe Teleport zwischen Orten.

Verteidigung in der Tiefe für eingeschränkte Orte

Für Universen, die keine sicheren Teleportationen verwenden können, oder als zusätzliche Schutzschichten neben ihnen, kombinieren Sie die folgenden Maßnahmen:

• Halten Sie Entwicklungs- und Testorte in separaten, privaten Universen — dies ist der einzige zuverlässige Weg, um die Vertraulichkeit für unveröffentlichten Inhalt sicherzustellen. Versenden Sie niemals vertrauliche Eventressourcen, Skripte oder UI-Elemente in die Produktionsumgebung, bevor sie aktiv sein sollen.
• Verwenden Sie, wenn möglich, Streaming, um zu begrenzen, wie viel von der Welt an einen neuen Spieler repliziert wird.
• Fügen Sie serverseitige Gruppenrollen- oder Abzeichenüberprüfungen hinzu und überprüfen Sie den Spielerstatus oder die Fortschrittsanforderungen.
• Verweigern Sie standardmäßig eingehende Spieler. Dies stellt sicher, dass kein Spieler zugelassen wird, selbst wenn der Überprüfungsprozess unklar ist, wie im Fall einer Ausnahme, die von der Engine ausgelöst wird.
• Verwenden Sie, wenn praktikabel, die Ban API für Spieler, die die Validierung nicht bestehen. Dies verhindert, dass Spieler weiterhin versuchen, sich mit demselben Konto anzumelden.

Replikation

Replikation beschreibt, wie der Zustand über das Netzwerk zwischen Instanzen der Engine übertragen wird. Das Replikationsmodell von Roblox ist in einigen wichtigen Punkten allgemein vereinfacht:

• Instanzen sind serverautoritär, was bedeutet, dass eine Instanz, um zwischen allen Teilnehmern (dem Server und allen verbundenen Clients) zu replizieren, auf dem Server erstellt werden muss.
• Instanzeigenschaften sind ebenfalls serverautoritär, was bedeutet, dass die meisten Eigenschaften auf dem Server geändert werden müssen, damit die Änderungen für alle Clients sichtbar sind.
• Im Allgemeinen repliziert eine Instanz entweder an alle verbundenen Clients oder nicht. Es gibt einige Ausnahmen, wie Streaming.

Replikationscontainer sind Top-Level-Instanzen (unter dem DataModel), die an Clients replizieren. Wenn eine Instanz jemals ein Nachkomme eines Replikationscontainers während ihrer Lebensdauer wird, sollten Sie erwarten, dass ein großer Teil ihres Zustands an alle Clients repliziert wird. Sie können mehr über gängige Replikationscontainer im Datenmodell-Leitfaden lesen. Wenn Sie sich unsicher sind, können Sie immer überprüfen, wie eine Instanz oder Eigenschaft in einer Testumgebung wie Play Solo repliziert. Sie können mehr über Testmodi in Studio-Testmodi lesen.

Sicherheitsimplikationen der Replikation

Jeder Inhalt, der an einen Client repliziert wird, kann von einem Ausnutzer extrahiert und datengemined werden. Als allgemeine Regel sollten Sie vermeiden, vertrauliche Inhalte in die Live-Produktionsumgebung zu veröffentlichen oder zu versenden, es sei denn, Sie sind sofort bereit, dass sie von Benutzern gesehen werden. Selbst wenn es Logik gibt, die die Veröffentlichung oder den Zugriff auf den Inhalt im Spiel bis zu einem späteren Zeitpunkt (oder einer anderen Bedingung) steuert, gehen Sie davon aus, dass Ausnutzer einen Weg finden werden, Ihren Inhalt zu entdecken und zu leaken, sobald er veröffentlicht wird.

Vermeiden Sie übermäßig beschreibende oder vorhersehbare Namen für sensible Instanzen, einschließlich, aber nicht beschränkt auf: Skripte, Remotes und Modelle. Eine vorhersehbare DataModel-Hierarchie erleichtert die Entwicklung von Exploits.

Skriptedekompilierung

Jedes LocalScript, Script mit RunContext::Client oder ModuleScript kann von einem Ausnutzer dekompiliert werden, sobald es an ihren Client repliziert wird, selbst wenn solche Skripte deaktiviert, niemals benötigt oder niemals auf dem Client ausgeführt werden. Serverseitige Skripte und ModuleScripts, die in ServerStorage oder ServerScriptService gespeichert sind, können nicht dekompiliert werden, da sie niemals an Clients repliziert werden.

Es ist nicht ratsam, ein ModuleScript zu schreiben, das serverseitigen und clientseitigen Code im selben Skript enthält, da serverseitige Logik in der Dekompilierung offengelegt wird und leichter auf Bugs untersucht werden kann, die ausgenutzt werden können.

local module = {}

local Remote = script:WaitForChild("RemoteEvent")

-- Hier ist ein Beispiel für ein Paradigma, das vermieden werden sollte
-- Halten Sie Servercode in Skriptinstanzen oder in ServerStorage/ServerScriptStorage!

if game:GetService("RunService"):IsServer() then
  function module:DoServerThing(password)
    if password == "SecretPassword" then
      print("sensible Servercode")
    end
  end

  Remote.OnServerEvent:Connect(function(player, password)
    module:DoServerThing(password)
  end)
else
  function module:DoServerThing(password)
    Remote:FireServer(password)
  end
end

return module

local table1 = {};
local RemoteEvent = script:WaitForChild("RemoteEvent");
if game:GetService("RunService"):IsServer() then
  function table1.DoServerThing(_, p2) -- Zeile: 9
    if p2 == "SecretPassword" then
      print("sensible Servercode");
    end
  end
  RemoteEvent.OnServerEvent:Connect(function(player: Player, p3) -- Zeile: 15
    --[[
      Upvalues:
        [1] = table1
    --]]
    table1:DoServerThing(p3);
  end);
  return table1;
end
function table1.DoServerThing(_, p1) -- Zeile: 19
  --[[
    Upvalues:
      [1] = RemoteEvent
  --]]
  RemoteEvent:FireServer(p1);
end
return table1;

Wie oben gezeigt, offenbart die Dekompilierung serverseitige Logik, einschließlich fest codierter Passwörter, Geschäftsregeln und Implementierungsdetails, die Ausnutzern helfen können, Schwachstellen zu analysieren.

Auswirkungen von Vertraulichkeitsverletzungen

Vertraulichkeitsverletzungen können erhebliche Folgen haben, wie zum Beispiel:

• Inhaltslecks: Unveröffentlichte Gegenstände, Karten oder Funktionen können entdeckt und öffentlich geteilt werden, bevor offizielle Ankündigungen erfolgen
• Wettbewerbsnachteile: Mechaniken, Algorithmen oder kommende Funktionen können von Wettbewerbern rückentwickelt werden
• Entwicklung von Exploits: Offengelegte Serverlogik erleichtert es Ausnutzern, Schwachstellen zu identifizieren und gezielte Angriffe zu entwickeln