Control de acceso y confidencialidad

Entender qué información y activos son visibles para los clientes es fundamental para mantener tanto la seguridad como la confidencialidad de tu juego. Los desarrolladores a menudo subestiman cuánto es visible para los explotadores y se replica a los clientes. Los explotadores tienen la capacidad de acceder a lugares "restringidos" dentro de tu universo si pueden unirse a un solo lugar. Pueden ver cualquier contenido replicado a su cliente, independientemente de si es visible o está en uso. Además, los explotadores pueden descompilar cualquier script local y ModuleScripts replicados, incluso si nunca se ejecutan en el cliente.

Teleportación del lado del cliente dentro de los universos

Una vez dentro de un universo, los clientes pueden teletransportarse a cualquier lugar dentro de ese universo, potencialmente eludiendo cualquier restricción de acceso o puertas de progreso previstas. Esto también puede llevar a la filtración no intencionada de contenido no lanzado, por ejemplo, de un juego de desarrollo o de pruebas. Es importante entender que:

• Deshabilitar "Acceso Directo" solo elimina el botón Unirse de los sublugares en el sitio web; no impide los teletransportes iniciados por el cliente.
• Supón que los explotadores descubrirán la existencia de todos los sublugares dentro de tu universo.
• Un cliente puede teletransportarse a cualquier sublugar si puede acceder a un solo lugar, como el lugar raíz, independientemente de tu flujo de diseño previsto.

Muchos desarrolladores intentan prevenir el acceso expulsando a los usuarios no autorizados de un sublugar. Esto puede funcionar para bloquear la jugabilidad, pero no impide que el contenido se replique al cliente, ya que la replicación comienza tan pronto como el jugador se une y antes de que la lógica de expulsión del lado del servidor pueda ejecutarse.

Usa teletransportes seguros

La forma más efectiva de prevenir el acceso no autorizado a través de la teleportación es establecer Control de Acceso para Lugares en Seguro dentro del universo solamente en el Panel de Creadores. Esto restringe todos los lugares que no son de inicio a teletransportes iniciados por el servidor solamente, bloqueando los teletransportes iniciados por el cliente a nivel de plataforma antes de que el jugador se una al sublugar. Dado que el jugador nunca se une, no se replica ningún contenido a ellos.

Para pasos de configuración y orientación sobre la migración de juegos existentes que utilizan teletransportes iniciados por el cliente, consulta Teletransportar entre lugares.

Defensa en profundidad para lugares restringidos

Para universos que no pueden usar teletransportes seguros, o como capas adicionales de protección junto a ellos, combina las siguientes medidas:

• Mantén los lugares de desarrollo y prueba en universos separados y privados; esta es la única forma confiable de garantizar la confidencialidad del contenido no lanzado. Nunca envíes activos de eventos confidenciales, scripts o elementos de UI al entorno de producción antes de que estén destinados a estar activos.
• Si es posible, utiliza streaming para limitar cuánto del mundo se replica a un nuevo jugador.
• Agrega verificación de rol de grupo del lado del servidor o verificación de insignias y verifica el estado del jugador o los requisitos de progreso.
• Por defecto, no permitas la entrada de jugadores. Esto asegura que ningún jugador será permitido incluso si el proceso de verificación es inconcluso, como en el caso de una excepción lanzada desde el motor.
• Si es práctico, utiliza la API Ban para jugadores que no pasan la validación. Esto evita que los jugadores intenten unirse continuamente con la misma cuenta.

Replicación

La replicación describe cómo se transfieren los estados a través de la red entre instancias del motor. El modelo de replicación de Roblox se simplifica generalmente de algunas maneras clave:

• Las instancias son autoritarias del servidor, lo que significa que para que una instancia se replique entre todos los participantes (el servidor y todos los clientes conectados) debe ser creada en el servidor.
• Las propiedades de las instancias también son autoritarias del servidor, lo que significa que la mayoría de las propiedades deben cambiarse en el servidor para que los cambios sean visibles en todos los clientes.
• En términos generales, una instancia se replica a todos los clientes conectados o no lo hace. Hay algunas excepciones, como el streaming.

