Sicherheitsstrategien und Cheat-Vermeidung

Roblox verwendet ein verteiltes Physik-System, bei dem Clients die physische Simulation von Objekten in ihrem Kontrollbereich besitzen, normalerweise der Charakter des Spieler:inund unverankerte Objekte in der Nähe dieses Charakters. Darüber hinaus, durch die Verwendung von Drittsoftware können Exploiter unbeaufsichtigten Lua-Code auf dem Client ausführen, um das Datenmodell des Clients zu manipulieren und den Code zu dekompilieren und anzuzeigen, der auf dem Client ausgeführ

Sammelhaft bedeutet dies, dass ein erfahrener Exploiter potenziell Code ausführen kann, um in deinem Spiel zu schummeln, einschließlich:

• Teleportieren Sie ihren eigenen Charakter um den Ort herum.
• Feuern Sie ungesicherte RemoteEvents oder rufen Sie RemoteFunctions auf, z. B. um sich Gegenstände zu verdienen, ohne sie zu verdienen.
• Anpassen der Charakter ihres WalkSpeed , damit es wirklich schnell bewegt.

Während Sie begrenzte Design-Verteidigungen implementieren können, um häufige Angriffe zu erkennen, wird dringend empfohlen, dass Sie mehr zuverlässige Server-seitige Mitigations-Taktiken implementieren, da der Server die letzte Autorität für jede laufende Erlebnisist.

Verteidigungsdesign-Taktiken

Grundlegende Designentscheidungen können als "erster Schritt"-Sicherheitsmaßnahmen dienen, um die Exploitation zu verhindern. Zum Beispiel in einem Shooter-Spiel, in dem Spieler Punkte für das Töten anderer Spieler erhalten, kann ein Exploiter eine Reihe von Bots erstellen, die sich zum selben Ort teleportieren, damit sie schnell für Punkte getötet werden können. Angesichts dieses potenziellen Exploits betrachten Sie zwei Ansätze und ihr vorhersehbares Ergebnis:

Während die Verteidigungsarchitektur offensichtlich kein perfektes oder umfassendes Lösung ist, kann sie zu einem breiteren Sicherheitsansatz beitragen, zusammen mit Server-seitige Mitigation.

Server-seitige Mitigation

Soweit möglich sollte der Server das endgültige Urteil darüber, was "wahr" und was der aktuelle Zustand der Welt ist, abgeben. Clients können natürlich den Server bitten, Änderungen vorzunehmen oder eine Actionauszuführen, aber der Server sollte überprüfen und genehmigen jede dieser Änderungen/Aktionen, bevor die Ergebnisse an andere Spieler repliziert werden.

Mit Ausnahme bestimmter physikalischer Operationen, die Änderungen am Datenmodell auf dem Client nicht auf den Server replizieren, so dass der Hauptangriffsweg oft über die Netzwerkereignisse, die du mit RemoteEvents und RemoteFunctions deklariert hast, ist. Denke daran, dass ein Exploiter, der seinen eigenen Code auf deinem Client ausführt, mit diesen aufrufen kann, mit welchen Daten

Remote-Laufzeit-Typ-Validierung

Ein Angriffsweg ist für einen Exploiter, um RemoteEvents und RemoteFunctions mit Argumenten des falschen eingebenzu spawnen. In einigen Szenarien kann dies dazu führen, dass der Code auf dem Server auf diese Fernzüge reagiert, um einen Vorteil für den Exploiter zu erhalten.

Wenn Sie Remote-Ereignisse/Funktionen verwenden, können Sie diesen Angriff verhindern, indem Sie die Arten von übergebenen Argumenten auf dem Server validieren. Das Modul "t", das verfügbar ist hier, ist nützlich für die Typ-Check-in dieser Weise. Zum Beispiel, wenn Sie den Code des Moduls annehmen

Lokales Skript in StarterPlayerScripts
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local remoteFunction = ReplicatedStorage:WaitForChild("RemoteFunctionTest")

