MASTG-TEST-0085: Verificação de Fraquezas em Bibliotecas de Terceiros
Deprecated Test
This test is deprecated and should not be used anymore. Reason: Nova versão disponível no MASTG V2
Please check the following MASTG v2 tests that cover this v1 test:
Visão Geral¶
Análise Estática¶
Detecção de vulnerabilidades em bibliotecas de terceiros¶
Para garantir que as bibliotecas utilizadas pelos aplicativos não contenham vulnerabilidades, é recomendável verificar as dependências instaladas pelo CocoaPods ou Carthage.
Swift Package Manager¶
Caso o Swift Package Manager seja utilizado para gerenciar dependências de terceiros, as seguintes etapas podem ser tomadas para analisar as bibliotecas de terceiros em busca de vulnerabilidades:
Primeiro, na raiz do projeto, onde o arquivo Package.swift está localizado, digite:
swift build
Em seguida, verifique o arquivo Package.resolved para as versões reais utilizadas e inspecione as bibliotecas fornecidas em busca de vulnerabilidades conhecidas.
Você pode utilizar o OWASP Dependency-Check com seu Swift Package Manager Analyzer experimental para identificar o esquema de nomenclatura Common Platform Enumeration (CPE) de todas as dependências e quaisquer entradas correspondentes Common Vulnerability and Exposure (CVE). Escaneie o arquivo Package.swift do aplicativo e gere um relatório de bibliotecas vulneráveis conhecidas com o seguinte comando:
dependency-check --enableExperimental --out . --scan Package.swift
CocoaPods¶
Caso o CocoaPods seja utilizado para gerenciar dependências de terceiros, as seguintes etapas podem ser tomadas para analisar as bibliotecas de terceiros em busca de vulnerabilidades.
Primeiro, na raiz do projeto, onde o Podfile está localizado, execute os seguintes comandos:
sudo gem install cocoapods
pod install
Em seguida, agora que a árvore de dependências foi construída, você pode criar uma visão geral das dependências e suas versões executando os seguintes comandos:
sudo gem install cocoapods-dependencies
pod dependencies
O resultado das etapas acima agora pode ser usado como entrada para pesquisar diferentes feeds de vulnerabilidades em busca de vulnerabilidades conhecidas.
Nota:
- Se o desenvolvedor empacota todas as dependências em termos de sua própria biblioteca de suporte usando um arquivo .podspec, então este arquivo .podspec pode ser verificado com o verificador experimental de podspec do CocoaPods.
- Se o projeto utiliza CocoaPods em combinação com Objective-C, o SourceClear pode ser utilizado.
- Usar CocoaPods com links baseados em HTTP em vez de HTTPS pode permitir ataques do tipo Man-in-the-Middle (MITM)) durante o download da dependência, permitindo que um invasor substitua (partes da) biblioteca por outro conteúdo. Portanto, sempre use HTTPS.
Você pode utilizar o OWASP Dependency-Check com seu Analisador CocoaPods experimental para identificar o esquema de nomenclatura Common Platform Enumeration (CPE) de todas as dependências e quaisquer entradas correspondentes Common Vulnerability and Exposure (CVE). Escaneie os arquivos *.podspec e/ou Podfile.lock do aplicativo e gere um relatório de bibliotecas vulneráveis conhecidas com o seguinte comando:
dependency-check --enableExperimental --out . --scan Podfile.lock
Carthage¶
Caso o Carthage seja utilizado para dependências de terceiros, então as seguintes etapas podem ser tomadas para analisar as bibliotecas de terceiros em busca de vulnerabilidades.
Primeiro, na raiz do projeto, onde o Cartfile está localizado, digite:
brew install carthage
carthage update --platform iOS
Em seguida, verifique o Cartfile.resolved para as versões reais utilizadas e inspecione as bibliotecas fornecidas em busca de vulnerabilidades conhecidas.
Nota: no momento da escrita deste capítulo, não há suporte automatizado conhecido pelos autores para análise de dependências baseada em Carthage. Pelo menos, esse recurso já foi solicitado para a ferramenta OWASP DependencyCheck, mas ainda não foi implementado (veja a issue no GitHub).
Vulnerabilidades descobertas em bibliotecas¶
Quando uma biblioteca é encontrada contendo vulnerabilidades, aplica-se o seguinte raciocínio:
- A biblioteca está empacotada com o aplicativo? 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 o aplicativo. Se for o caso ou puder ser no futuro, procure uma alternativa que forneça funcionalidade similar, mas sem as vulnerabilidades.
- A biblioteca não está empacotada com o aplicativo? 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? Então tente procurar uma alternativa na qual a vulnerabilidade esteja corrigida.
No caso de frameworks adicionados manualmente como bibliotecas vinculadas:
- Abra o arquivo xcodeproj e verifique as propriedades do projeto.
- Vá para a aba Build Phases e verifique as entradas em Link Binary With Libraries para qualquer uma das bibliotecas. Veja seções anteriores sobre como obter informações similares usando MobSF.
No caso de fontes copiadas e coladas: pesquise os arquivos de cabeçalho (no caso de uso de Objective-C) e, caso contrário, os arquivos Swift por nomes de métodos conhecidos de bibliotecas conhecidas.
Além disso, observe que para aplicativos híbridos, você terá que verificar as dependências JavaScript com RetireJS. Da mesma forma, para Xamarin, você terá que verificar as dependências C#.
Por último, se o aplicativo for de alto risco, você acabará verificando a biblioteca manualmente. Nesse caso, existem requisitos específicos para código nativo, que são semelhantes aos requisitos estabelecidos pelo MASVS para o aplicativo como um todo. Além disso, é bom verificar se todas as melhores práticas de engenharia de software são aplicadas.
Análise Dinâmica¶
A análise dinâmica desta seção compreende duas partes: a verificação real da licença e a verificação de quais bibliotecas estão envolvidas no caso de fontes ausentes.
É necessário validar se os direitos autorais das licenças foram respeitados. Isso geralmente significa que o aplicativo deve ter uma seção about ou EULA na qual as declarações de direitos autorais são anotadas conforme exigido pela licença da biblioteca de terceiros.
Listagem de Bibliotecas do Aplicativo¶
Ao realizar a análise de aplicativos, é importante também analisar das dependências do aplicativo (geralmente na forma de bibliotecas ou chamados iOS Frameworks) e garantir que elas não contenham vulnerabilidades. Mesmo quando você não tem o código-fonte, ainda pode identificar algumas das dependências do aplicativo usando ferramentas como objection, MobSF ou o comando otool -L. O Objection é a ferramenta recomendada, pois fornece os resultados mais precisos e é fácil de usar. Ele contém um módulo para trabalhar com iOS Bundles, que oferece dois comandos: list_bundles e list_frameworks.
O comando list_bundles lista todos os bundles do aplicativo que não estão relacionados a Frameworks. A saída contém nome do executável, ID do bundle, versão da biblioteca e caminho para a biblioteca.
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios bundles list_bundles
Executable Bundle Version Path
------------ ----------------------------------------- --------- -------------------------------------------
DVIA-v2 com.highaltitudehacks.DVIAswiftv2.develop 2 ...-1F0C-4DB1-8C39-04ACBFFEE7C8/DVIA-v2.app
CoreGlyphs com.apple.CoreGlyphs 1 ...m/Library/CoreServices/CoreGlyphs.bundle
O comando list_frameworks lista todos os bundles do aplicativo que representam Frameworks.
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios bundles list_frameworks
Executable Bundle Version Path
-------------- ----------------------------------------- --------- -------------------------------------------
Bolts org.cocoapods.Bolts 1.9.0 ...8/DVIA-v2.app/Frameworks/Bolts.framework
RealmSwift org.cocoapods.RealmSwift 4.1.1 ...A-v2.app/Frameworks/RealmSwift.framework
...ystem/Library/Frameworks/IOKit.framework
...