Control de acceso y confidencialidad

Entender qué información y activos son visibles para los clientes es fundamental para mantener la seguridad y la confidencialidad de tu experiencia. 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 actualmente 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 una experiencia de desarrollo o staging. Es importante entender que:

• Deshabilitar "Acceso directo" solo elimina el botón de 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 echando a los usuarios no autorizados de un sublugar. Esto puede funcionar para bloquear la jugabilidad, pero no evita 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 Solo seguro dentro del universo 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. Debido a que el jugador nunca se une, ningún contenido se replica a él.

Para pasos de configuración y orientación de migración para experiencias existentes que usan 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 lugares de desarrollo y prueba en universos privados y separados — esta es la única forma confiable de asegurar la confidencialidad del contenido no lanzado. Nunca envíes activos de evento confidenciales, scripts o elementos de UI al entorno de producción antes de que estén destinados a estar activos.
• Si es posible, usa streaming para limitar cuánto del mundo se replica a un nuevo jugador.
• Agrega verificación de roles de grupo del lado del servidor o de insignias y verifica el estado o los requisitos de progreso del jugador.
• Por defecto, no permitas jugadores entrantes. Esto asegura que ningún jugador será permitido aunque el proceso de verificación sea inconcluso, como en el caso de una excepción lanzada desde el motor.
• Si es práctico, usa la Ban API para jugadores que fallen en la validación. Esto previene que los jugadores intenten unirse continuamente con la misma cuenta.

Replicación

La replicación describe cómo el estado se transfiere 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 para todos los clientes.
• En términos generales, una instancia se replica a todos los clientes conectados o no se replica. Hay algunas excepciones, como el streaming.

Los contenedores de replicación son instancias de nivel superior (padres bajo el DataModel) que se replican a los clientes. Si una instancia llega a ser descendiente de un contenedor de replicación durante su vida, 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 comprobar cómo una instancia o propiedad se replica en un entorno de prueba como Play 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 restringe la liberación o el acceso del contenido dentro de la experiencia hasta una fecha posterior (o alguna otra condición), supón que los explotadores encontrarán una manera de descubrir y filtrar tu contenido tan pronto como sea publicado.

Evita nombres demasiado descriptivos o predecibles para instancias sensibles, incluidos pero no limitados a: scripts, remotos y modelos. Tener una jerarquía del 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 dichos scripts están desactivados, 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 para el servidor y solo para el cliente en el mismo script no es recomendable, ya que la lógica del lado del servidor será expuesta en la descompilación y puede ser disecada más fácilmente para buscar errores que pueden ser explotados.

ModuleScript original en ReplicatedStorage
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 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

Resultado de la descompilación
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 lógica del lado del servidor, incluidos contraseñas codificadas, reglas comerciales y detalles de implementación que los explotadores pueden analizar para identificar vulnerabilidades.

Impacto de las brechas de confidencialidad

Las brechas 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 anuncios oficiales.
• Desventaja competitiva: Mecánicas, algoritmos o características próximas pueden ser desensambladas por competidores.
• Desarrollo de exploits: La lógica del servidor expuesta facilita y agiliza que los explotadores identifiquen vulnerabilidades y desarrollen ataques específicos.