Controle de acesso e confidencialidade

Entender quais informações e ativos são visíveis para os clientes é fundamental para manter a segurança e a confidencialidade de sua experiência. Os desenvolvedores frequentemente subestimam quanto é visível para os exploradores e replicado para os clientes. Os exploradores têm a capacidade de acessar lugares "restritos" dentro de seu universo se conseguirem entrar em um único lugar. Eles podem visualizar qualquer conteúdo replicado para seu cliente, independentemente de estar visível ou em uso no momento. Além disso, os exploradores podem descompilar quaisquer scripts locais e ModuleScripts replicados, mesmo que nunca sejam executados no cliente.

Teleportação do lado do cliente dentro de universos

Uma vez dentro de um universo, os clientes podem se teletransportar para qualquer lugar dentro desse universo, podendo contornar quaisquer restrições de acesso ou portas de progresso pretendidas. Isso também pode levar ao vazamento não intencional de conteúdo não liberado, por exemplo, de uma experiência de desenvolvimento ou de teste. É importante entender que:

• Desativar o "Acesso Direto" apenas remove o botão de Entrada de sublugares no site — isso não impede teletransportes iniciados pelo cliente
• Presuma que os exploradores descobrirão a existência de todos os sublugares dentro de seu universo
• Um cliente pode se teletransportar para qualquer sublugar se puder acessar um único lugar, como o lugar raiz, independentemente do fluxo de design pretendido

Muitos desenvolvedores tentam prevenir o acesso expulsando usuários não autorizados de um sublugar. Isso pode funcionar para bloquear a jogabilidade, mas não impede que o conteúdo seja replicado para o cliente, uma vez que a replicação começa assim que o jogador entra e antes que a lógica de expulsão do lado do servidor possa ser executada.

Use teletransportes seguros

A maneira mais eficaz de prevenir acesso não autorizado por meio de teleportação é definir o Controle de Acesso para Lugares como Seguro dentro do universo apenas no Painel do Criador. Isso restringe todos os lugares não iniciais a apenas teletransportes iniciados pelo servidor, bloqueando teletransportes iniciados pelo cliente no nível da plataforma antes que o jogador entre no sublugar. Como o jogador nunca entra, nenhum conteúdo é replicado para ele.

Para etapas de configuração e orientações de migração para experiências existentes que usam teletransportes iniciados pelo cliente, veja Teletransportar entre lugares.

Defesa em profundidade para lugares restritos

Para universos que não podem usar teletransportes seguros, ou como camadas adicionais de proteção ao lado deles, combine as seguintes medidas:

• Mantenha lugares de desenvolvimento e teste em universos separados e privados — essa é a única maneira confiável de garantir a confidencialidade de conteúdo não liberado. Nunca envie ativos de evento, scripts ou elementos de UI confidenciais para o ambiente de produção antes de estarem prontos para serem ativos.
• Se possível, use streaming para limitar quanto do mundo é replicado para um novo jogador.
• Adicione verificação de função de grupo ou crachá do lado do servidor e verifique o estado ou requisitos de progresso do jogador.
• Por padrão, não permita a entrada de jogadores. Isso garante que nenhum jogador será autorizado a entrar mesmo que o processo de verificação seja inconclusivo, como no caso de uma exceção gerada pelo motor.
• Se prático, use a Ban API para jogadores que falham na validação. Isso impede que jogadores tentem entrar repetidamente na mesma conta.

Replicação

A replicação descreve como o estado é transferido pela rede entre instâncias do motor. O modelo de replicação do Roblox é geralmente simplificado de algumas maneiras principais:

• As instâncias são autoritárias do servidor, o que significa que, para uma instância replicar entre todos os participantes (o servidor e todos os clientes conectados), ela deve ser criada no servidor.
• As propriedades das instâncias também são autoritárias do servidor, o que significa que a maioria das propriedades deve ser alterada no servidor para que as alterações sejam visíveis em todos os clientes.
• Falando de maneira geral, uma instância ou replica para todos os clientes conectados ou não. Existem algumas exceções, como streaming.

