Il contenuto seguente copre vari concetti e tattiche per migliorare la sicurezza e mitigare le frodi nei tuoi giochi Roblox. È altamente raccomandato che tutti gli sviluppatori leggano attentamente queste informazioni per garantire che i tuoi giochi siano sicuri e giusti per tutti gli utenti. Controlla la barra laterale per ulteriori argomenti di sicurezza.
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 singola 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.
Autorità del server
Il server deve essere la fonte ultima 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 è di:
- Ricevere input dal client
- Convalidare che l'azione richiesta sia possibile e permessa
- Eseguire l'azione e aggiornare il proprio 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 del giocatore 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.
Sicurezza per design
Integra 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 è la frequenza massima con cui 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à precocemente. Mantieni la logica e i dati in ServerScriptService fin dal primo giorno. Non metterli mai in contenitori replicati come ReplicatedStorage o Workspace.