MASTG-TEST-0042: Verificação de Vulnerabilidades em Bibliotecas de Terceiros

Deprecated Test

This test is deprecated and should not be used anymore. Reason: New version available in MASTG V2

Please check the following MASTG v2 tests that cover this v1 test:

Visão Geral¶

Análise Estática¶

A detecção de vulnerabilidades em dependências de terceiros pode ser realizada por meio do OWASP Dependency Checker. Isso é melhor feito usando um plugin do gradle, como o dependency-check-gradle. Para usar o plugin, as seguintes etapas devem ser aplicadas: Instale o plugin do repositório central do Maven adicionando o seguinte script ao seu build.gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.owasp:dependency-check-gradle:3.2.0'
    }
}

apply plugin: 'org.owasp.dependencycheck'

Uma vez que o gradle invocou o plugin, você pode criar um relatório executando:

gradle assemble
gradle dependencyCheckAnalyze --info

O relatório estará em build/reports, a menos que configurado de outra forma. Use o relatório para analisar as vulnerabilidades encontradas. Consulte a seção de remediation sobre o que fazer diante das vulnerabilidades encontradas nas bibliotecas.

Por favor, note que o plugin requer o download de um feed de vulnerabilidades. Consulte a documentação caso surjam problemas com o plugin.

Por fim, observe que para aplicações híbridas, será necessário verificar as dependências JavaScript com o RetireJS. Da mesma forma, para Xamarin, será necessário verificar as dependências C#.

Quando uma biblioteca é encontrada com vulnerabilidades, aplica-se o seguinte raciocínio:

A biblioteca está empacotada com a aplicação? Então verifique se a biblioteca possui uma versão na qual a vulnerabilidade está corrigida. Caso não tenha, verifique se a vulnerabilidade realmente afeta a aplicação. Se for o caso ou puder ser no futuro, procure uma alternativa que ofereça funcionalidade similar, mas sem as vulnerabilidades.
A biblioteca não está empacotada com a aplicação? Veja se há uma versão corrigida na qual a vulnerabilidade está fixada. Se não houver, verifique as implicações da vulnerabilidade para o processo de build. A vulnerabilidade poderia impedir um build ou enfraquecer a segurança do pipeline de build? Tente procurar uma alternativa na qual a vulnerabilidade esteja corrigida.

Quando os fontes não estão disponíveis, pode-se descompilar o app e verificar os arquivos JAR. Quando o Dexguard ou Proguard são aplicados corretamente, as informações de versão sobre a biblioteca geralmente são ofuscadas e, portanto, removidas. Caso contrário, você ainda pode encontrar a informação com frequência nos comentários dos arquivos Java das bibliotecas fornecidas. Ferramentas como a MobSF podem ajudar na análise das possíveis bibliotecas empacotadas com a aplicação. Se você conseguir recuperar a versão da biblioteca, seja por comentários ou por métodos específicos usados em determinadas versões, pode procurar manualmente por CVEs.

Se a aplicação é de alto risco, você acabará avaliando a biblioteca manualmente. Nesse caso, há requisitos específicos para código nativo, que você pode encontrar no capítulo "Testando a Qualidade do Código)". Além disso, é bom verificar se todas as melhores práticas de engenharia de software foram aplicadas.

Análise Dinâmica¶

A análise dinâmica desta seção compreende validar se os direitos autorais das licenças foram respeitados. Isso frequentemente significa que a aplicação deve ter uma seção about ou EULA na qual as declarações de copyright estejam anotadas conforme exigido pela licença da biblioteca de terceiros.