Controllo accessi e riservatezza

Comprendere quali informazioni e risorse sono visibili ai client è fondamentale per mantenere sia la sicurezza che la riservatezza della tua esperienza. Gli sviluppatori spesso sottovalutano quanto sia visibile agli exploitatori e replicato ai client. Gli exploitatori hanno la possibilità di accedere a luoghi "riservati" all'interno del tuo universo se possono unirsi a un singolo luogo. Possono visualizzare qualsiasi contenuto replicato al loro client, indipendentemente dal fatto che sia visibile o attualmente utilizzato. Inoltre, gli exploitatori possono decompilare qualsiasi script locale e ModuleScript replicato, anche se non vengono mai eseguiti sul client.

Teletrasporto lato client all'interno degli universi

Una volta all'interno di un universo, i client possono teletrasportarsi a qualsiasi luogo all'interno di quell'universo, potenzialmente aggirando qualsiasi restrizione di accesso o porta di progressione prevista. Ciò può portare anche alla fuga involontaria di contenuti non rilasciati, ad esempio da un'esperienza di sviluppo o di staging. È importante capire che:

• Disabilitare "Accesso Diretto" rimuove solo il pulsante Unisciti dai sottolughi sul sito web — non impedisce i teletrasporti avviati dal client
• Assumi che gli exploitatori scopriranno l'esistenza di tutti i sottolughi all'interno del tuo universo
• Un client può teletrasportarsi a qualsiasi sottoluglio se può accedere a un singolo luogo, come il luogo radice, indipendentemente dal tuo flusso di progettazione previsto

Molti sviluppatori tentano di prevenire l'accesso espellendo gli utenti non autorizzati da un sottoluglio. Questo può funzionare per bloccare il gameplay, ma non impedisce la replicazione del contenuto al client, poiché la replicazione inizia non appena il giocatore si unisce e prima che la logica di espulsione sul server possa eseguire.

Utilizza teletrasporti sicuri

Il modo più efficace per prevenire accessi non autorizzati tramite teletrasporto è impostare il Controllo Accessi per i Luoghi su Sicuro solo all'interno dell'universo nel Creator Dashboard. Questo limita tutti i luoghi non di avvio a teletrasporti avviati dal server, bloccando i teletrasporti avviati dal client a livello di piattaforma prima che il giocatore si unisca mai al sottoluglio. Poiché il giocatore non si unisce, nessun contenuto viene replicato per loro.

Per i passaggi di configurazione e le linee guida per la migrazione delle esperienze esistenti che utilizzano teletrasporti avviati dal client, vedere Teletrasporta tra i luoghi.

Difesa a più livelli per luoghi riservati

Per gli universi che non possono utilizzare teletrasporti sicuri, o come ulteriori strati di protezione accanto a essi, combina le seguenti misure:

• Mantieni i luoghi di sviluppo e test in universi separati e privati — questo è l'unico modo affidabile per garantire la riservatezza per contenuti non rilasciati. Non spedire mai asset, script o elementi UI riservati all'ambiente di produzione prima che siano pronti per essere attivi.
• Se possibile, utilizza lo streaming per limitare quanto del mondo si replica a un nuovo giocatore.
• Aggiungi verifiche del ruolo di gruppo o del badge sul server e verifica lo stato del giocatore o i requisiti di progressione.
• Per impostazione predefinita, vieta l'ingresso ai nuovi giocatori. Ciò garantisce che nessun giocatore sarà autorizzato ad entrare anche se il processo di verifica è inconcludente, ad esempio nel caso di un'eccezione generata dal motore.
• Se pratico, utilizza il Ban API per i giocatori che non superano la convalida. Questo impedisce ai giocatori di tentare continuamente di unirsi con lo stesso account.

Replicazione

La replicazione descrive come lo stato si trasferisce attraverso la rete tra istanze del motore. Il modello di replicazione di Roblox è generalmente semplificato in alcuni modi chiave:

• Le istanze sono autorità dal server, il che significa che per un'istanza replicarsi tra tutti i partecipanti (il server e tutti i client connessi) deve essere creata sul server.
• Anche le proprietà delle istanze sono autorità dal server, il che significa che la maggior parte delle proprietà deve essere cambiata sul server per essere visibile a tutti i client.
• In generale, un'istanza o si replica a tutti i client connessi o non lo fa. Ci sono alcune eccezioni, come lo streaming.

