Cursos que formaram meu caráter: Desenvolvimento web com Quarkus - Validação de vulnerabilidades com OWASP Dependency Check
"Mais visibilidade é mais poder, mas mais vulnerabilidade". Ezra Furman
Nesse sétimo post falaremos sobre vulnerabilidades em bibliotecas. Se você trabalha com Java há algum tempo, creio que a vulnerabilidade do Log4j possa ter te dado algumas dores de cabeça.
Como desenvolvedores, um ponto que falaremos é o que fazer quando descobrirmos um vulnerabilidade. Lembre-se que:
"Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada". H L Mencken
Esse artigo faz parte de uma série, abaixo é possível encontrar a lista completa de artigos.
Estamos nos baseando no curso Desenvolvimento web com Quarkus do Vinicius Ferraz .
O repositório que estamos utilizando é:
Vulnerabilidades
Em TI temos uma máxima de que não existe sistema perfeito! Mesmo soluções que funcionam sem nenhum problema aparente podem apresentar problemas desconhecidos ou novos problemas dado a evolução de outras bibliotecas ou mesmo outros problemas.
O cenário do Log4J aconteceu recentemente, e o pessoal do Coffee And IT Coffee and IT até fez um vídeo explicando com um viés de desenvolvimento.
Algumas perguntas podem ficar em nossas cabeça:
OWASP e CVE
Um dos pontos de início pode ser a OWASP (The Open Web Application Security Project).
A OWASP é uma fundação sem fins lucrativos que trabalha para melhorar a segurança do software. Eles possuem Chapters em vários países, bem como realizam uma série de eventos com esse foco.
Uma de suas publicações mais conhecidas é o OWASP Top Ten em que são documentadas as 10 maiores vulnerabilidades dados um período de tempo.
Outro termo que falaremos também é o CVE (Common Vulnerabilities and Exposures). No Maven Repo é bem comum ver uma observação quando estamos buscando uma biblioteca.
Note que a versão 2.15.0.Final do Quarkus JUnit 5 nos apresenta alguns alertas:
Olhando um pouco mais para as versões do quarkus-junit5 podemos ver que para a versão 2 do Quarkus ainda não temos nenhuma correção para essas vulnerabilidades.
Estou vulnerável, e agora?
Um insight legal que recomendo a todos desenvolvedores é: converse com pessoas de outras áreas para formar uma opinião.
Como desenvolvedores é bem comum acharmos vulnerabilidades e já pensarmos em subir novas versões ou já colocar a mão no código.
Há uns anos atrás tive uma conversa com o Bruno Almeida na ília digital ; ele por ter um background em segurança me fez exatamente essa pergunta, questionando sobre o que eu faria.
Falei que iria atualizar as bibliotecas, alterar o código e coisas do tipo.
Ele então me trouxe um outro ponto de vista bem interessante: Será que preciso atualizar o código? Será que a vulnerabilidade que tenho é passível de ser explorada? Algumas vezes trabalhamos com APIs e diversas camadas como microservices, API Gateway dentre outras, e pode ser que uma fez configurado algo em uma camada superior, não seja passível de se explorar a vulnerabilidade.
Recomendados pelo LinkedIn
O ponto então que ficou em minha mente foi: é importante descobrir as vulnerabilidades que estamos expostos, em seguida entender se essas vulnerabilidades são passíveis de serem exploradas, e caso sejam passíveis de serem exploradas, analisar o impacto de correção nos pontos de nossa solução em que tal vulnerabilidade pode ser explorada.
Automatizando a descoberta de possíveis vulnerabilidades
A OWASP tem um projeto bem interessante, o Dependency-Check.
Ele possui uma série de plugins e integrações que podemos usar para descobrir CVEs no nosso projeto.
No arquivo build.gradle do nosso projeto podemos ver a primeira parte da configuração do plugin:
plugins {
...
id "org.owasp.dependencycheck" version "$dependencyCheckVersion" apply false
}
...
subprojects {
if (it.name != 'applications') {
...
apply from: "$rootDir/plugins/security.gradle"
}
}
E no arquivo plugins/security.gradle podemos ver a segunda parte da configuração:
apply plugin: "org.owasp.dependencycheck"
dependencyCheck {
autoUpdate = true
format = "ALL"
outputDirectory = "build/reports/dependencyCheck"
}
Para a lista de demais configurações, acesse o link.
A task que iremos utilizar para executar o plugin será a dependencyCheckAnalyze
Essa task busca as vulnerabilidades associadas a nossas dependências e nos da um detalhamento.
Abrindo o arquivo dependency-check-report.html temos o seguinte:
Além de informar as bibliotecas que temos vulnerabilidades, o plugin consegue obter mais detalhes sobre o problema, situações em que ele acontece e às vezes até direcionamentos sobre a solução. No caso da venerabilidade no okhttp-3.14.9.jar temos:
In verifyHostName of OkHostnameVerifier.java, there is a possible way to accept a certificate for the wrong domain due to improperly used crypto. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.1 Android-9 Android-10 Android-11Android ID: A-171980069
Integração com SonarQube
Outra coisa que podemos fazer é instalar o plugin no nosso SonarQube e assim termos uma rastreabilidade de vulnerabilidades como parte do nosso relatório do projeto.
Ignorando falsos positivos
É possível ainda ignorar falsos positivos através da configuração suppressionFile.
Conclusão
O OWASP Dependency Check é um plugin fantástico que pode nos ajudar na descoberta de vulnerabilidades em nossos projetos. Uma consideração é avaliarmos o impacto de tais vulnerabilidades em nossos códigos, além do custo de correção caso seja o nosso caso.
No próximo post falaremos do último plugin utilizado no projeto. Ele será bem importante para formatação do nosso código Groovy, Java, SQL, dentre outros.
Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.
A série completa é:
Original post published at https://dev.to on December 18th, 2022.