Out-of-Band Validation (OAST)

Como a WASViking confirma vulnerabilidades cegas com o seu próprio colaborador out-of-band e como revisar no portal as interações capturadas. Sem caminho de dados por terceiros.

Algumas das vulnerabilidades mais graves nunca aparecem na resposta. Um SSRF cego, um XXE cego ou uma injeção de comando cega roda no servidor e deixa a página com aparência normal. A única prova é que o alvo se conectou a algum lugar a que não deveria.

O WASViking^® Out-of-Band Validation (validação fora de banda) captura essa prova. Quando um payload faz o alvo chamar de volta um servidor que nós controlamos, o callback é registrado e vinculado exatamente ao scan, ao alvo e ao parâmetro que o causaram. Um achado que de outra forma seria um palpite vira um resultado confirmado, com evidência por trás.

Como funciona

Todo scan que executa uma verificação de classe cega emite um token único a partir do colaborador da WASViking^®. O token é embutido no payload, em uma URL HTTP ou em um hostname DNS, e a requisição sai pelo caminho normal do scan. Quando há um agente Sentinel em uso, a sonda trafega pelo mesmo túnel que o restante do scan, de modo que alvos internos são cobertos sem nenhuma configuração extra.

Se o alvo processa o payload, ele contata o colaborador. Essa interação é registrada com o seu protocolo, endereço de origem e timestamp, e depois associada de volta ao token. O analisador da classe de injeção lê o resultado e promove um achado confirmado para o mesmo fluxo de trabalho de Findings que qualquer outro resultado.

O colaborador é acessado em um endereço operado pela WASViking^® e escuta callbacks tanto HTTP quanto DNS. O token único trafega dentro do próprio callback, de modo que toda interação é vinculada exatamente ao scan, ao alvo e ao parâmetro que a produziram, e tem escopo restrito ao seu tenant.

Classes que ele confirma

Onde os seus dados ficam

Esta é a parte que importa para equipes reguladas. O colaborador é construído e operado pela WASViking^®, dentro da plataforma à qual você já confia os seus scans. Os dados de validação não passam por um serviço hospedado por terceiros, e os registros de interação têm escopo restrito ao seu tenant.

Para organizações sujeitas à LGPD, ao GDPR ou a regras setoriais como as do BACEN, esse caminho de dados único costuma ser a diferença entre um controle que você consegue aprovar e um que não consegue.

Revisando interações no portal

Os callbacks capturados são listados em Application Security → Out-of-Band (OAST). Cada linha é uma interação, com o contexto necessário para agir sobre ela:

Os cards no topo resumem o período de relance: total de interações, quantos tokens foram sondados, quantas classes de vulnerabilidade distintas foram vistas e a classe mais frequente. Um achado cego sempre aponta de volta para a interação que o comprova, de modo que um revisor consegue rastrear um resultado da lista de Findings até o callback bruto.

Privacidade e controle de ruído

O colaborador é deliberadamente silencioso. Ele só registra callbacks de tokens que ele mesmo emitiu, de modo que o ruído de fundo da internet que bate no endereço wildcard é descartado em vez de armazenado. Headers de requisição sensíveis, como authorization, cookies e chaves de API, são removidos antes de uma interação ser gravada, de modo que um registro de callback nunca vira um lugar por onde vazam os secrets de um alvo.

Configuração

Não há nada para configurar. O colaborador participa automaticamente sempre que um scan exercita uma classe com variante cega. Revise as interações capturadas em Application Security → Out-of-Band (OAST) e veja o checklist de ativação de módulos para o restante do seu plano.