Tattiche di sicurezza e mitigazione delle frodi

Prima di immergersi in tattiche specifiche per sviluppare in modo sicuro e prevenire le frodi, è essenziale comprendere i principi fondamentali della sicurezza di Roblox. Un gioco sicuro è costruito su una mentalità che anticipa azioni avversarie. Prima di scrivere una sola riga di codice, devi interiorizzare questi principi fondamentali. Dovrebbero informare ogni decisione architettonica e di design che prendi.

Non fidarti mai del client

Questo è il principio fondamentale. Un exploit determinato ha il completo controllo sul proprio stato locale e sul traffico di rete. Poiché gli exploitatori hanno questo livello di controllo, qualsiasi misura di sicurezza che si basa sull'applicazione lato client sarà eventualmente elusa. Questa non è una limitazione di Roblox: è una realtà fondamentale delle architetture client-server. Assumi che ogni pezzo di dati inviato dal client sia stato manipolato, fabbricato o inviato con intento malevolo. Questo include il potere di:

• Decompilare qualsiasi LocalScript replicato o qualsiasi ModuleScript, anche se non vengono mai eseguiti sul client
• Prendere possesso della rete del proprio personaggio e di qualsiasi parte non ancorata
• Attivare eventi avviati dal client come eventi Touched o attivazioni di ProximityPrompt a qualsiasi distanza o frequenza
• Modificare la posizione del proprio giocatore, la fisica o le interazioni con il mondo
• Attivare o invocare RemoteEvents e RemoteFunctions a qualsiasi frequenza con argomenti arbitrari (tranne il primo argomento Player)
• Cambiare qualsiasi cosa nel proprio DataModel locale senza attivare eventi attesi
• Alterare arbitrariamente il comportamento di qualsiasi codice in esecuzione localmente

A causa di ciò, tutta la logica critica deve essere convalidata lato server o eseguita esclusivamente sul server. Le conseguenze di questo controllo sono dettagliate in Network Ownership, Movement Validation, and Physics Exploits e Access Control and Confidentiality.

Il server come fonte di verità

Il server deve essere l'ultima fonte di verità per tutti gli stati di simulazione, regole, progressione dei giocatori e decisioni critiche. Il ruolo del client è quello di rendere il mondo e inviare input utente al server.

Il ruolo del server è:

• Ricevere input dal client
• Convalidare che l'azione richiesta sia possibile e permessa
• Eseguire l'azione e aggiornare il suo stato autorevole
• Replicare i risultati a tutti i client pertinenti

Ad esempio, se un giocatore dice "Voglio comprare una Bloxy Cola", il server deve conoscere il vero prezzo dell'oggetto, il denaro del giocatore e la distanza fisica del personaggio dal negozio prima di convalidare e approvare la transazione. Il più possibile, lo stato da convalidare dovrebbe essere mantenuto esclusivamente dal server e non dai client. Nell'esempio, se la transazione della Bloxy Cola viene approvata, il server dovrebbe sottrarre il prezzo della Bloxy Cola dal denaro del giocatore, tuttavia, il server non può necessariamente controllare sempre il personaggio del giocatore.

Questo principio è diverso dall'autorità del server, una funzionalità del motore che lo applica alla fisica e al movimento. Nel modello di autorità del server, il server simula l'intero stato del gioco e i client inviano solo i loro input, quindi un client non può mai segnalare la propria posizione o stato. Questo previene intere classi di frodi, come il volo o gli hack di velocità. Per mantenere il gameplay reattivo, i client prevedono i risultati dei loro input e il server li corregge quando una previsione è errata. Considera il modello di autorità del server per giochi competitivi come sparatutto, corse, sport e combattimento.

Sicurezza per design

Integra le considerazioni di sicurezza nel design del tuo gioco fin dall'inizio, piuttosto che tentare di aggiungerle successivamente come un ripensamento.

• Modella le minacce per ogni nuova funzionalità. Per ogni nuova funzionalità, chiediti

  • Come potrebbe un attaccante sfruttare questo se avesse il pieno controllo del proprio client?
  • Se un client potesse inviare qualsiasi valore per qualsiasi parametro utilizzato nella funzionalità, qual è il peggior risultato possibile?
  • Cosa succede se questa funzionalità viene utilizzata 1.000+ volte al secondo? Qual è il tasso massimo al quale dovrebbe essere utilizzata?
  • Un exploit potrebbe usarlo per rovinare l'esperienza di un altro giocatore?
  • Quante risorse, nel peggior caso, potrebbe utilizzare questa funzionalità?
  • Qual è il minimo di informazioni interne o stato che devo esporre per questa funzionalità?
• Partiziona le responsabilità in anticipo. Mantieni la logica e i dati in ServerScriptService fin dal primo giorno. Non metterli mai in contenitori replicati come ReplicatedStorage o Workspace.

Fiducia del dispositivo

I principi in questa pagina proteggono il tuo gioco da ciò che un giocatore fa dopo essersi unito. Roblox fornisce anche l'opzionale Device Trust API, che verifica se il dispositivo del giocatore può essere considerato affidabile mentre si unisce e ti fornisce il risultato come un livello di fiducia del dispositivo. Roblox non intraprende alcuna azione basata su questo livello. Sei tu a decidere come il tuo gioco risponde, ad esempio inviando i giocatori in luoghi separati in base al loro livello di fiducia, limitando funzionalità sensibili come il trading a dispositivi fidati, o rifiutando i giocatori i cui dispositivi non superano il controllo. Per iniziare a usarlo nei tuoi script, consulta leggi il livello di fiducia.

La fiducia del dispositivo non sostituisce i principi in questa pagina. Gli exploit che si basano su una convalida lato server debole funzionano ancora su dispositivi fidati, quindi continua a trattare il client come non affidabile e a convalidare azioni importanti sul server.