Noções básicas de testes de caixa branca: identificando riscos de segurança no início do SDLC

Quando o assunto é segurança de software, 85% dos usuários acreditam que a responsabilidade é de quem está mais perto do código: desenvolvedores e engenheiros. Isso não surpreende, já que a maioria das vulnerabilidades surge no início do ciclo de vida de desenvolvimento de software, antes mesmo de o software chegar à produção. Para quem não conhece por dentro os sistemas ou softwares testados, muitas dessas vulnerabilidades também podem ser muito difíceis de encontrar.

É aí que entram os testes de caixa branca. Neste artigo, vamos explorar esse método de teste de segurança de aplicações, como realizá-lo e suas vantagens e desvantagens.

Entenda os testes de caixa branca

Diagrama de teste de caixa-branca

A principal característica dos testes de caixa branca é permitir enxergar o que acontece dentro do software. Por isso, eles também são conhecidos como testes de caixa de vidro, caixa transparente ou caixa aberta. Como o testador ou a ferramenta conhece a estrutura interna do software e sabe o que o código deve fazer, é possível avaliar sua segurança examinando sua resistência a ataques.

Os testes de caixa branca são o oposto dos testes de caixa-preta. Nesse tipo de teste, como o nome sugere, o testador de segurança não tem acesso ao software ou às redes e, portanto, sabe pouco ou nada sobre o alvo. O profissional de pentest testa a aplicação para descobrir vulnerabilidades da mesma forma que um invasor externo faria.

O objetivo dos testes de caixa branca

Por que testar software com testes de caixa branca? Por que esse tipo de teste é importante? A resposta tem dois aspectos:

1. Eles revelam riscos de segurança.

De acordo com o relatório sobre o estado da segurança de aplicações nativas da nuvem, mais de 56% dos usuários enfrentaram um incidente envolvendo uma configuração incorreta ou uma vulnerabilidade conhecida sem correção em suas aplicações nativas da nuvem. A segurança de aplicações é fundamental, e negligenciá-la pode levar a consequências desastrosas. Conhecer as falhas de segurança em tempo hábil ajuda a eliminar riscos e evitar o alto custo de violações de segurança, que podem abalar a confiança dos clientes na sua capacidade de proteger os dados deles (e até levar a processos judiciais).

Muitas vulnerabilidades de segurança — como desserialização insegura, configuração incorreta, exposição de segredos e falhas no controle de acesso — resultam de erros de programação no código. Sem testes de caixa branca, é difícil corrigir os riscos que essas vulnerabilidades representam.

2. Eles revelam bugs e melhoram a qualidade.

As equipes de software trabalham de forma ágil e lançam atualizações com frequência, com base no feedback dos usuários e nas mudanças do mercado. As atualizações e alterações regulares não devem comprometer os recursos existentes. Poucas coisas irritam mais os usuários do que uma atualização que prejudica funcionalidades já populares. Os testes de caixa branca são fundamentais para detectar bugs e alterações que quebram funcionalidades em tempo hábil.

Em resumo, os testes de caixa branca são essenciais para detectar bugs, possíveis brechas de segurança e problemas de desempenho desde o início.

Tipos de testes de caixa branca

Há vários tipos de testes de caixa branca:

• Teste de execução/unitário: esse tipo de teste de caixa branca é realizado executando uma parte do código e comparando o resultado com o esperado. Se o resultado esperado não for obtido, há um defeito que precisa ser corrigido. Os testes de execução são feitos continuamente.

• Teste estático/análise estrutural: envolve uma análise cuidadosa da base de código para encontrar bugs e vulnerabilidades sem executar o código. Por exemplo, um testador pode analisar a base de código com ferramentas de segurança de aplicações estáticas (SAST) para identificar vulnerabilidades. Com SAST, a aplicação é analisada detalhadamente com base em verificações específicas, como análise de configuração, análise semântica e análise de fluxo de dados, entre outras, para manter o código-fonte seguro.

