Saltar para o conteúdo principal
Glossário de segurança

Black-box vs grey-box vs white-box

Estes três termos descrevem quanto o testador sabe sobre o alvo antes de começar e, por isso, até onde pode realisticamente chegar no tempo disponível. São graus de conhecimento, não uma classificação de qualidade.

Black-box: a perspetiva de quem está de fora

Num teste black-box, o testador começa com pouco ou nenhum conhecimento interno, muitas vezes apenas um domínio ou uma gama de IP, e trabalha como um atacante externo. É realista para simular um agente externo oportunista. Mas o tempo, que é fixo, vai para uma descoberta a que um atacante real poderia dedicar meses, pelo que falhas reais, mas mais profundas, podem ficar por encontrar simplesmente por falta de tempo.

Grey-box: a norma com melhor relação custo-benefício

O grey-box dá ao testador conhecimento parcial, tipicamente contas válidas com várias funções e uma especificação de API, como OpenAPI/Swagger. É a opção pragmática por omissão para a maioria dos trabalhos de aplicação e de API, porque o orçamento vai para encontrar falhas reais e não para o reconhecimento. As falhas de autorização, como BOLA/IDOR, só podem ser encontradas com várias contas: com um único token, ou sem nenhum, não há forma de as pôr à prova.

White-box: garantia máxima

Os testes white-box (ou crystal-box) dão informação total: código-fonte, arquitetura, configuração e acesso às pessoas envolvidas. Permitem a cobertura mais profunda e são a escolha certa quando precisa de garantia elevada ou está a verificar face aos níveis mais altos de um padrão. O OWASP ASVS 5.0 nota que os seus níveis mais rigorosos podem exigir exatamente este tipo de acesso à documentação, ao código-fonte e à configuração.

Qual deve escolher?

Escolha pelo objetivo de garantia, e não pela opção que soa mais difícil. O black-box é adequado a uma simulação realista de um atacante externo, o grey-box é a opção eficiente por omissão para avaliações de web e de API, e o white-box destina-se a revisões de garantia elevada e à verificação face a padrões. Uma ideia que já não se aplica: o ASVS 5.0 reformulou o Nível 1, pelo que o velho atalho de que «o ASVS L1 equivale a um pentest black-box» deixou de ser válido. O nível de verificação é agora uma decisão baseada no risco.

Perguntas frequentes

Descrevem quanto o testador sabe sobre o alvo antes de começar, e não uma classificação de qualidade. A caixa preta começa com pouco ou nenhum conhecimento interno; a caixa cinzenta dá conhecimento parcial, como contas válidas e uma especificação; a caixa branca dá acesso completo ao código-fonte, à arquitetura e à configuração.

O grey-box é a opção pragmática por omissão para a maior parte do trabalho com aplicações e APIs, porque o orçamento é gasto a encontrar falhas reais em vez de em reconhecimento. É especialmente importante para falhas de autorização como BOLA/IDOR, que só se encontram com várias contas em diferentes funções. Um único token, ou nenhum, não permite pô-las à prova.

Não. O OWASP ASVS 5.0 reformulou o Nível 1, pelo que a velha equivalência «ASVS L1 = pentest black-box» deixou de ser válida. O nível de verificação é agora uma decisão baseada no risco, e os níveis ASVS mais elevados e rigorosos podem exigir acesso ao código-fonte e à configuração, como num teste white-box.

Fale com um profissional a sério.

Tem uma pergunta que estas páginas não responderam? Diga-nos o que está a tentar proteger e indicamos-lhe o projeto adequado. A primeira consulta é gratuita.