-- Farbe und Position des Passes beim Aufrufen der Funktion
local newPart = remoteFunction:InvokeServer(Color3.fromRGB(200, 0, 50), Vector3.new(0, 25, 0))

if newPart then
	print("The server created the requested part:", newPart)
elseif newPart == false then
	print("The server denied the request. No part was created.")
end

Script in ServerScriptService
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local remoteFunction = ReplicatedStorage:WaitForChild("RemoteFunctionTest")
local t = require(ReplicatedStorage:WaitForChild("t"))

-- Erstellen Sie im Voraus einen Typ-Validator, um eine unnötige Überlagerung zu vermeiden
local createPartTypeValidator = t.tuple(t.instanceIsA("Player"), t.Color3, t.Vector3)

-- Erstellen Sie ein neues Teil mit den übergebenen Eigenschaften
local function createPart(player, partColor, partPosition)
	-- Überprüfen Sie die übergebenen Argumente
	if not createPartTypeValidator(player, partColor, partPosition) then
		-- Geben Sie hier "false" zurück, wenn der Typ-Check fehlschlägt
		-- Ein Fehler ohne Abklingzeit kann zum Absturz des Servers missbraucht werden
		-- Stellen Sie stattdessen Kunden-Feedback bereit!

		return false
	end

	print(player.Name .. " requested a new part")
	local newPart = Instance.new("Part")
	newPart.Color = partColor
	newPart.Position = partPosition
	newPart.Parent = workspace
	return newPart
end

-- Binden Sie "createPart()" an den Callbackder Remote-Funktion
remoteFunction.OnServerInvoke = createPart

Daten-Validierung

Ein weiterer Angriff, den die Exploiter starten könnten, ist, technisch gültige Arten zu senden, aber sie extrem groß, lang oder anders als mangelhaft zu machen. Zum Beispiel, wenn der Server eine teure Operation auf einer Zeichenkette durchführen muss, kann ein Exploiter einen unglaublichen großen oder mangelhaften Zeichen senden, um den Server zu verlangsamen.

Ebenso werden sowohl inf als auch NaN``Global.LuaGlobals.type() als 1> number1> , aber beide können große Probleme verursachen, wenn ein Exploiter sie sendet und sie nicht richtig durch Funktionen wie die gefolgte Profileverwaltet:

local function isNaN(n: number): boolean
	-- NaN ist niemals gleich mit sich selbst
	return n ~= n
end

local function isInf(n: number): boolean
	-- Die Zahl könnte -inf oder inf sein
	return math.abs(n) == math.huge
end

Ein weiterer häufiger Angriff, den die Exploiter verwenden, besteht darin, tables anstelle eines Instance zu senden. Komplexe Payloads können das aussehen, was eine sonstige übliche Objektressource wäre.

Zum Beispiel mit einem In-Experience-Shop-System, in dem Artikeldaten wie Preise in Class.NumberValue -Objekten gespeichert sind, kann ein Exploiter alle anderen Checks umgehen, indem er gefolgte Profiletut:

Lokales Skript in StarterPlayerScripts
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local itemDataFolder = ReplicatedStorage:WaitForChild("ItemData")
local buyItemEvent = ReplicatedStorage:WaitForChild("BuyItemEvent")
local payload = {
	Name = "Ultra Blade",
	ClassName = "Folder",
	Parent = itemDataFolder,
	Price = {
		Name = "Price",
		ClassName = "NumberValue",
		Value = 0,  -- Negative Werte können auch verwendet werden, was dazu führt, dass die Währung gegeben wird, anstatt sie zu nehmen!
	},
}

-- Senden Sie ein bösartiges Paket an den Server (dies wird abgelehnt)
print(buyItemEvent:InvokeServer(payload))  -- Outputs "false Unzulässiges Item bereitgestellt"

