Posse do alvo por DNS
Antes de qualquer simulação não-sandbox rodar, DoesItDefend exige prova técnica de que quem chamou controla o hostname do alvo. A prova é um desafio DNS TXT em `_doesitdefend.<hostname>` contendo um token de verificação por organização. Esta é a camada CFAA / Marco Civil da Internet / Computer Misuse Act: sem ela, um atacante com uma API key válida poderia weaponizar a plataforma contra alvos arbitrários.
Antes de qualquer simulação fora do sandbox, a plataforma exige prova técnica de que você controla o hostname do alvo: um registro DNS TXT em _doesitdefend.<hostname> contendo um token de verificação por organização. A posse é provada antes da primeira requisição.
Essa é a camada de autorização que mantém o teste ofensivo consensual — a mesma classe de controle que o CFAA e o Marco Civil esperam de pesquisa autorizada.
Pontos-chave
- Tokens são escopados por (organização, hostname) e rotacionam a cada 7 dias para verificações pendentes, 365 dias para verificadas.
- Verificação é técnica, não declarativa: resolvemos o registro TXT ao vivo; declaração sem registro correspondente nunca concede acesso.
- Alvos sandbox (Juice Shop, VulnBot) bypassam o desafio: é infraestrutura nossa para demo e nunca encosta em endpoints de cliente.
- Registros verificados auto-revogam em falha de resolução DNS durante re-checks semanais em background (a Cloud Run Job target-ownership-sweeper).
Setup (uma vez por hostname)
- Em /settings/targets, adicione o hostname. A UI mostra o registro TXT a adicionar (host = _doesitdefend.<hostname>, valor = did-verify=<token de 48 chars>).
- Adicione o registro no seu provedor DNS. Propagação geralmente completa em minutos.
- Clique Verificar. A plataforma resolve o registro TXT e flipa a linha de pendente para verificado.
A configuração acontece uma vez por hostname em /settings/targets: a UI mostra o registro exato, você o adiciona no seu provedor de DNS, e a verificação resolve o TXT e muda a linha para verificada. A propagação costuma levar minutos.
Garantias operacionais
- REQUIRE_TARGET_OWNERSHIP=true em prod / staging: POST /v1/runs retorna 403 target_ownership_required para qualquer host não-sandbox não verificado.
- Entrada no audit log a cada evento verify_requested / verified / verify_failed / revoked, linkada ao ator (user_id ou system).
- Fluxo de revogação em /settings/targets: útil quando o cliente transfere o domínio ou rotaciona DNS.
A aplicação é no servidor, não consultiva: com REQUIRE_TARGET_OWNERSHIP habilitado em produção e staging, a criação de execução contra um host não verificado falha com 403 target_ownership. Cada evento de verificação e revogação vai para o log de auditoria, e a revogação fica disponível quando o domínio muda de mãos.
Recursos relacionados