Controle de acesso e confidencialidade

Entender quais informações e ativos são visíveis para os clientes é fundamental para manter tanto a segurança quanto a confidencialidade do seu jogo. Os desenvolvedores costumam subestimar o quanto é visível para os exploradores e replicado para os clientes. Os exploradores têm a capacidade de acessar lugares "restritos" dentro do 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 dos universos

Uma vez dentro de um universo, os clientes podem se teletransportar para qualquer lugar dentro desse universo, potencialmente contornando quaisquer restrições de acesso ou portões de progressão pretendidos. Isso também pode levar ao vazamento não intencional de conteúdo não lançado, por exemplo, de um jogo de desenvolvimento ou de teste. É importante entender que:

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

Muitos desenvolvedores tentam impedir 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 se replique 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 via teleportação é definir Controle de Acesso para Lugares como Seguro dentro do universo apenas no Painel do Criador. Isso restringe todos os lugares não iniciais a teletransportes iniciados pelo servidor apenas, 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 se replica para ele.

Para etapas de configuração e orientações de migração para jogos existentes que usam teletransportes iniciados pelo cliente, consulte Teletransporte 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 — esta é a única maneira confiável de garantir a confidencialidade de conteúdo não lançado. Nunca envie ativos de eventos confidenciais, scripts ou elementos de UI para o ambiente de produção antes que estejam prontos para serem ativos.
• Se possível, use streaming para limitar quanto do mundo se replica para um novo jogador.
• Adicione verificação de função de grupo ou verificação de insígnias do lado do servidor e verifique o estado ou os requisitos de progressão do jogador.
• Por padrão, não permita a entrada de jogadores. Isso garante que nenhum jogador será permitido mesmo que o processo de verificação seja inconclusivo, como no caso de uma exceção lançada pelo mecanismo.
• Se prático, use a API Ban para jogadores que falham na validação. Isso impede que jogadores tentem continuamente entrar com a mesma conta.

Replicação

Replicação descreve como o estado é transferido pela rede entre instâncias do mecanismo. 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 se replicar entre todos os participantes (o servidor e todos os clientes conectados), ela deve ser criada no servidor.
• As propriedades da instância 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 para todos os clientes.
• De modo geral, uma instância ou se replica para todos os clientes conectados ou não se replica. Existem algumas exceções, como streaming.

Os contêineres de replicação são instâncias de nível superior (parentes do DataModel) que se replicam para os clientes. Se uma instância se tornar um descendente de um contêiner de replicação ao longo de sua vida, você deve esperar que grande parte de seu estado se replique 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 Play 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 replique 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 ele seja visto pelos usuários. Mesmo que haja lógica que restrinja a liberação ou o acesso ao conteúdo no jogo 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 ele 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 apenas do servidor armazenados em ServerStorage ou ServerScriptService não podem ser descompilados, pois nunca se replicam para os clientes.

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

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 de 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

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, como:

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