InfoSec è sempre un equilibrio tra rischio, costo e convenienza. Nel tuo caso stiamo parlando di un gioco che forse non è ben noto, quindi non è un obiettivo di alto valore. Se non c'è letteralmente nulla che valga la pena di hackerare, non c'è nulla che valga la pena proteggere.
Inoltre, InfoSec tende a concentrarsi su modellazione delle minacce specifico vettori di attacco . Potresti non dover fare nulla se non ci sono attacchi che ti causerebbero dolore, ad es. se gli unici attacchi che potrebbero funzionare sono quelli che non influenzano nulla di importante per le tue operazioni. Quindi dovresti provare ad elencarli. Che tipo di cose sei preoccupato che un hacker possa realizzare? Ad esempio, è un grosso problema se qualcuno può modificare i propri punteggi e rapporti? È un grosso problema se potessero vedere i punteggi di qualcun altro? Se potessero modificarli? Ecc.
Detto questo, posso introdurti a un paio di pratiche generali che sicuramente non farebbero male a nessuno se le facessi:
Se si stanno effettivamente memorizzando i dati nei cookie (al contrario di un identificatore che può essere utilizzato per ottenere dati), i cookie possono essere modificati da qualsiasi utente che detenga il controllo della macchina su cui è memorizzato il cookie. Ovviamente, possono solo modificare i propri cookie. Ma se questo è ancora un problema, puoi rendere i tuoi cookie un po 'resistenti alle manomissioni attraverso vari mezzi: puoi cifrare il cookie (probabilmente usando la crittografia simmetrica a chiave privata come AES ), oppure potresti firmare il cookie con un Codice di autenticazione della macchina .
Se non si memorizzano dati, solo un ID e si utilizza l'ID per ottenere dati dal database, ci sono tre suggerimenti che farei. Per prima cosa, rendi l'identificatore casuale, non sequenziale, in modo che nessuno possa indovinare gli ID degli altri semplicemente aggiungendo 1 al proprio ID. In secondo luogo, generare l'identificatore con entropia sufficiente (ad esempio, 64 bit) in modo che sia difficile trovare gli ID utilizzando una ricerca forza bruta. In terzo luogo, lega l'identificatore a un utente (ad esempio aggiungi una colonna UserID alla tabella del database) e verifica che corrisponda all'utente corrente autenticato prima di estrarre i dati.
Se sei preoccupato per la sicurezza fisica dell'endpoint-- ad es. un utente che gioca in un bar, che lascia il computer senza cancellare i cookie, quindi suggerisco che il cookie venga fornito con una scadenza o che sia cookie di sessione che viene eliminato quando l'utente chiude il browser. Riemetti il cookie quando l'utente si firma utilizzando il suo nome utente e la sua password.
Se sei preoccupato che un hacker possa utilizzare il cookie per inserire codice dannoso nella tua applicazione, usa il cookie solo per memorizzare un identificatore in un formato noto e convalidare il formato del cookie quando viene inviato al tuo server.