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. Uma experiência segura é construída sobre uma mentalidade que antecipa ações adversariais. 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:

• Decompilar qualquer LocalScript replicado ou qualquer ModuleScript, mesmo que nunca sejam executados no cliente
• Tomar posse 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, física ou interações do jogador com o mundo
• Disparar ou invocar RemoteEvents e RemoteFunctions a qualquer frequência com argumentos arbitrários (exceto o primeiro argumento Player)
• Alterar 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 definitiva de verdade para todos os estados de simulação, regras, progressão 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 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 disser "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 até a 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 ao design de sua experiência desde o início, em vez de tentar adicioná-las mais tarde como um pensamento posterior.

• Modele ameaças para cada nova função. Para cada nova função, pergunte-se:

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