O que é o teste de fuzz?

O teste de fuzz, ou fuzzing de aplicativos, é uma técnica de teste de software que permite que as equipes descubram vulnerabilidades ou bugs de segurança no código-fonte de aplicativos de software. Ao contrário das metodologias tradicionais de teste de software – SAST, DAST ou IAST – o fuzzing essencialmente envia “pings” de código com entradas aleatórias para tentar causar uma falha e, assim, identificar problemas que, de outra forma, não seriam aparentes. Essas falhas de código (ou problemas com a lógica de negócios) representam áreas com alto risco de ameaças à segurança.

Quando uma falha ou vulnerabilidade é encontrada, um fuzzer — uma ferramenta que identifica as possíveis causas da falha — pode ser usado para encontrar vulnerabilidades específicas no código-fonte. Os fuzzers são mais eficazes na descoberta de vulnerabilidades que podem ser exploradas por ataques como injeção de SQL e cross-site scripting, quando os hackers desativam a segurança para roubar informações ou derrubar um sistema. Os fuzzers são menos eficazes na identificação de vulnerabilidades não relacionadas a falhas no sistema, como spyware ou cavalos de Tróia.

Os apoiadores do teste de fuzz o elogiam por ser totalmente automatizado e capaz de encontrar fraquezas obscuras, enquanto seus críticos reclamam que ele pode ser difícil de configurar e propenso a fornecer resultados não confiáveis.

O teste de fuzz também se destaca de outra maneira: há toda uma história sobre como o conceito foi descoberto. Em 1988, o professor Barton Miller, da Universidade de Wisconsin – Madison, estava tentando acessar um código remotamente usando um sistema de discagem, mas o feedback de uma tempestade fazia com que o programa falhasse. A ideia de que o “ruído” externo não podia ser tolerado pelo código tornou-se a inspiração para o trabalho de Miller e seu aluno. Eles descobriram que os programas Unix, Mac e Windows apresentavam falhas rotineiras quando recebiam ping de entradas inesperadas aleatórias. Miller é um dos autores de Fuzzing for Software Security Testing and Quality Assurance.

Existem dois tipos principais de fuzzing: guiado por cobertura e comportamental.

O fuzzing guiado por cobertura se concentra no código-fonte enquanto o aplicativo está em execução, analisando-o com entradas aleatórias para descobrir bugs. Novos testes são gerados constantemente, e o objetivo é fazer com que o aplicativo falhe. Uma falha significa um problema em potencial, e os dados do processo de teste de fuzzing guiado por cobertura permitirão que um testador reproduza a falha, o que é útil ao tentar identificar o código em risco.

O fuzzing comportamental funciona de forma diferente. Usando especificações para mostrar como um aplicativo deve funcionar, ele usa entradas aleatórias para julgar como o aplicativo realmente funciona; a diferença entre o esperado e a realidade é geralmente onde bugs ou outros riscos de segurança em potencial podem ser encontrados.

Por que o teste de fuzz é importante para DevSecOps? Devido à natureza aleatória do teste de fuzz, os especialistas dizem que essa é a metodologia com maior probabilidade de encontrar bugs não encontrados por outros testes. Ele também é visto como uma metodologia de teste de baixo esforço, em que só é necessário "configurar e esquecer". Uma vez que o equipamento de teste é criado, o teste de fuzz é totalmente automatizado e será executado indefinidamente. A escala dele pode ser ajustada facilmente inicializando mais máquinas e é uma boa escolha para testes de regressão. O fuzzing também acelera o processo de desenvolvimento, maximizando a cobertura de código — quanto do código foi executado pelo fuzzer — sem introduzir falsos positivos. Uma cobertura de código mais alta significa testes mais completos.

O teste de fuzz também é ideal para trabalhar ao lado de uma equipe de teste manual, pois ambos os conjuntos de entradas informam um ao outro.

Os profissionais que buscam implementar testes de fuzz enfrentam dois principais desafios: configuração e análise de dados. O teste de fuzz não é necessariamente fácil de configurar; ele requer "equipamentos" de teste complexos que podem ser ainda mais complicados de criar se o teste de fuzz não estiver localizado em uma cadeia de ferramentas existente. Além disso, o teste de fuzz pode gerar muitos dados, incluindo possíveis falsos positivos. Portanto, é fundamental garantir que uma equipe de teste esteja preparada para lidar com o grande volume de informações.

Além disso, embora seja menos fácil de documentar, as atitudes negativas em relação à natureza "vaga" do teste de fuzz persistem na comunidade de QA.