Controllo degli accessi e riservatezza

Comprendere quali informazioni e risorse sono visibili ai client è fondamentale per mantenere sia la sicurezza che la riservatezza del tuo gioco. Gli sviluppatori spesso sottovalutano quanto sia visibile agli sfruttatori e replicato ai client. Gli sfruttatori 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 in uso. Inoltre, gli sfruttatori 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 eludendo qualsiasi restrizione di accesso o porte di progresso previste. Questo può anche portare alla fuga involontaria di contenuti non rilasciati, ad esempio da un gioco di sviluppo o di staging. È importante comprendere che:

• Disabilitare "Accesso diretto" rimuove solo il pulsante Unisciti dai sottolughi sul sito web — non impedisce i teletrasporti avviati dal client
• Assumi che gli sfruttatori 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 principale, indipendentemente dal tuo flusso di design 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 lato server possa essere eseguita.

Utilizza teletrasporti sicuri

Il modo più efficace per prevenire l'accesso non autorizzato tramite teletrasporto è impostare il Controllo degli accessi per i luoghi su Sicuro solo all'interno dell'universo nel Creator Dashboard. Questo limita tutti i luoghi non di avvio ai 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 mai, nessun contenuto viene replicato a lui.

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

Difesa in profondità per luoghi riservati

Per gli universi che non possono utilizzare teletrasporti sicuri, o come ulteriori strati di protezione insieme 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 dei contenuti non rilasciati. Non spedire mai risorse, script o elementi UI riservati nell'ambiente di produzione prima che siano destinati a essere attivi.
• Se possibile, utilizza lo streaming per limitare quanto del mondo viene replicato a un nuovo giocatore.
• Aggiungi la verifica del ruolo di gruppo o del badge lato server e verifica lo stato o i requisiti di progresso del giocatore.
• Per impostazione predefinita, vieta l'ingresso ai giocatori in arrivo. Questo garantisce che nessun giocatore sarà autorizzato a entrare anche se il processo di verifica è inconcludente, come nel caso di un'eccezione generata dal motore.
• Se pratico, utilizza l'API Ban per i giocatori che non superano la validazione. Questo impedisce ai giocatori di tentare continuamente di unirsi con lo stesso account.

Replicazione

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

• Le istanze sono autoritative dal server, il che significa che affinché un'istanza venga replicata tra tutti i partecipanti (il server e tutti i client connessi) deve essere creata sul server.
• Anche le proprietà delle istanze sono autoritative dal server, il che significa che la maggior parte delle proprietà deve essere modificata sul server affinché le modifiche siano visibili 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 (parentate sotto il DataModel) che si replicano ai client. Se un'istanza diventa mai un discendente di un contenitore di replicazione durante la sua 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. Quando hai dubbi, puoi sempre controllare come un'istanza o una proprietà si replica in un ambiente di test come Play Solo. Puoi leggere di più sui modi di testare in Modalità di test di Studio.

Implicazioni di sicurezza della replicazione

Qualsiasi contenuto che si replica a un client può essere estratto e analizzato da un sfruttatore. Come regola generale, evita di pubblicare o spedire contenuti riservati nell'ambiente di produzione live a meno che tu non sia immediatamente pronto affinché venga visto dagli utenti. Anche se c'è una logica che limita il rilascio o l'accesso al contenuto nel gioco fino a una data successiva (o a qualche altra condizione), assumi che gli sfruttatori troveranno un modo per scoprire e divulgare il tuo contenuto non appena viene pubblicato.

Evita nomi eccessivamente descrittivi o prevedibili per istanze sensibili, inclusi ma non limitati a: script, remoti e modelli. Avere una gerarchia del DataModel prevedibile rende più facile sviluppare exploit.

Decompilazione degli script

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

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

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

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 la logica lato server, inclusi password hardcoded, regole aziendali e dettagli di implementazione che gli sfruttatori possono analizzare per vulnerabilità.

Impatto delle violazioni della riservatezza

Le violazioni della riservatezza possono avere conseguenze significative, come:

• Fughe di contenuto: Oggetti, mappe o funzionalità non rilasciate possono essere scoperti e condivisi pubblicamente prima degli annunci ufficiali
• Svantaggio competitivo: Meccaniche, algoritmi o funzionalità future possono essere reverse-engineered dai concorrenti
• Sviluppo di exploit: La logica server esposta rende più veloce e facile per gli sfruttatori identificare vulnerabilità e sviluppare attacchi mirati