InfoSec siempre es un equilibrio entre riesgo, costo y conveniencia. En su caso, estamos hablando de un juego que quizás no sea muy conocido, por lo que no es un objetivo de alto valor. Si no hay nada que merezca la pena piratear, no hay nada que merezca la pena proteger.
Además, InfoSec tiende a centrarse en modelado de amenazas específico vectores de ataque . Es posible que no tenga que hacer nada si no hay ataques que le causen dolor, por ejemplo. Si los únicos ataques que podrían funcionar son los que no afectan nada importante para sus operaciones. Así que deberías intentar enumerarlos. ¿Qué tipo de cosas le preocupa que un hacker pueda lograr? Por ejemplo, ¿es un gran problema si alguien puede modificar sus propios puntajes e informes? ¿Es un gran problema si pudieran ver los puntajes de otra persona? ¿Si pudieran modificarlos? Etc.
Dicho esto, puedo presentarte un par de prácticas generales que ciertamente no dañarán nada si las hicieras:
Si realmente está almacenando datos en las cookies (a diferencia de un identificador que se puede usar para obtener datos), cualquier usuario que controle la máquina en la que se almacena la cookie puede modificar las cookies. Por supuesto, solo pueden modificar sus propias cookies. Pero si esto sigue siendo una preocupación, puede hacer que sus cookies sean un poco resistentes a la manipulación a través de diversos medios: podría cifrar la cookie (probablemente utilizando un cifrado simétrico de clave privada como AES ), o puede firmar la cookie con un Código de autenticación de máquina .
Si no está almacenando datos, solo una ID, y usa la ID para obtener datos de la base de datos, hay tres sugerencias que haría. Primero, haga que el identificador sea aleatorio, no secuencial, de modo que nadie pueda adivinar las ID de otros simplemente agregando 1 a su propia ID. En segundo lugar, genere el identificador con suficiente entropía (por ejemplo, 64 bits) para que sea difícil encontrar ID utilizando una búsqueda de fuerza bruta. Tercero, vincule el identificador a un usuario (por ejemplo, agregue una columna UserID a la tabla de la base de datos) y verifique que coincida con el usuario autenticado actual antes de extraer cualquier información.
Si le preocupa la seguridad física del punto final, por ejemplo, un usuario que juega su juego en una cafetería, que deja la computadora sin borrar sus cookies, entonces le sugiero que le dé una caducidad a su cookie o que sea una cookie de sesión que se elimina cuando el usuario cierra el navegador. Vuelva a emitir la cookie cuando el usuario inicie sesión con su nombre de usuario y contraseña.
Si le preocupa que un pirata informático pueda usar la cookie para inyectar un código malicioso en su aplicación, utilice la cookie solo para almacenar un identificador en un formato conocido y valide el formato de la cookie cuando se envíe a su servidor.