Kontrola dostępu i poufność

Zrozumienie, jakie informacje i zasoby są widoczne dla klientów, jest kluczowe dla utrzymania zarówno bezpieczeństwa, jak i poufności twojego doświadczenia. Deweloperzy często nie doceniają, ile jest widoczne dla oszustów i replikowane dla klientów. Oszuści mają możliwość dostępu do "zablokowanych" miejsc w twoim uniwersum, jeśli mogą dołączyć do jednego miejsca. Mogą przeglądać wszelkie treści replikowane do ich klientów, niezależnie od tego, czy są widoczne, czy aktualnie używane. Dodatkowo, oszuści mogą dekompilować wszelkie replikowane lokalne skrypty i ModuleScripts, nawet jeśli nigdy nie są uruchamiane po stronie klienta.

Teleportacja po stronie klienta w uniwersach

Gdy klienci są wewnątrz uniwersum, mogą teleportować się do dowolnego miejsca w tym uniwersum, potencjalnie omijając wszelkie zamierzone ograniczenia dostępu lub bramy postępów. Może to również prowadzić do niezamierzonego wycieku niewydanych treści, na przykład z doświadczenia deweloperskiego lub testowego. Ważne jest, aby zrozumieć, że:

• Wyłączenie "Dostępu bezpośredniego" jedynie usuwa przycisk Dołącz z podmiejsc na stronie internetowej — nie zapobiega to teleportacjom inicjowanym przez klienta.
• Zakładaj, że oszuści odkryją istnienie wszystkich podmiejsc w twoim uniwersum.
• Klient może teleportować się do dowolnego podmiejsca, jeśli ma dostęp do jednego miejsca, takiego jak miejsce główne, niezależnie od twojego zamierzonego przepływu projektowania.

Wielu deweloperów próbuje zapobiec dostępowi, wyrzucając nieautoryzowanych użytkowników z podmiejsca. To może działać w przypadku blokowania rozgrywki, ale nie zapobiega replicacji treści do klienta, ponieważ replikacja rozpoczyna się, gdy gracz dołącza, zanim logika wyrzucenia po stronie serwera może zostać wykonana.

Używaj bezpiecznych teleportacji

Najskuteczniejszym sposobem zapobiegania nieautoryzowanemu dostępowi poprzez teleportację jest ustawienie Kontroli dostępu do miejsc na Bezpieczne tylko w uniwersum w Panelu twórcy. To ogranicza wszystkie miejsca inne niż startowe do teleportacji inicjowanych przez serwer, blokując teleportacje inicjowane przez klientów na poziomie platformy, zanim gracz w ogóle dołączy do podmiejsca. Ponieważ gracz nigdy nie dołącza, żadne treści nie replikują się dla niego.

Aby uzyskać kroki konfiguracyjne i wskazówki dotyczące migracji dla istniejących doświadczeń, które używają teleportacji inicjowanej przez klienta, zobacz Teleportacja między miejscami.

Ochrona wielowarstwowa dla zablokowanych miejsc

Dla uniwersów, które nie mogą korzystać z bezpiecznych teleportacji lub jako dodatkowe warstwy ochrony obok nich, połącz następujące środki:

• Zachowaj miejsca deweloperskie i testowe w oddzielnych, prywatnych uniwersach — to jedyny niezawodny sposób na zapewnienie poufności dla niewydanych treści. Nigdy nie publikuj poufnych zasobów wydarzeń, skryptów ani elementów UI w środowisku produkcyjnym, zanim nie będą przeznaczone do aktywacji.
• Jeśli to możliwe, użyj strumieniowania, aby ograniczyć, ile świata replikuję do nowego gracza.
• Dodaj weryfikację ról grup serwerowych lub odznak i sprawdź stan gracza lub wymagania postępu.
• Domyślnie zabroń przychodzącym graczom. To zapewnia, że żaden gracz nie będzie miał zezwolenia na wejście, nawet jeśli proces weryfikacji jest niejednoznaczny, jak w przypadku wyjątku wyrzuconego z silnika.
• Jeśli to praktyczne, używaj Ban API dla graczy, którzy nie przeszli walidacji. To zapobiega graczom w nieustannym próbującym dołączyć na to samo konto.

Replikacja

Replikacja opisuje, jak stan transferuje się przez sieć pomiędzy instancjami silnika. Model replikacji Roblox jest na ogół uproszczony w kilku kluczowych punktach:

• Instancje są autorytatywne po stronie serwera, co oznacza, że aby instancja mogła się replikować pomiędzy wszystkimi uczestnikami (serwerem i wszystkimi podłączonymi klientami), musi być tworzona na serwerze.
• Właściwości instancji są również autorytatywne po stronie serwera, co oznacza, że większość właściwości musi być zmieniana po stronie serwera, aby zmiany były widoczne dla wszystkich klientów.
• Generalnie mówiąc, instancja albo replikuję do wszystkich podłączonych klientów, albo nie. Istnieją pewne wyjątki, takie jak strumieniowanie.

