El siguiente contenido cubre varios conceptos y tácticas para mejorar la seguridad y mitigar el engaño en tus juegos de Roblox. Se recomienda encarecidamente que todos los desarrolladores lean esto para garantizar que sus juegos sean seguros y justos para todos los usuarios. Consulta la barra lateral para temas de seguridad adicionales.
Antes de profundizar en tácticas específicas para desarrollar de manera segura y prevenir trampas, es esencial comprender los principios fundamentales de la seguridad en Roblox. Un juego seguro se basa en una mentalidad que anticipa acciones adversariales. Antes de escribir una sola línea de código, debes internalizar estos principios fundamentales. Deben informar cada decisión arquitectónica y de diseño que tomes.
Nunca confíes en el cliente
Este es el principio fundamental. Un explotador decidido tiene control total sobre su estado local y el tráfico de red. Debido a que los explotadores tienen este nivel de control, cualquier medida de seguridad que dependa de la aplicación del lado del cliente eventualmente será eludida. Esta no es una limitación de Roblox: es una realidad fundamental de las arquitecturas cliente-servidor. Asume que cada pieza de datos enviada desde el cliente ha sido manipulada, fabricada o enviada con intención maliciosa. Esto incluye el poder de:
- Descompilar cualquier LocalScript replicado o cualquier ModuleScript, incluso si nunca se ejecutan en el cliente
- Tomar la propiedad de red de su personaje y de cualquier parte no anclada
- Activar eventos iniciados por el cliente, como eventos Touched o activaciones de ProximityPrompt a cualquier rango o frecuencia
- Modificar la posición, física o interacciones de su jugador con el mundo
- Disparar o invocar RemoteEvents y RemoteFunctions a cualquier frecuencia con argumentos arbitrarios (además del primer argumento Player)
- Cambiar cualquier cosa en su DataModel local sin disparar ningún evento esperado
- Alterar arbitrariamente el comportamiento de cualquier código que se esté ejecutando localmente
Debido a esto, toda la lógica crítica debe ser validada del lado del servidor o ejecutarse exclusivamente en el servidor. Las consecuencias de este control se detallan en Propiedad de red, validación de movimiento y exploits físicos y Control de acceso y confidencialidad.
Autoridad del servidor
El servidor debe ser la fuente última de verdad para todos los estados de simulación, reglas, progresión de jugadores y decisiones críticas. El papel del cliente es renderizar el mundo y enviar la entrada del usuario al servidor.
El papel del servidor es:
- Recibir la entrada del cliente
- Validar que la acción solicitada sea posible y permisible
- Ejecutar la acción y actualizar su estado autoritativo
- Replicar los resultados a todos los clientes relevantes
Por ejemplo, si un jugador dice "Quiero comprar una Bloxy Cola", el servidor debe conocer el verdadero precio del artículo, el dinero del jugador y la distancia física del personaje del jugador desde la tienda antes de validar y aprobar la transacción. Tanto como sea posible, el estado a validar debe ser mantenido exclusivamente por el servidor y no por los clientes. En el ejemplo, si la transacción de Bloxy Cola es aprobada, el servidor debe restar el precio de la Bloxy Cola del dinero del jugador; sin embargo, el servidor no puede necesariamente controlar siempre el personaje del jugador.
Seguridad por diseño
Integra consideraciones de seguridad en el diseño de tu juego desde el principio, en lugar de intentar añadirlas más tarde como un pensamiento posterior.
- Modela amenazas cada nueva característica. Para cada nueva característica, pregunta:
- ¿Cómo podría un atacante explotar esto si tiene control total de su cliente?
- Si un cliente pudiera enviar cualquier valor para cualquier parámetro utilizado en la característica, ¿cuál sería el peor resultado posible?
- ¿Qué pasa si esta característica se utiliza más de 1,000 veces por segundo? ¿Cuál es la tasa máxima a la que debería usarse?
- ¿Podría un explotador usar esto para arruinar la experiencia de otro jugador?
- ¿Cuántos recursos, en el peor de los casos, podría usar esta característica de manera factible?
- ¿Cuál es la información o estado interno mínimo que necesito exponer para esta característica?
- Divide responsabilidades desde el principio. Mantén la lógica y los datos en ServerScriptService desde el primer día. Nunca los coloques en contenedores replicados como ReplicatedStorage o Workspace.