I contenitori di replicazione sono istanze di alto livello (ordinate sotto il DataModel) che si replicano ai client. Se un'istanza diventa mai un discendente di un contenitore di replicazione nel suo ciclo di vita, dovresti aspettarti che gran parte del suo stato si replichi a tutti i client. Puoi leggere di più sui contenitori di replicazione comuni nella guida al modello di dati. In caso di dubbi, puoi sempre controllare come un'istanza o una proprietà si replica in un ambiente di test come Play Solo. Puoi leggere di più sulle modalità di test in Modalità di test dello Studio.

Implicazioni di sicurezza della replicazione

Qualsiasi contenuto che si replica a un client può essere estratto e analizzato da un exploitore. Come regola generale, evita di pubblicare o spedire qualsiasi contenuto riservato all'ambiente di produzione dal vivo a meno che tu non sia immediatamente pronto per farlo vedere dagli utenti. Anche se esiste una logica che limita il rilascio o l'accesso al contenuto nell'esperienza fino a una data successiva (o a qualche altra condizione), assumi che gli exploitatori troveranno un modo per scoprire e diffondere i tuoi contenuti non appena vengono pubblicati.

Evita nomi eccessivamente descrittivi o prevedibili per istanze sensibili, inclusi, ma non limitati a: script, remoti e modelli. Avere una gerarchia DataModel prevedibile facilita lo sviluppo di exploit.

Decompilazione degli script

Qualsiasi LocalScript, Script con RunContext::Client, o ModuleScript può essere decompilato da un exploitore una volta replicato al loro client, anche se tali script sono disabilitati, mai richiesti o mai eseguiti sul client. Script e ModuleScript solo per server memorizzati in ServerStorage o ServerScriptService non possono essere decompilati poiché non si replicano mai ai client.

Scrivere un ModuleScript che include codice solo per server e codice solo per client nello stesso script è sconsigliato poiché la logica lato server sarà esposta nella decompilazione e potrà essere più facilmente analizzata per trovare bug che possono essere sfruttati.

Original ModuleScript in ReplicatedStorage
local module = {}

local Remote = script:WaitForChild("RemoteEvent")

-- Ecco un esempio di un paradigma da evitare
-- Mantieni il codice server in istanze Script o in ServerStorage/ServerScriptStorage!

if game:GetService("RunService"):IsServer() then
  function module:DoServerThing(password)
    if password == "SecretPassword" then
      print("codice server sensibile")
    end
  end

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

return module

Risultato decompilato
local table1 = {};
local RemoteEvent = script:WaitForChild("RemoteEvent");
if game:GetService("RunService"):IsServer() then
  function table1.DoServerThing(_, p2) -- Linea: 9
    if p2 == "SecretPassword" then
      print("codice server sensibile");
    end
  end
  RemoteEvent.OnServerEvent:Connect(function(player: Player, p3) -- Linea: 15
    --[[
      Upvalues:
        [1] = table1
    --]]
    table1:DoServerThing(p3);
  end);
  return table1;
end
function table1.DoServerThing(_, p1) -- Linea: 19
  --[[
    Upvalues:
      [1] = RemoteEvent
  --]]
  RemoteEvent:FireServer(p1);
end
return table1;

Come mostrato sopra, la decompilazione rivela logiche lato server inclusi password hardcoded, regole aziendali e dettagli di implementazione che possono essere analizzati dagli exploitatori per vulnerabilità.

Impatto delle violazioni della riservatezza

Le violazioni della riservatezza possono avere conseguenze significative, come:

• Fughe di contenuti: Articoli, mappe o funzionalità non rilasciate possono essere scoperte e condivise pubblicamente prima degli annunci ufficiali
• Svantaggio competitivo: Meccaniche, algoritmi o funzionalità future possono essere ingegnerizzati a ritroso dai concorrenti
• Sviluppo di exploit: La logica server esposta rende più veloce e facile per gli exploitatori identificare vulnerabilità e sviluppare attacchi mirati