-- Senden Sie einen echten Gegenstand an den Server (dies wird durchgehen!)
print(buyItemEvent:InvokeServer(itemDatafolder["Real Blade"]))  -- Outputs "true" and remaining currency if purchase succeeds

Script in ServerScriptService
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local itemDataFolder = ReplicatedStorage:WaitForChild("ItemData")
local buyItemEvent = ReplicatedStorage:WaitForChild("BuyItemEvent")

local function buyItem(player, item)
	-- Überprüfen Sie, ob das übergebene Element nicht gespoofed ist und in der ItemData-Ordner ist
	if typeof(item) ~= "Instance" or not item:IsDescendantOf(itemDataFolder) then
		return false, "Invalid item provided"
	end

	-- Der Server kann dann auf die Verarbeitung des Kaufs basierend auf dem unten stehenden Beispielflow fortfahren
end

-- Binden Sie "buyItem()" an den Callbackder Remote-Funktion
buyItemEvent.OnServerInvoke = buyItem

Wert-Validierung

Zusätzlich zu der Überprüfung von Typen und Daten, solltest du die werte , die durch 1> Class.RemoteEvent|RemoteEvents1> und 4> Class.RemoteFunction|RemoteFunctions4> durchgegeben werden, überprüfen, um sicherzustellen, dass sie im Kontext angegebenen

In-Experience-Shop

Betrachten Sie ein In-Experience-Shop-System mit einer Benutzeroberfläche, z. B. ein Produktauswahlmenü mit einem "Kaufen"-Button. Wenn die Schaltfläche gedrückt wird, können Sie einen RemoteFunction zwischen dem Client und dem Server aufrufen, um den kaufenzu veranlassen. jedoch ist es wichtig, dass die server, der zuverlässigste Manager des Artikel, bestätigt, dass der Ben

Ziel auf Waffen

Kampfszenarien erfordern besondere Aufmerksamkeit für die Überprüfung von Werten, insbesondere durch das Zielen und das Treffen.

Stellen Sie sich vor, ein Spiel, bei dem ein Spieler einen Laserstrahl auf einen anderen Spieler:inabfeuern kann. Statt dem Client dem Server zu sagen, wer den Schaden zu verursachen, sollte er stattdessen den Schuss und die Position der Person/ des Teils, die er getroffen hat, dem Server mitteilen. Der Server kann dann überprüfen, was gefolgte Profile:

• Die Position, die der Client berichtet, schießt von , ist in der Nähe des Charakters des Spieler:inauf dem Server. Beachten Sie, dass der Server und der Client wegen der Latenz etwas abweichen, so dass zusätzliche Toleranz angewendet werden muss.

• Die Position, die der Client berichtet, hat das Ziel erreicht , ist razsicherlich nahe der Position der Teil , auf der der Client berichtet, dass er das Ziel erreicht hat, auf dem Server.

• Es gibt keine statischen Hindernisse zwischen der Position, die der Client berichtet, dass er schießt, und der Position, die der Client berichtet, dass er schießt. Dieser Check stellt sicher, dass ein Client nicht versucht, durch Wände zu schießen. Beachten Sie, dass dies nur statische Geometrie überprüft, um gültige Schüsse aufgrund der Verzögerung abzulehnen. Zusätzlich können Sie weitere Server-seitige Überprüfungen wie folgt implementieren:

• Verfolgen Sie, wenn der Spieler seine Waffe zum letzten Mal abgefeuert hat, und überprüfen Sie, um sicherzustellen, dass sie nicht zu schnell schießen.

• Verfolgen Sie die Munitionsmenge jedes Spieler:inauf dem Server und bestätigen Sie, dass ein schießender Spieler genug Munition hat, um die Waffenangriff auszuführen.

• Wenn du Mannschaften oder ein "Mannschaften gegen Bots"-Kampf-System implementiert hast, bestätige, dass der Treffercharakter ein Feind ist, nicht ein Teamkolleague.

• Bestätigen Sie, dass der Treffer-Spieler lebt.

