Następująca treść obejmuje różne koncepcje i taktyki mające na celu poprawę bezpieczeństwa i przeciwdziałanie oszustwom w Twoich grach Roblox. Zdecydowanie zaleca się, aby wszyscy deweloperzy zapoznali się z nimi, aby zapewnić, że Twoje gry są bezpieczne i sprawiedliwe dla wszystkich użytkowników. Sprawdź pasek boczny, aby uzyskać dodatkowe tematy dotyczące bezpieczeństwa.
Zanim przejdziesz do konkretnych taktyk dotyczących bezpiecznego rozwoju i zapobiegania oszustwom, ważne jest, aby zrozumieć podstawowe zasady bezpieczeństwa Roblox. Bezpieczna gra opiera się na myśleniu, które przewiduje działania przeciwników. Zanim napiszesz jakikolwiek kod, musisz przyswoić te podstawowe zasady. Powinny one wpływać na każdą decyzję architektoniczną i projektową, jaką podejmujesz.
Nigdy nie ufaj klientowi
To jest zasada podstawowa. Zdeterminowany oszust ma pełną kontrolę nad swoim lokalnym stanem i ruchem sieciowym. Ponieważ oszuści mają ten poziom kontroli, wszelkie środki bezpieczeństwa, które polegają na egzekwowaniu po stronie klienta, w końcu zostaną obejście. To nie jest ograniczenie Roblox: to fundamentalna rzeczywistość architektur klient-serwer. Zakładaj, że każdy kawałek danych wysłany z klienta został zmanipulowany, sfałszowany lub wysłany z złośliwym zamiarem. Obejmuje to możliwość:
- Dekompilacji dowolnego skopiowanego LocalScript lub ModuleScript, nawet jeśli nigdy nie są uruchamiane na kliencie
- Przejęcia kontroli nad siecią swojego charakteru i wszelkich nieprzytwierdzonych części
- Wywoływania zdarzeń inicjowanych przez klienta, takich jak zdarzenia Touched lub aktywacje ProximityPrompt w dowolnym zasięgu lub częstotliwości
- Modyfikacji pozycji gracza, fizyki lub interakcji ze światem
- Wywoływania lub uruchamiania RemoteEvents i RemoteFunctions w dowolnej częstotliwości z dowolnymi argumentami (oprócz pierwszego argumentu Player)
- Zmiany czegokolwiek w swoim lokalnym DataModel bez wywoływania jakichkolwiek oczekiwanych zdarzeń
- Arbitralnej zmiany zachowania dowolnego kodu działającego lokalnie
Z tego powodu cała krytyczna logika musi być walidowana po stronie serwera lub uruchamiana wyłącznie na serwerze. Konsekwencje tej kontroli są szczegółowo opisane w Własność sieci, walidacja ruchu i oszustwa fizyczne oraz Kontrola dostępu i poufność.
Autorytet serwera
Serwer musi być ostatecznym źródłem prawdy dla wszystkich stanów symulacji, zasad, postępu graczy i krytycznych decyzji. Rola klienta polega na renderowaniu świata i przesyłaniu danych wejściowych do serwera.
Rola serwera to:
- Odbieranie danych wejściowych od klienta
- Walidacja, że żądana akcja jest możliwa i dozwolona
- Wykonanie akcji i zaktualizowanie swojego autorytatywnego stanu
- Replikacja wyników do wszystkich odpowiednich klientów
Na przykład, jeśli gracz mówi "Chcę kupić Bloxy Colę", serwer musi znać prawdziwą cenę przedmiotu, pieniądze gracza oraz fizyczną odległość postaci gracza od sklepu, zanim zweryfikuje i zatwierdzi transakcję. Tak bardzo, jak to możliwe, stan do walidacji powinien być utrzymywany wyłącznie przez serwer, a nie przez klientów. W przykładzie, jeśli transakcja Bloxy Coli zostanie zatwierdzona, serwer powinien odjąć cenę Bloxy Coli od pieniędzy gracza, jednak serwer nie może zawsze kontrolować postaci gracza.
Bezpieczeństwo przez projektowanie
Zintegruj rozważania dotyczące bezpieczeństwa w projekt swojej gry od samego początku, zamiast próbować je dodać później jako myśl poboczną.
- Modeluj zagrożenia dla każdej nowej funkcji. Dla każdej nowej funkcji zapytaj:
- Jak mógłby zaatakować oszust, jeśli miałby pełną kontrolę nad swoim klientem?
- Jeśli klient mógłby wysłać dowolną wartość dla dowolnych parametrów używanych w funkcji, jaki byłby najgorszy możliwy wynik?
- Co się stanie, jeśli ta funkcja będzie używana 1 000+ razy na sekundę? Jaka jest maksymalna częstotliwość, z jaką powinna być używana?
- Czy oszust mógłby to wykorzystać, aby zrujnować doświadczenie innego gracza?
- Ile zasobów, w najgorszym przypadku, ta funkcja mogłaby realistycznie wykorzystać?
- Jakie jest minimalne wewnętrzne informacje lub stan, które muszę ujawnić dla tej funkcji?
- Podziel odpowiedzialności na wczesnym etapie. Przechowuj logikę i dane w ServerScriptService od pierwszego dnia. Nigdy nie umieszczaj ich w replikowanych kontenerach, takich jak ReplicatedStorage lub Workspace.