Zugriffskontrolle und Vertraulichkeit

Das Verständnis dafür, welche Informationen und Assets für Clients sichtbar sind, ist entscheidend für die Aufrechterhaltung sowohl der Sicherheit als auch der Vertraulichkeit Ihres Erlebnisses. Entwickler unterschätzen oft, wie viel für Ausnutzer sichtbar ist und zu Clients repliziert wird. Ausnutzer haben die Möglichkeit, „beschränkte“ Orte innerhalb Ihres Universums zuzugreifen, wenn sie einem einzigen Ort beitreten können. Sie können jeden Inhalt einsehen, der auf ihren Client repliziert wurde, unabhängig davon, ob er sichtbar oder derzeit in Gebrauch ist. Darüber hinaus können Ausnutzer alle replizierten lokalen Skripte und ModuleScripts dekompilieren, selbst wenn sie 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 beabsichtigte Zugangsbeschränkungen oder Fortschrittsschranken umgangen werden. Dies kann auch zu einem unbeabsichtigten Leck von nicht veröffentlichtem Inhalt führen, beispielsweise aus einem Entwicklungs- oder Testprozess. Es ist wichtig zu verstehen, dass:

• Das Deaktivieren von „Direktem Zugang“ entfernt lediglich die Schaltfläche „Beitreten“ von Unterorten auf der Website – es verhindert nicht klientenseitige Teleportationen.
• 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, wie den Hauptort, zugreifen kann, unabhängig von Ihrem beabsichtigten Designfluss.

Viele Entwickler versuchen, den Zugriff zu verhindern, indem sie unbefugte Benutzer von einem Unterort ausschließen. Dies mag funktionieren, um das Gameplay zu blockieren, aber es verhindert 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

Die effektivste Möglichkeit, unbefugten Zugriff über Teleportation zu verhindern, besteht darin, die Zugriffskontrolle für Orte auf Nur innerhalb des Universums sichern im Creator Dashboard einzustellen. Dadurch werden alle nicht startenden Orte auf serverinitiierte Teleportationen beschränkt, was clientinitiierte Teleportationen auf Plattformebene blockiert, bevor der Spieler jemals dem Unterort beitritt. Da der Spieler nie beitritt, repliziert nichts an ihn.

Für Konfigurationsschritte und Migrationsleitfäden für bestehende Erlebnisse, die clientinitiierte Teleportationen verwenden, siehe Teleport zwischen Orten.

Abwehrmaßnahmen für eingeschränkte Orte

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

• Halten Sie Entwicklungs- und Testorte in separaten, privaten Universen – dies ist die einzige zuverlässige Methode, um die Vertraulichkeit nicht veröffentlichter Inhalte zu gewährleisten. Versenden Sie niemals vertrauliche Event-Assets, Skripte oder UI-Elemente in die Produktionsumgebung, bevor sie dazu bestimmt sind, aktiv zu sein.
• Verwenden Sie, wenn möglich, Streaming, um zu beschränken, 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.
• Lassen Sie standardmäßig keine eingehenden Spieler zu. Dies stellt sicher, dass kein Spieler zugelassen wird, selbst wenn der Überprüfungsprozess nicht schlüssig ist, wie im Falle einer von der Engine ausgelösten Ausnahme.
• Verwenden Sie, wenn praktikabel, die Ban API für Spieler, die die Validierung nicht bestehen. Dies verhindert, dass Spieler weiterhin versuchen, mit demselben Konto beizutreten.

Replikation

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

• Instanzen sind serverautorisiert, 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 serverautorisiert, 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 zu allen verbundenen Clients oder nicht. Es gibt einige Ausnahmen, wie das 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ßteil ihres Zustands an alle Clients repliziert wird. Sie können mehr über gängige Replikationscontainer im Datenmodellführer lesen. Im Zweifelsfall können Sie immer überprüfen, wie eine Instanz oder Eigenschaft in einer Testumgebung wie Play Solo repliziert wird. Sie können mehr über Testmodi in den Studio-Testmodi lesen.

Sicherheitsimplikationen der Replikation

Alle Inhalte, die an einen Client repliziert werden, können von einem Ausnutzer extrahiert und datengegraben werden. Als allgemeine Regel gilt: Vermeiden Sie es, 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 Freigabe oder den Zugriff auf den Inhalt bis zu einem späteren Datum (oder einer anderen Bedingung) im Erlebnis steuert, gehen Sie davon aus, dass Ausnutzer einen Weg finden, Ihre Inhalte zu entdecken und zu leaken, sobald sie veröffentlicht sind.

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 Ausnutzungen.

Dekompilierung von Skripten

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

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

Originales ModuleScript in ReplicatedStorage
local module = {}

local Remote = script:WaitForChild("RemoteEvent")

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

if game:GetService("RunService"):IsServer() then
  function module:DoServerThing(password)
    if password == "GeheimesPasswort" then
      print("sensible server code")
    end
  end

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

return module

Dekompilierter Ergebnis
local table1 = {};
local RemoteEvent = script:WaitForChild("RemoteEvent");
if game:GetService("RunService"):IsServer() then
  function table1.DoServerThing(_, p2) -- Zeile: 9
    if p2 == "GeheimesPasswort" then
      print("sensible server code");
    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, deckt die Dekompilierung serverseitige Logik auf, einschließlich von hartkodierten Passwörtern, Geschäftsregeln und Implementierungsdetails, die Ausnutzer analysieren können, um Schwachstellen zu finden.

Auswirkungen von Vertraulichkeitsverletzungen

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

• Inhaltslecks: Nicht veröffentlichte Gegenstände, Karten oder Funktionen können entdeckt und öffentlich geteilt werden, bevor offizielle Ankündigungen erfolgen.
• Wettbewerbsnachteil: Mechaniken, Algorithmen oder bevorstehende Funktionen können von Wettbewerbern zurückentwickelt werden.
• Entwicklung von Ausnutzungen: Offen gelegte Serverlogik ermöglicht es Ausnutzern, schneller und einfacher Schwachstellen zu identifizieren und gezielte Angriffe zu entwickeln.