Kontenery replikacji to instancje najwyższego poziomu (parentowane pod DataModel), które replikują się do klientów. Jeśli instancja kiedykolwiek stanie się potomkiem kontenera replikacji w swoim życiu, powinieneś oczekiwać, że wiele z jej stanu zreplikuje się do wszystkich klientów. Możesz przeczytać więcej o typowych kontenerach replikacji w Przewodniku po modelu danych. Kiedy masz wątpliwości, zawsze możesz sprawdzić, jak instancja lub właściwość replikują się w środowisku testowym, takim jak Graj Solo. Możesz przeczytać więcej o trybach testowych w Trybach testowania w Studio.

Implkacje bezpieczeństwa replikacji

Jakiekolwiek treści replikowane do klienta mogą być wydobywane i analizowane przez oszusta. Zasadniczo unikaj publikowania lub dostarczania jakichkolwiek poufnych treści do rzeczywistego środowiska produkcyjnego, chyba że jesteś natychmiast przygotowany na ich widoczność dla użytkowników. Nawet jeśli istnieje logika, która blokuje wydanie lub dostęp do treści w doświadczeniu do późniejszej daty (lub innego warunku), zakładaj, że oszuści znajdą sposób na odkrycie i wyciek treści, gdy tylko zostanie opublikowana.

Unikaj zbyt opisowych lub przewidywalnych nazw dla wrażliwych instancji, w tym, ale nie tylko: skryptów, zdalnych i modeli. Posiadanie przewidywalnej hierarchii DataModel ułatwia rozwijanie exploitów.

Dekompilacja skryptów

Każdy LocalScript, Script z RunContext::Client, lub ModuleScript może być dekompilowany przez oszusta, gdy tylko zostanie zreplikowany do ich klienta, nawet jeśli takie skrypty są wyłączone, nigdy nie wymagane, lub nigdy nie uruchamiane po stronie klienta. Skrypty i ModuleScripts tylko po stronie serwera, przechowywane w ServerStorage lub ServerScriptService, nie mogą być dekompilowane, ponieważ nigdy nie replikują się do klientów.

Pisanie ModuleScript, które zawiera kod tylko po stronie serwera i kod tylko po stronie klienta w tym samym skrypcie jest niezalecane, ponieważ logika po stronie serwera będzie ujawniona podczas dekompilacji i łatwiej może zostać zbadana pod kątem błędów, które można wykorzystać.

Oryginalny ModuleScript w ReplicatedStorage
local module = {}

local Remote = script:WaitForChild("RemoteEvent")

-- Oto przykład paradygmatu, którego należy unikać
-- Zachowaj kod serwera w instancjach Skryptu lub w ServerStorage/ServerScriptStorage!

if game:GetService("RunService"):IsServer() then
  function module:DoServerThing(password)
    if password == "SecretPassword" then
      print("wrażliwy kod serwera")
    end
  end

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

return module

Wynik dekompilacji
local table1 = {};
local RemoteEvent = script:WaitForChild("RemoteEvent");
if game:GetService("RunService"):IsServer() then
  function table1.DoServerThing(_, p2) -- Linia: 9
    if p2 == "SecretPassword" then
      print("wrażliwy kod serwera");
    end
  end
  RemoteEvent.OnServerEvent:Connect(function(player: Player, p3) -- Linia: 15
    --[[
      Upvalues:
        [1] = table1
    --]]
    table1:DoServerThing(p3);
  end);
  return table1;
end
function table1.DoServerThing(_, p1) -- Linia: 19
  --[[
    Upvalues:
      [1] = RemoteEvent
  --]]
  RemoteEvent:FireServer(p1);
end
return table1;

Jak pokazano powyżej, dekompilacja ujawnia logikę po stronie serwera, w tym twardo zakodowane hasła, zasady biznesowe i szczegóły implementacji, które oszuści mogą analizować w celu znalezienia luk.

Skutki naruszeń poufności

Naruszenia poufności mogą mieć poważne konsekwencje, takie jak:

• Wycieki treści: Niewydane przedmioty, mapy lub funkcje mogą zostać odkryte i udostępnione publicznie przed oficjalnymi ogłoszeniami.
• Niekorzystna sytuacja konkurencyjna: Mechanika, algorytmy lub nadchodzące funkcje mogą zostać odwrotne z inżynieryjny przez konkurencję.
• Rozwój exploitów: Ujawniona logika serwera pozwala oszustom szybciej i łatwiej zidentyfikować luki i opracować ukierunkowane ataki.