Poniższa treść omawia różne koncepcje i taktyki mające na celu poprawę bezpieczeństwa i zapobieganie oszustwom w Twoich doświadczeniach Roblox. Zdecydowanie zaleca się, aby wszyscy deweloperzy zapoznali się z nimi, aby zapewnić, że Twoje doświadczenia 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, istotne jest zrozumienie podstawowych zasad bezpieczeństwa w Roblox. Bezpieczne doświadczenie opiera się na myśleniu, które przewiduje działania przeciwników. Zanim napiszesz choćby jedną linię kodu, musisz wchłonąć te podstawowe zasady. Powinny one informować o każdej decyzji architektonicznej i projektowej, jaką podejmujesz.
Nigdy nie ufaj klientowi
To jest zasada podstawowa. Zdeterminowany exploiter ma pełną kontrolę nad swoim lokalnym stanem i ruchem sieciowym. Ponieważ exploiterzy mają ten poziom kontroli, wszelkie środki bezpieczeństwa polegające na egzekwowaniu po stronie klienta będą ostatecznie obchodzone. To nie jest ograniczenie Roblox: to fundamentalna rzeczywistość architektur klient-serwer. Zakładaj, że każdy kawałek danych wysłanych z klienta został zmanipulowany, sfabrykowany lub wysłany z złośliwym zamiarem. Wśród tych mocy znajduje się:
- Dekompilacja każdego zreplikowanego LocalScript lub jakiegokolwiek ModuleScript, nawet jeśli nigdy nie wykonują się po stronie klienta
- Przejęcie sieciowej kontroli nad swoją postacią i wszystkimi niezakotwiczonymi częściami
- Wywoływanie zdarzeń inicjowanych przez klienta, takich jak zdarzenia Touched lub aktywacje ProximityPrompt z dowolnego zasięgu lub częstotliwości
- Modyfikowanie pozycji gracza, fizyki lub interakcji ze światem
- Uruchamianie lub wywoływanie RemoteEvents i RemoteFunctions z dowolną częstotliwością z dowolnymi argumentami (oprócz pierwszego argumentu Player)
- Zmiana czegokolwiek w swoim lokalnym DataModel bez wywoływania jakichkolwiek oczekiwanych zdarzeń
- Dowolna zmiana działania jakiegokolwiek lokalnie działającego kodu
Z tego powodu, wszelka krytyczna logika musi być walidowana po stronie serwera lub działać wyłącznie na serwerze. Konsekwencje tej kontroli są szczegółowo opisane w Własności sieciowe, 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, reguł, postępów 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 aktualizacja swojego autorytatywnego stanu
- Replikacja wyników do wszystkich odpowiednich klientów
Na przykład, jeśli gracz mówi "Chcę kupić Bloxy Cola", serwer musi znać prawdziwą cenę przedmiotu, pieniądze gracza oraz fizyczny dystans postaci od sklepu przed zatwierdzeniem i akceptacją transakcji. Jak najwięcej, stan do walidacji powinien być utrzymywany wyłącznie przez serwer, a nie przez klientów. W przykładzie, jeśli transakcja Bloxy Cola zostanie zatwierdzona, serwer powinien odjąć cenę Bloxy Cola od pieniędzy gracza, jednak serwer nie zawsze może kontrolować postać gracza.
Bezpieczeństwo przez projektowanie
Zintegrować kwestie bezpieczeństwa w projekt swojego doświadczenia od samego początku, zamiast próbować dodać je później jako myśl wtórną.
- Modeluj zagrożenia dla każdej nowej funkcji. Dla każdej nowej funkcji pytaj:
- W jaki sposób napastnik mógłby to wykorzystać, jeśli ma pełną kontrolę nad swoim klientem?
- Jeśli klient mógłby wysłać dowolną wartość dla jakichkolwiek parametrów używanych w tej funkcji, jaki byłby najgorszy możliwy skutek?
- Co się stanie, jeśli ta funkcja będzie używana 1 000+ razy na sekundę? Jaka jest maksymalna częstość jej używania?
- Czy exploiter mógłby użyć tego do zepsucia doświadczenia innego gracza?
- Ile zasobów, w najgorszym przypadku, mogłaby ta funkcja wykorzystać?
- Jakie minimalne wewnętrzne informacje lub stan muszę ujawniać dla tej funkcji?
- Wcześnie podziel obowiązki. Przechowuj logikę i dane w ServerScriptService od pierwszego dnia. Nigdy nie umieszczaj ich w replikowanych kontenerach, takich jak ReplicatedStorage czy Workspace.