Os contêineres de replicação são instâncias de nível superior (parentes do DataModel) que replicam para os clientes. Se uma instância se tornar um descendente de um contêiner de replicação durante sua vida útil, você deve esperar que grande parte de seu estado seja replicada para todos os clientes. Você pode ler mais sobre contêineres de replicação comuns no Guia do modelo de dados. Quando em dúvida, você pode sempre verificar como uma instância ou propriedade se replica em um ambiente de teste, como o Jogo Solo. Você pode ler mais sobre modos de teste em Modos de teste do Studio.

Implicações de segurança da replicação

Qualquer conteúdo que se replica para um cliente pode ser extraído e minerado por um explorador. Como regra geral, evite publicar ou enviar qualquer conteúdo confidencial para o ambiente de produção ao vivo, a menos que você esteja imediatamente preparado para que seja visto pelos usuários. Mesmo que haja lógica que bloqueie a liberação ou o acesso ao conteúdo na experiência até uma data posterior (ou alguma outra condição), presuma que os exploradores encontrarão uma maneira de descobrir e vazar seu conteúdo assim que for publicado.

Evite nomes excessivamente descritivos ou previsíveis para instâncias sensíveis, incluindo, mas não se limitando a: scripts, remotes e modelos. Ter uma hierarquia de DataModel previsível facilita o desenvolvimento de exploits.

Descompilação de scripts

Qualquer LocalScript, Script com RunContext::Client, ou ModuleScript pode ser descompilado por um explorador uma vez replicado para seu cliente, mesmo que tais scripts estejam desativados, nunca sejam exigidos ou nunca sejam executados no cliente. Scripts e ModuleScripts somente do servidor armazenados em ServerStorage ou ServerScriptService não podem ser descompilados, pois nunca se replicam para os clientes.

Escrever um ModuleScript que inclui código somente do servidor e somente do cliente no mesmo script não é aconselhável, pois a lógica do lado do servidor será exposta na descompilação e pode ser mais facilmente analisada em busca de bugs que podem ser explorados.

ModuleScript Original em ReplicatedStorage
local module = {}

local Remote = script:WaitForChild("RemoteEvent")

-- Aqui está um exemplo de um paradigma a evitar
-- Mantenha o código do servidor em instâncias Script ou em ServerStorage/ServerScriptStorage!

if game:GetService("RunService"):IsServer() then
  function module:DoServerThing(password)
    if password == "SecretPassword" then
      print("código sensível do 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 da descompilação
local table1 = {};
local RemoteEvent = script:WaitForChild("RemoteEvent");
if game:GetService("RunService"):IsServer() then
  function table1.DoServerThing(_, p2) -- Linha: 9
    if p2 == "SecretPassword" then
      print("código sensível do servidor");
    end
  end
  RemoteEvent.OnServerEvent:Connect(function(player: Player, p3) -- Linha: 15
    --[[
      Upvalues:
        [1] = table1
    --]]
    table1:DoServerThing(p3);
  end);
  return table1;
end
function table1.DoServerThing(_, p1) -- Linha: 19
  --[[
    Upvalues:
      [1] = RemoteEvent
  --]]
  RemoteEvent:FireServer(p1);
end
return table1;

Como mostrado acima, a descompilação revela a lógica do lado do servidor, incluindo senhas codificadas, regras de negócios e detalhes de implementação que os exploradores podem analisar em busca de vulnerabilidades.

Impacto das violações de confidencialidade

As violações de confidencialidade podem ter consequências significativas, tais como:

• Vazamentos de conteúdo: Itens, mapas ou recursos não liberados podem ser descobertos e compartilhados publicamente antes de anúncios oficiais.
• Desvantagem competitiva: Mecânicas, algoritmos ou recursos futuros podem ser revertidos por concorrentes.
• Desenvolvimento de exploits: A lógica do servidor exposta torna mais rápida e fácil para os exploradores identificarem vulnerabilidades e desenvolverem ataques direcionados.