Limiti di sicurezza dei giochi per browser: CSP, SRI e Trusted Types

Un browser game sicuro inizia con un confine chiaro: tutto ciò che viene fornito al giocatore è ispezionabile e potenzialmente modificabile, mentre account, scommesse e risultati autorevoli rimangono su sistemi server affidabili. I controlli del browser come Content Security Policy, Subresource Integrity e Trusted Types riducono quindi specifici percorsi di attacco lato client all’interno di quel modello più grande.

Questi controlli si completano a vicenda. CSP limita ciò che il documento può caricare o eseguire. SRI verifica che le risorse esterne selezionate corrispondano al digest crittografico previsto. Trusted Types può limitare i pericolosi pozzi di iniezione DOM a valori prodotti da politiche approvate. Nessuno trasforma il codice client in un segreto e nessuno compensa una decisione autorevole lasciata nel browser.

Mappare prima ogni eseguibile e ogni origine di rete

Una politica dovrebbe iniziare con un inventario di ciò che il gioco effettivamente carica: documenti, script, lavoratori, moduli WebAssembly, trame, caratteri, audio, connessioni API, telemetria e frame incorporati. Registrare il proprietario e lo scopo di ogni origine. Una dipendenza sconosciuta non può ricevere un’autorizzazione deliberata.

Ridurre l’elenco prima di codificarlo in CSP. Ospita autonomamente risorse stabili, ove appropriato, rimuovi i tracker inutilizzati e mantieni gli endpoint di sviluppo fuori dalla configurazione di produzione. I caratteri jolly ampi rendono una politica più facile da implementare ma più debole come confine di applicazione.

Tratta il codice di terze parti come codice, anche quando arriva tramite analisi o un tag manager. Uno script attendibile può manipolare il documento entro le capacità fornite dalla pagina. Se una dipendenza necessita solo di dati di eventi, preferisci un’integrazione ristretta lato server o un frame isolato rispetto all’esecuzione illimitata del documento principale quando l’architettura del prodotto lo consente.

Costruisci CSP attorno a nonce o hash

Guida CSP di MDN spiega come l’intestazione della risposta può limitare i tipi di risorse e l’esecuzione degli script. Una politica moderna e rigorosa in genere autorizza gli script dell’applicazione previsti con nonce per risposta o hash in fase di compilazione invece di mantenere un lungo elenco di host.

Inizia in modalità Content-Security-Policy-Report-Only, raccogli le violazioni, rimuovi le dipendenze impreviste e quindi applica la policy. La segnalazione è un aiuto alla migrazione, non un motivo per disattivare l’applicazione delle norme. Filtra i dati sensibili dai report e aspettati rumore dalle estensioni del browser o dal software locale inserito.

Evitare unsafe-inline e unsafe-eval a meno che non siano richiesti da un vincolo di compatibilità misurato e documentato. Alcuni motori di gioco o bundle legacy compilano dinamicamente il codice; tale comportamento dovrebbe essere identificato durante il controllo della creazione, non scoperto quando l’applicazione raggiunge la produzione.

Direttive separate per capacità. script-src, connect-src, img-src, font-src, worker-src e frame-src rispondono a domande diverse. Un gioco che apre connessioni WebSocket o crea nodi di lavoro necessita che gli endpoint siano dichiarati senza concedere la stessa autorizzazione di origine agli script.

Utilizzare SRI per risorse esterne immutabili

Integrità delle risorse secondarie consente a un collegamento script o a un foglio di stile di dichiarare uno o più digest crittografici. Il browser esegue l’hashing della risorsa recuperata e rifiuta una risposta che non corrisponde. Ciò è utile quando si prevede che una risorsa ospitata esternamente sia immutabile.

SRI non è la gestione automatica delle dipendenze. Ogni modifica approvata alle risorse richiede la corrispondenza dei metadati di integrità e i recuperi SRI multiorigine dipendono anche dal server remoto che consente la richiesta tramite CORS. Se un fornitore fornisce contenuti modificabili da un URL, il blocco di un digest interromperà correttamente tale comportamento; l’integrazione deve passare a un artefatto con versione o a un modello di attendibilità diverso.

Genera valori di integrità dall’artefatto di rilascio, non da una copia dello sviluppatore, e testa la risposta distribuita. La trasformazione del contenuto da parte di un proxy o di una rete CDN modifica i byte e dovrebbe causare il fallimento della verifica. Conservare l’artefatto e il relativo digest nelle prove di rilascio in modo che un incidente possa collegare la pagina all’esatta dipendenza prevista.

Utilizzare Trusted Types per ridurre i percorsi di iniezione DOM

Trusted Types API DOM di destinazione in grado di interpretare le stringhe come HTML o script. Quando l’imposizione è abilitata, i sink protetti accettano valori tipizzati creati da policy registrate anziché stringhe arbitrarie. Ciò trasforma le decisioni di iniezione sparse in un insieme più piccolo di trasformazioni rivedibili.

