Minha maior experiência em TI é no ambiente de desenvolvimento. Foram quase 20 anos desenvolvendo software. Há pouco mais de um ano venho atuando com AppSec e em muitas reuniões que participo, o assunto “Teste” sempre aparece, mais precisamente “Teste de Segurança”.
Você também pode ouvir esse conteúdo:
Normalmente no seguinte contexto: “precisamos testar se nosso software está seguro” ou “os requisitos de segurança que os desenvolvedores implementaram foram testados?”
E eu me perguntava, será possível unir esses dois mundos? Será que não podemos aproveitar os testes que o desenvolvedor já faz e adicionar uma “visão” de segurança?
Vamos aos Conceitos sobre teste de unidade e teste de segurança
Antes de mais nada, vamos contextualizar de forma simples o que seria um teste de software e o que seria um teste de segurança.
Quando falamos de testes de software, normalmente estamos falando sobre testes para verificar a qualidade do código, se o fluxo de dados segue o que se espera e se a aplicação se comportará como o esperado em ambiente de produção.
Agora no caso dos testes de segurança a ideia é encontrar vulnerabilidades ou falhas de segurança. No blog da Conviso temos um artigo mais abrangente sobre testes de segurança. Acredito que valha a leitura.
O primeiro insight
Ao olhar para o OWASP SAMM, dentro do domínio de Verificação, temos a prática testes baseados em requisitos. Quando comecei a ler sobre essa prática, automaticamente vislumbrei que, cabe um teste de unidade, teste de integração, enfim, cabe aproveitar o que o desenvolvedor já faz!
Figura 1 – OWASP SAMM
O segundo insight
Um certo dia aparece na minha timeline do Youtube um vídeo com o título “DevSecOps wins with Security Unit Tests”. Confesso que até hoje não assisti ao vídeo por completo, mas só o título já me fez ter algumas ideias e também ver que o meu pensamento inicial poderia funcionar.
Depois desse vídeo comecei a buscar coisas relacionadas ao assunto e encontrei mais um Let’s Write Security Unit Tests! Legal, mais um case interessante.
Na minha cabeça eu não tinha dúvidas que era possível, mas eu estava iniciando na área, e ver que existiam materiais sobre o assunto em canais de referência como a OWASP só me deixava mais animado.
Talk is cheap! Show me the code!
Como todo desenvolvedor, adoro a frase acima! Nada mais justo do que implementar um requisito de segurança e aplicar nesse requisito um “teste de software”, mais precisamente um teste de unidade na função.
Para a prova de conceito escolhi a linguagem de programação C#, o framework .Net Core e para construir e executar o teste de unidade utilizaremos a ferramenta XUnit.
O requisito de segurança escolhido para ser implementado e testado será o requisito de segurança “2.1.1 – Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined)” do OWASP ASVS.
A ideia aqui não é fazer um passo a passo, apenas mostrar os códigos gerados e também os resultados esperados.
Foi criada uma função que validará se uma senha atende aos requisitos do ASVS, o código gerado pode ser verificado na Figura 2.
Figura 2 – Código para atender requisito ASVS 2.1.1
Agora criaremos o teste de unidade que validará a função “IsValidPassword” criada na Figura 2. Podemos visualizar o código do teste de unidade na Figura 3. Basicamente, nosso teste de unidade verificará cada “condição” da nossa função “IsValidPassword”.
Figura 3 – Código Teste de Unidade
Chegou a hora de executar o teste de unidade, garantir que tudo está “passando” e que nossa função “IsValidPassword” realmente está funcionando. Quem fará isso é nosso teste de unidade.
No .Net core, a instrução para executar o teste é “dotnet teste Projeto onde está o teste”, no meu caso a instrução ficou da seguinte maneira:
dotnet test K8ServiceMesh.Tests/K8ServiceMesh.Tests.csproj
O resultado esperado foi alcançado e todos os testes passaram, conforme ilustra a Figura 4, logo, podemos enviar esse código para produção.
Vamos supor que foi isso que aconteceu, agora o nosso código se encontra em produção!
Figura 4 – Resultado teste de unidade
Legal, porém, outro desenvolvedor tinha uma nova feature para fazer, ele olhou a função criada anteriormente e decidiu remover a “condição” que verifica se existe uma letra maiúscula na senha conforme ilustra a Figura 5.
Acho que aqui todos concordam que se a alteração feita chegar em produção significa que nosso sistema não estará atendendo ao requisito do ASVS 2.1.1 e que será permitido utilizar senhas sem letras maiúsculas.
Figura 5 – Código modificado, retirado a condição de verificação de letras maiúsculas.
Então o desenvolvedor fez a modificação no código, agora ele precisa executar o teste de unidade para verificar se o que ele fez quebrou alguma coisa, se quebrou algum teste. Vamos então executar novamente o teste de unidade e agora teremos algo parecido com a Figura 6.
Figura 6 – Teste de unidade quebrando
Podemos verificar que o teste de unidade quebrou e diz exatamente onde quebrou. Quebrou na verificação de letras maiúsculas.
Isso mostra para o desenvolvedor que ele não pode modificar o código da forma que ele fez e mais! Está garantindo que o requisito 2.1.1 do ASVS não deixe de ser atendido.
Conclusão
Um dos grandes problemas que enfrentamos enquanto profissionais de segurança é a discrepância entre os tamanhos dos times de desenvolvimento e segurança.
Conhecer o que o desenvolvedor faz e como ele faz, pode ajudar muito um profissional de segurança de aplicações a reaproveitar as atividades diárias de um desenvolvedor em prol da segurança de aplicações.
Os testes que os desenvolvedores já executam em seu cotidiano podem tomar ares de testes de segurança, desde que esses desenvolvedores tenham uma visão mais apurada sobre segurança
Essa minha conclusão não é uma “bala de prata” e de forma alguma substitui todas as outras práticas recomendadas para a construção e entrega de software seguro, mas com certeza pode se tornar mais uma camada entre as outras tantas no que tange a S-SDLC.
