Taktiki zabezpieczeń i przeciwdziałania oszustwom

Zanim przejdziesz do konkretnych taktyk dotyczących bezpiecznego rozwoju i zapobiegania oszustwom, ważne jest, aby zrozumieć podstawowe zasady bezpieczeństwa w 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ą, którą 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, ostatecznie zostaną obejście. To nie jest ograniczenie Roblox: to fundamentalna rzeczywistość architektur klient-serwer. Zakładaj, że każdy kawałek danych wysył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 swoją postacią i wszelkimi nieprzytwierdzonymi częściami
• 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 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ść.

Serwer jako źródło prawdy

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

Ta zasada różni się od autorytetu serwera, cechy silnika, która stosuje ją do fizyki i ruchu. W modelu autorytetu serwera serwer symuluje cały stan gry, a klienci tylko przesyłają swoje dane wejściowe, więc klient nigdy nie może zgłosić swojej własnej pozycji lub stanu. To zapobiega całym klasom oszustw, takim jak latanie czy oszustwa prędkości. Aby utrzymać responsywność rozgrywki, klienci przewidują wyniki swoich danych wejściowych, a serwer je koryguje, gdy przewidywanie jest błędne. Rozważ model autorytetu serwera dla gier konkurencyjnych, takich jak strzelanki, wyścigi, sporty i walki.

Bezpieczeństwo w projektowaniu

Zintegruj rozważania dotyczące bezpieczeństwa w projektowaniu 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 oszust wykorzystać to, jeśli ma 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 czy Workspace.

Zaufanie do urządzenia

Zasady na tej stronie chronią Twoją grę przed tym, co gracz robi po dołączeniu. Roblox oferuje również opcjonalne API Zaufania do Urządzenia, które sprawdza, czy urządzenie gracza może być zaufane w momencie dołączenia i zwraca wynik jako poziom zaufania do urządzenia. Roblox nie podejmuje żadnych działań na podstawie tego poziomu. To Ty decydujesz, jak Twoja gra reaguje, na przykład wysyłając graczy do oddzielnych miejsc w zależności od ich poziomu zaufania, ograniczając wrażliwe funkcje, takie jak handel, do zaufanych urządzeń lub odrzucając graczy, których urządzenia nie przeszły weryfikacji. Aby zacząć używać tego w swoich skryptach, zobacz odczytaj poziom zaufania.

Zaufanie do urządzenia nie zastępuje zasad na tej stronie. Oszustwa, które polegają na słabej walidacji po stronie serwera, nadal działają na zaufanych urządzeniach, więc nadal traktuj klienta jako niezaufanego i waliduj ważne działania na serwerze.