Los contenedores de replicación son instancias de nivel superior (parentadas bajo el DataModel) que se replican a los clientes. Si una instancia alguna vez se convierte en descendiente de un contenedor de replicación durante su vida útil, debes esperar que gran parte de su estado se replique a todos los clientes. Puedes leer más sobre los contenedores de replicación comunes en la guía del modelo de datos. Cuando tengas dudas, siempre puedes verificar cómo se replica una instancia o propiedad en un entorno de prueba como Jugar en Solo. Puedes leer más sobre los modos de prueba en Modos de prueba de Studio.

Implicaciones de seguridad de la replicación

Cualquier contenido que se replique a un cliente puede ser extraído y minado de datos por un explotador. Como regla general, evita publicar o enviar cualquier contenido confidencial al entorno de producción en vivo a menos que estés inmediatamente preparado para que sea visto por los usuarios. Incluso si hay lógica que limita la liberación o el acceso al contenido en el juego hasta una fecha posterior (o alguna otra condición), asume que los explotadores encontrarán una manera de descubrir y filtrar tu contenido tan pronto como se publique.

Evita nombres excesivamente descriptivos o predecibles para instancias sensibles, incluyendo pero no limitado a: scripts, remotos y modelos. Tener una jerarquía de DataModel predecible facilita el desarrollo de exploits.

Descompilación de scripts

Cualquier LocalScript, Script con RunContext::Client, o ModuleScript puede ser descompilado por un explotador una vez replicado a su cliente, incluso si tales scripts están deshabilitados, nunca son requeridos o nunca se ejecutan en el cliente. Los Scripts y ModuleScripts solo del servidor almacenados en ServerStorage o ServerScriptService no pueden ser descompilados ya que nunca se replican a los clientes.

Escribir un ModuleScript que incluya código solo del servidor y solo del cliente en el mismo script no es recomendable, ya que la lógica del lado del servidor se expondrá en la descompilación y puede ser más fácilmente disecada para encontrar errores que pueden ser explotados.

local module = {}

local Remote = script:WaitForChild("RemoteEvent")

-- Aquí hay un ejemplo de un paradigma a evitar
-- Mantén el código del servidor en instancias de Script o en ServerStorage/ServerScriptStorage!

if game:GetService("RunService"):IsServer() then
  function module:DoServerThing(password)
    if password == "SecretPassword" then
      print("código sensible del servidor")
    end
  end

  Remote.OnServerEvent:Connect(function(player, password)
    module:DoServerThing(password)
  end)
else
  function module:DoServerThing(password)
    Remote:FireServer(password)
  end
end

return module

local table1 = {};
local RemoteEvent = script:WaitForChild("RemoteEvent");
if game:GetService("RunService"):IsServer() then
  function table1.DoServerThing(_, p2) -- Línea: 9
    if p2 == "SecretPassword" then
      print("código sensible del servidor");
    end
  end
  RemoteEvent.OnServerEvent:Connect(function(player: Player, p3) -- Línea: 15
    --[[
      Upvalues:
        [1] = table1
    --]]
    table1:DoServerThing(p3);
  end);
  return table1;
end
function table1.DoServerThing(_, p1) -- Línea: 19
  --[[
    Upvalues:
      [1] = RemoteEvent
  --]]
  RemoteEvent:FireServer(p1);
end
return table1;

Como se muestra arriba, la descompilación revela la lógica del lado del servidor, incluyendo contraseñas codificadas, reglas de negocio y detalles de implementación que los explotadores pueden analizar en busca de vulnerabilidades.

Impacto de las violaciones de confidencialidad

Las violaciones de confidencialidad pueden tener consecuencias significativas, tales como:

• Filtraciones de contenido: Artículos, mapas o características no lanzadas pueden ser descubiertos y compartidos públicamente antes de los anuncios oficiales.
• Desventaja competitiva: Mecánicas, algoritmos o características próximas pueden ser descompuestos por competidores.
• Desarrollo de exploits: La lógica del servidor expuesta facilita y acelera a los explotadores identificar vulnerabilidades y desarrollar ataques dirigidos.