El siguiente contenido cubre varios conceptos y tácticas para mejorar la seguridad y mitigar el engaño en tus experiencias de Roblox. Se recomienda encarecidamente que todos los desarrolladores lean esto para asegurar que sus experiencias sean seguras y justas para todos los usuarios. Consulta la barra lateral para obtener 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. Una experiencia segura se basa en una mentalidad que anticipa acciones adversarias. Antes de escribir una sola línea de código, debes internalizar estos principios fundamentales. Deberían informar cada decisión arquitectónica y de diseño que tomes.
Nunca confíes en el cliente
Este es el principio fundamental. Un exploitador determinado tiene control total sobre su estado local y tráfico de red. Debido a que los exploitadores tienen este nivel de control, cualquier medida de seguridad que dependa de la aplicación del lado del cliente será eventualmente eludida. Esta no es una limitación de Roblox: es una realidad fundamental de las arquitecturas cliente-servidor. Supón que cada pieza de datos enviada desde el cliente ha sido manipulada, falsificada o enviada con intenciones maliciosas. Esto incluye el poder de:
- Descompilar cualquier LocalScript replicado o cualquier ModuleScript, incluso si nunca se ejecutan en el cliente
- Tomar 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 de su jugador, la física o las interacciones con el mundo
- Disparar o invocar RemoteEvents y RemoteFunctions a cualquier frecuencia con argumentos arbitrarios (además del primero, que es el argumento Player)
- Cambiar cualquier cosa en su DataModel local sin activar 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 Network Ownership, Movement Validation, and Physics Exploits y Access Control and Confidentiality.
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 rol del cliente es renderizar el mundo y enviar la entrada del usuario al servidor.
El rol del servidor es:
- Recibir la entrada del cliente
- Validar que la acción solicitada es posible y permitida
- 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 un 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. En la medida de lo 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 debería restar el precio del Bloxy Cola del dinero del jugador; sin embargo, el servidor no puede controlar necesariamente el personaje del jugador en todo momento.
Seguridad por diseño
Integra las consideraciones de seguridad en el diseño de tu experiencia desde el principio, en lugar de intentar agregarlas más tarde como un pensamiento posterior.
- Modela las amenazas de cada nueva característica. Para cada nueva característica, pregúntate
- ¿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é pasaría si esta característica se usa 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 utilizar esta característica de manera factible?
- ¿Cuál es la información o estado interno mínimo que necesito exponer para esta característica?
- Separa responsabilidades temprano. 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.