Táticas de segurança e mitigação de trapaças

Antes de mergulhar em táticas específicas para desenvolver de forma segura e prevenir trapaças, é essencial entender os princípios fundamentais da segurança no Roblox. Um jogo seguro é construído com uma mentalidade que antecipa ações adversárias. Antes de escrever uma única linha de código, você deve internalizar esses princípios fundamentais. Eles devem informar cada decisão arquitetônica e de design que você tomar.

Nunca confie no cliente

Este é o princípio fundamental. Um explorador determinado tem controle total sobre seu estado local e tráfego de rede. Como os exploradores têm esse nível de controle, qualquer medida de segurança que dependa da aplicação no lado do cliente será eventualmente contornada. Isso não é uma limitação do Roblox: é uma realidade fundamental das arquiteturas cliente-servidor. Assuma que cada pedaço de dado enviado do cliente foi manipulado, fabricado ou enviado com intenção maliciosa. Isso inclui o poder de:

• Descompilar qualquer LocalScript replicado ou qualquer ModuleScript, mesmo que nunca sejam executados no cliente
• Assumir a propriedade da rede de seu personagem e de quaisquer partes não ancoradas
• Acionar eventos iniciados pelo cliente, como eventos Touched ou ativações de ProximityPrompt a qualquer distância ou frequência
• Modificar a posição do jogador, física ou interações com o mundo
• Disparar ou invocar RemoteEvents e RemoteFunctions a qualquer frequência com argumentos arbitrários (exceto o primeiro argumento Player)
• Mudar qualquer coisa em seu DataModel local sem disparar quaisquer eventos esperados
• Alterar arbitrariamente o comportamento de qualquer código em execução localmente

Por causa disso, toda lógica crítica deve ser validada no lado do servidor ou executada exclusivamente no servidor. As consequências desse controle estão detalhadas em Propriedade de Rede, Validação de Movimento e Exploits de Física e Controle de Acesso e Confidencialidade.

Autoridade do servidor

O servidor deve ser a fonte final de verdade para todos os estados de simulação, regras, progresso do jogador e decisões críticas. O papel do cliente é renderizar o mundo e enviar a entrada do usuário para o servidor.

O papel do servidor é:

• Receber a entrada do cliente
• Validar se a ação solicitada é possível e permitida
• Executar a ação e atualizar seu estado autoritativo
• Replicar os resultados para todos os clientes relevantes

Por exemplo, se um jogador diz "Eu quero comprar uma Bloxy Cola", o servidor deve saber o verdadeiro preço do item, o dinheiro do jogador e a distância física do personagem do jogador em relação à loja antes de validar e aprovar a transação. Tanto quanto possível, o estado a ser validado deve ser mantido exclusivamente pelo servidor e não pelos clientes. No exemplo, se a transação da Bloxy Cola for aprovada, o servidor deve subtrair o preço da Bloxy Cola do dinheiro do jogador, no entanto, o servidor não pode necessariamente controlar sempre o personagem do jogador.

Segurança por design

Integre considerações de segurança no design do seu jogo desde o início, em vez de tentar adicioná-las mais tarde como um pensamento posterior.

• Modele ameaças para cada novo recurso. Para cada novo recurso, pergunte-se:

  • Como um atacante poderia explorar isso se tivesse controle total de seu cliente?
  • Se um cliente pudesse enviar qualquer valor para quaisquer parâmetros usados no recurso, qual seria o pior resultado possível?
  • O que acontece se esse recurso for usado mais de 1.000 vezes por segundo? Qual é a taxa máxima na qual ele deve ser usado?
  • Um explorador poderia usar isso para arruinar a experiência de outro jogador?
  • Quais recursos, no pior caso, esse recurso poderia usar de forma viável?
  • Qual é a mínima informação interna ou estado que eu preciso expor para esse recurso?
• Particione responsabilidades desde o início. Mantenha a lógica e os dados no ServerScriptService desde o primeiro dia. Nunca os coloque em contêineres replicados como ReplicatedStorage ou Workspace.