• Teste de mutação: normalmente realizado na etapa final, envolve uma verificação geral de bugs e uma análise para determinar as melhores estratégias de codificação para expandir o programa.

O que é testado?

Para realizar testes de caixa branca, primeiro você precisa entender o software que está testando, conhecer o código e saber qual é o comportamento esperado. Em seguida, crie casos de teste escrevendo código adicional para verificar onde a execução pode falhar e onde vulnerabilidades podem ser exploradas.

Em geral, os testes de caixa branca abrangem:

• Brechas de segurança internas

• O fluxo de entradas específicas pelo código

• Resultados esperados e inesperados

• Caminhos de código com falhas ou mal estruturados

• A lógica de um loop condicional

• O comportamento de cada função e classe

• Como o software lida com entradas específicas

Técnicas de teste de caixa branca

O teste de invasão de caixa branca é uma parte fundamental dos testes de segurança, pois oferece uma análise completa das vulnerabilidades internas e externas. A colaboração entre testadores de segurança e desenvolvedores proporciona um entendimento aprofundado do sistema e das possíveis formas de explorá-lo. Um exemplo dessa técnica é verificar a segurança e a confiabilidade de um aplicativo bancário e garantir que não haja brechas na lógica de negócios.

Entre as técnicas mais comuns de teste de caixa branca estão:

• Cobertura de condições: técnica usada para testar as variáveis de uma subexpressão por meio de condições lógicas

• Cobertura de instruções: essa técnica envolve executar um conjunto de testes nas instruções do código e também é conhecida como cobertura de linhas. Cada instrução é testada pelo menos uma vez.

• Cobertura de ramificações: os testadores usam essa técnica para garantir que cada ramificação do código seja testada pelo menos uma vez.

• Cobertura de caminhos: geralmente realizada para testar cada caminho individual em uma aplicação.

• Teste de fluxo de dados: usado para examinar o fluxo de dados no software em relação às variáveis do código.

Testes de caixa branca vs. caixa-preta

Os testes de caixa branca e de caixa-preta são métodos para detectar falhas no software. Embora ambos sejam técnicas de teste bastante usadas, são bem diferentes. A tabela abaixo apresenta as principais diferenças entre eles.

Diagrama de teste de caixa-preta

Por isso, testes de caixa branca e de caixa-preta não são intercambiáveis. Não basta realizar apenas um ou outro. Em vez disso, essas duas técnicas se complementam para ajudar a entregar um software melhor. Quando usadas em conjunto, elas formam uma técnica conhecida como teste de caixa cinza.

Vantagens e desvantagens dos testes de caixa branca

Os testes de caixa branca têm vantagens e desvantagens próprias.

Vantagens:

• O testador já conhece o sistema que está sendo testado, o que reduz bastante o tempo necessário para obter informações ou fazer o reconhecimento.

• Permitem testes mais completos e a descoberta de mais riscos de segurança do que qualquer outra técnica de teste.

• Por serem de baixo nível, podem ser integrados a pipelines de CI com a ajuda de ferramentas automatizadas de segurança, como o SonarQube.

• A técnica é mais próxima do código, o que facilita a correção das vulnerabilidades identificadas pelos desenvolvedores.

Desvantagens:

• Por serem tão completos, são a técnica de teste mais demorada e cara.

• Exigem um conhecimento mais aprofundado do sistema em teste.

Conclusão

Por sua própria natureza, os testes de caixa branca são fundamentais para adotar a cultura DevOps no ciclo de vida de desenvolvimento seguro de software. Como podem ser automatizados, geralmente são executados em pipelines de CI para dar feedback rápido aos desenvolvedores enquanto eles verificam o código.

Ferramentas de teste de segurança de caixa branca, como o Snyk Code, integram o teste estático de segurança de aplicações ao pipeline de DevSecOps, oferecendo aos desenvolvedores a maior cobertura de testes necessária para identificar riscos de segurança com antecedência no processo de desenvolvimento.