• Lagere Waffen- und Spielerzustand auf dem Server und bestätige, dass ein abfeuernder Spieler nicht durch eine aktuelle Aktion wie Nachladen oder einen Zustand wie Sprinten blockiert wird.

Datenspeicher-Manipulation

In Erlebnissen, die DataStoreService verwenden, um Spielerdaten zu speichern, können Exploiter die ungültigen Daten nutzen und mehr verschleiertere Methoden, um ein DataStore richtig zu speichern. Dies kann in Erlebnissen mit Artikelhandel, Marktplätzen und ähnlichen Systemen verwendet werden, bei denen Gegenstände oder Währungen das Inventar eines Spieler:inverlassen.

Stellen Sie sicher, dass alle Aktionen, die durch einen RemoteEvent oder RemoteFunction ausgeführt werden, der auf die gefolgte ProfileOptionen basieren:

• Instance Werte können nicht in ein DataStore geschrieben werden und fehlen. Verwenden Sie Typ-Validierung, um dies zu verhindern.
• DataStores haben daten Limits. Strings von beliebiger Länge sollten überprüft und/oder begrenzt werden, um dies zu vermeiden, neben der Gewährleistung, dass unbegrenzte beliebige Schlüssel nicht auf Tabeln vom Client hinzugefügt werden können.
• Tabellen-Indexen können nicht NaN oder nil sein. Iterate über alle Tabellen, die vom Client durchgeführt werden, und überprüfen Sie, dass alle Indizes gültig sind.
• DataStores kann nur gültige UTF-8-Zeichen akzeptieren, so dass Sie alle Strings, die vom Client über utf8.len() bereitgestellt werden, validieren, um sicherz

Fernbedienungsschalter

Wenn ein Client in der Lage ist, deinen Server mithilfe eines kostenpflichtigen Berechnungsprozesses oder eines Rate-限定-Dienstes wie DataStoreService über einen RemoteEvent Zugriff auf eine begrenzte Rate zu erhalten, ist es wichtig, dass du Rate-Limitierungsmechanismen implementierst, um sicherzustellen, dass der Prozess nicht zu hä

Bewegung-Validierung

Für kompetitive Erlebnisse kann es sich lohnen, die Bewegungen des Spielers auf dem Server zu überprüfen, um sicherzustellen, dass sie nicht auf der Karte teleportiert werden oder schneller sind als die akzeptablen.

1. Inkremente von 1 Sekunde überprüfen Sie die neue Position des Charakters gegen einen zuvor gespeicherten Ort.

   

2. Bestimmen Sie eine maximale "verzeihliche" Änderung in der Entfernung basierend auf der Charakter-WalkSpeed (Studs pro Sekunde), multipliziert um ~ 1,4, um eine gewisse Toleranz gegen die Serverlatenz zu erlauben. Zum Beispiel bei einer Standard-WalkSpeed von 16, ein verzeihlic

   

3. Vergleichen Sie die tatsächliche Entfernung gegen die verträgliche Entfernung und verfahren Sie wie folgt:

   • Für einen tolerablen Delta, speichern Sie die neue Position des Charakters im Voraus für die nächste erhöhte überprüfen.
   • Für ein unerwartetes oder intolerantes Delta (Potenzgeschwindigkeit / Teleport-Exploit):

     1. Erhöht den "number of offenses"-Wert für den Spieler:inim Vergleich zu Penalien für eine "falsche positive"-Strafe, die durch extreme Server-Verzögerung oder andere Nicht-Exploit-Faktoren entsteht.
     2. Wenn eine große Anzahl von Verletzungen über einen Zeitraum von 30-60 Sekunden auftreten, Kick() der Spieler aus der Erfahrung vollständig; sonstige, resette die "Anzahl der Verletzungen" -Zähler. Beachten Sie, dass beim Kicken eines Spielers für Schummeln die beste Praktik, das Ereignis aufzuzeichnen, damit Sie verfolgen können, wie viele Spieler betroffen sind.