Il contenuto seguente tratta vari concetti e tattiche per migliorare la sicurezza e mitigarre le frodi nelle tue esperienze di Roblox. È altamente raccomandato che tutti gli sviluppatori leggano attentamente queste informazioni per garantire che le tue esperienze siano sicure e giuste 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 fondativi della sicurezza in Roblox. Un'esperienza sicura si basa su una mentalità che anticipa azioni avversarie. Prima di scrivere una sola riga di codice, devi interiorizzare questi principi fondamentali. Essi devono informare ogni decisione architettonica e di design che prendi.
Non fidarti mai del client
Questo è il principio fondativo. Un exploiter determinato ha il pieno controllo sul proprio stato locale e sul traffico di rete. Poiché gli exploiters hanno questo livello di controllo, qualsiasi misura di sicurezza che si basa su un'applicazione lato client sarà eventualmente elusa. Questo non è un limite di Roblox: è una realtà fondamentale delle architetture client-server. Assumi che ogni pezzo di dati inviato dal client sia stato manipolato, falsificato o inviato con intento malevolo. Questo include la possibilità di:
- Decompilare qualsiasi LocalScript replicato o qualsiasi ModuleScript, anche se non vengono mai eseguiti nel client
- Prendere il possesso della rete del proprio personaggio e di qualsiasi parte non ancorata
- Attivare eventi iniziati dal client come eventi Touched o attivazioni di ProximityPrompt a qualsiasi distanza o frequenza
- Modificare la posizione del giocatore, la fisica o le interazioni con il mondo
- Inviare o invocare RemoteEvents e RemoteFunctions a qualsiasi frequenza con argomenti arbitrari (oltre al 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 sul 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
- Validare che l'azione richiesta sia possibile e permessa
- Eseguire l'azione e aggiornare il suo stato autorevole
- Replicare i risultati a tutti i client rilevanti
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.
Sicurezza per design
Integra considerazioni di sicurezza nel design della tua esperienza fin dall'inizio, piuttosto che cercare di aggiungerle in seguito come un ripensamento.
- Modella le minacce per ogni nuova funzionalità. Per ogni nuova funzionalità, chiediti
- Come potrebbe un attaccante sfruttare questo se ha 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 più di 1,000 volte al secondo? Qual è la massima frequenza alla quale dovrebbe essere utilizzata?
- Potrebbe un exploiter usare questo per rovinare l'esperienza di un altro giocatore?
- Quante risorse, nel peggiore dei casi, potrebbe ragionevolmente utilizzare questa funzionalità?
- Qual è la minima informazione interna o stato che devo rendere noto per questa funzionalità?
- Suddividi le responsabilità sin dall'inizio. Mantieni la logica e i dati in ServerScriptService fin dal primo giorno. Non posizionarli mai in contenitori replicati come ReplicatedStorage o Workspace.