Lo W3C Trusted Types documento è una bozza di lavoro, non una raccomandazione finale. È necessario verificare il supporto del browser per la matrice del dispositivo del prodotto e resta necessaria la costruzione sicura di DOM. La migrazione corretta consiste nel rimuovere prima la costruzione di stringhe HTML non necessarie, quindi inserire una sanificazione o un modello strettamente revisionato dietro le policy denominate.

Non creare una policy predefinita che restituisca ciecamente ogni input. Ciò soddisfa una forma API preservando la vulnerabilità. Ogni policy dovrebbe avere uno scopo, chiara provenienza degli input e test con payload dannosi.

Mantieni l’autorità e i segreti del gioco sul server

CSP, SRI e Trusted Types proteggono l’esecuzione dei documenti; non rendono affidabile il saldo, il risultato RNG, il diritto o la chiave di firma quando archiviati nel client. JavaScript e WebAssembly vengono entrambi eseguiti in un ambiente controllato dal giocatore.

Il client può restituire un risultato e rifiutare input ovviamente non corretti per l’usabilità, ma il server deve autenticare la sessione, convalidare le azioni consentite e il proprio stato autorevole. Utilizzare credenziali con ambito di breve durata e cookie o token sicuri standard adeguati all’architettura. Non spedire mai una chiave privata riutilizzabile, una credenziale del database o un token di servizio privilegiato in un pacchetto.

Questo stesso confine informa WebAssembly utilizzato nei giochi da casinò: la compilazione cambia la rappresentazione, non la fiducia. Appartiene anche alla fase di progettazione di sviluppo di giochi da casinò, prima che le integrazioni di terze parti accumulino privilegi impliciti.

Trasforma le violazioni delle policy in un cancello di rilascio

Automatizza i controlli per le intestazioni di produzione, il comportamento nonce o hash, gli errori SRI e l’esecuzione in linea vietata. Esercita l’accesso, il caricamento del gioco, i lavoratori, le chiamate API e i percorsi di errore in base alla politica applicata. Una home page che passa mentre il gioco perde silenziosamente il suo lavoratore non è una distribuzione riuscita.

Conserva un piccolo set di test negativi intenzionali. Modifica una risorsa bloccata e conferma che SRI la blocca. Tentare una connessione non approvata e confermare che CSP lo segnala e lo impedisce. Passa una stringa non attendibile in un sink protetto e conferma che l’applicazione la rifiuta. Un cancello di sicurezza che non ha mai dimostrato un cedimento non è ancora una prova.

Esamina l’inventario di origine con ogni nuovo fornitore, aggiornamento del motore e host di risorse. Le policy decadono quando i team aggiungono eccezioni senza rimuovere quelle obsolete. La politica più sicura è quella più ristretta che supporta il comportamento di produzione verificato.

Domande frequenti

Che cosa fa la politica di sicurezza dei contenuti per un gioco per browser?

La politica di sicurezza dei contenuti indica al browser quali origini e modelli di esecuzione una pagina può utilizzare. Una policy rigorosa può ridurre i percorsi attraverso i quali il contenuto inserito diventa eseguibile, ma non sostituisce la codifica dell’output o la progettazione sicura dell’applicazione.

Cos’è l’integrità delle risorse secondarie?

L’integrità della risorsa secondaria consente a una pagina di fornire un hash crittografico per uno script o un foglio di stile recuperato. Il browser confronta la risposta con quell’hash e rifiuta di utilizzare una risorsa non corrispondente.

Cosa sono Trusted Types?

Trusted Types sono un’API del browser per limitare i pericolosi sink di iniezione DOM ai valori creati da policy approvate. Il documento W3C è ancora una bozza funzionante, quindi i team devono verificare il supporto del browser e mantenere pratiche di codifica sicure.

CSP blocca ogni attacco di cross-site scripting?

No. CSP è la difesa in profondità. Una lista consentita debole, un’esecuzione in linea non sicura, script attendibili vulnerabili o una gestione dei dati non sicura possono comunque lasciare percorsi sfruttabili. Prevenire l’iniezione rimane il primo controllo.

Un gioco per browser può mantenere segreti in JavaScript o WebAssembly?

No. Il codice e i dati forniti a un browser controllato dal giocatore devono essere trattati come ispezionabili e modificabili. Segreti di lunga durata e decisioni di scommessa autorevoli appartengono a sistemi server affidabili.

Come dovrebbero essere controllati gli script di giochi di terze parti?

Riducili al minimo, blocca le versioni approvate, caricale da origini esplicite, applica i metadati di integrità dove si adattano, isolali quando possibile e rivedi ogni funzionalità che ricevono. Un tag manager non dovrebbe diventare un percorso di esecuzione senza restrizioni.