OWASP Mobile Top 10: o que é, lista de vulnerabilidades e como aplicar

O que é OWASP Mobile Top 10?

OWASP Mobile Top 10 é uma lista padronizada dos riscos de segurança mais críticos específicos para aplicativos móveis. Ao contrário do OWASP Top 10 geral para aplicativos web, a versão móvel leva em conta as especificidades das plataformas: armazenamento local no dispositivo, interação com sensores, modos offline e peculiaridades das lojas de aplicativos. O documento é publicado desde 2010 e é revisado a cada 2–4 anos: a versão atual de 2024 inclui categorias como M1 — Improper Credential Usage e M8 — Security Misconfiguration. O projeto é apoiado por uma comunidade de mais de 500 voluntários em todo o mundo.

História e propósito

Originalmente, o OWASP Top 10 cobria apenas aplicativos web, mas o crescimento do desenvolvimento móvel nos anos 2010 exigiu um documento separado. A primeira versão do Mobile Top 10 foi lançada em 2011 e continha apenas 7 itens. Em 2024, a lista se expandiu para 10 categorias, cada uma incluindo vários cenários de ataque específicos. O objetivo principal do documento é dar aos desenvolvedores e equipes de segurança uma linguagem comum para discutir riscos e priorizar correções. As atualizações regulares da lista refletem mudanças no cenário de ameaças: o surgimento de novas APIs, a evolução dos sistemas operacionais (Android, iOS) e novas técnicas de ataque descritas em relatórios da Positive Technologies e outros centros de pesquisa.

Como a lista OWASP Mobile Top 10 é formada

A metodologia para compilar o Mobile Top 10 é baseada em dados de projetos reais: resultados de pentests de aplicativos móveis, relatórios de incidentes e pesquisas de vulnerabilidades são analisados. Cada categoria é avaliada por dois parâmetros: Taxa de Incidência (Incidence Rate) e Impacto Técnico (Technical Impact). A combinação dessas métricas forma a classificação final. Ao contrário de listas subjetivas, a OWASP usa dados abertos: qualquer membro da comunidade pode enviar uma solicitação para incluir uma nova categoria através do repositório GitHub do projeto. Para a versão atual de 2024, mais de 300.000 testes de segurança de 25 países foram processados, tornando as estatísticas representativas do ecossistema global de desenvolvimento móvel. Além disso, a OWASP publica o MASVS (Mobile Application Security Verification Standard) — um conjunto de requisitos de segurança detalhados que inclui mais de 80 verificações específicas distribuídas em 8 categorias. O MASVS é usado como base para certificação de aplicativos e como lista de verificação para pentests: cada requisito tem uma referência a uma categoria do Mobile Top 10, garantindo rastreabilidade entre o padrão e a lista de riscos.

Visão geral das principais vulnerabilidades do top 10

Vamos examinar as três categorias mais críticas do OWASP Mobile Top 10 2024, que cobrem mais de 70% de todos os incidentes de segurança em projetos móveis. Cada categoria inclui cenários de exploração específicos e recomendações de proteção.

Uso inadequado da plataforma

Esta categoria (M1) cobre situações em que os desenvolvedores usam APIs e mecanismos de plataforma de forma inadequada. Exemplos típicos: Intent Injection no Android, manipuladores de Deep Link abertos no iOS, manuseio incorreto de Keychain e SharedPreferences. Um atacante pode enviar um Intent especialmente criado e obter acesso a dados de outro aplicativo ou componente. De acordo com o relatório da NowSecure (2023), 22% dos aplicativos Android testados continham vulnerabilidades do tipo Intent Redirection. A proteção inclui: validação rigorosa de dados de entrada, verificação da origem do Intent e uso de permissões para componentes exportados.

Armazenamento inseguro de dados

Armazenamento inseguro de dados (M2) é o problema mais comum em aplicativos móveis. Ocorre quando dados confidenciais (tokens de acesso, senhas, dados pessoais) são armazenados em texto simples ou com proteção insuficiente. Fontes típicas de vulnerabilidade: bancos de dados SQLite sem criptografia, SharedPreferences sem EncryptedSharedPreferences, registro de dados em modo debug. De acordo com a OWASP Foundation (2024), mais de 60% dos aplicativos gratuitos no Google Play armazenam pelo menos um tipo de dado confidencial de forma não criptografada. A solução é usar Android EncryptedSharedPreferences, iOS Keychain e criptografar os dados antes de escrever no armazenamento local.

Comunicação insegura

A categoria M3 — Comunicação insegura — inclui vulnerabilidades nos canais de transmissão de dados entre o aplicativo e o servidor. Falta de HTTPS, validação incorreta de certificados SSL, uso de protocolos TLS 1.0/1.1 obsoletos — todos esses problemas permitem que um atacante intercepte o tráfego através de ataques Man-in-the-Middle. A situação é especialmente perigosa quando o aplicativo lida com dados sensíveis (transações bancárias, informações médicas) através de um canal não protegido. Em 2023, pesquisadores do NCC Group descobriram que 12% dos aplicativos financeiros populares usam configuração TLS incorreta. Recomendação: uso obrigatório de HTTPS com Certificate Pinning e rejeição de HTTP em compilações de produção.

Como testar aplicativos de acordo com OWASP Mobile Top 10

O teste de segurança de um aplicativo móvel usando a metodologia OWASP inclui várias etapas: análise estática de código (SAST), análise dinâmica (DAST) e teste manual (pentest). Cada etapa visa identificar categorias específicas de vulnerabilidades do Mobile Top 10.

Ferramentas de teste

Para análise automatizada, a OWASP recomenda o uso do MobSF (Mobile Security Framework) — uma ferramenta de código aberto. O MobSF realiza análise estática de código fonte e arquivos binários, verifica a configuração do manifesto, analisa permissões e identifica vulnerabilidades do Mobile Top 10. Para análise dinâmica, são usados Burp Suite (proxy para interceptação de tráfego) e Frida (ferramenta de análise em tempo de execução). A combinação dessas ferramentas cobre mais de 80% das categorias da lista. Testes regulares em um pipeline CI/CD com MobSF permitem identificar vulnerabilidades nos estágios iniciais do desenvolvimento e reduzem o custo de corrigi-las em 60–70%. A integração de ferramentas SAST e DAST no pipeline deve ser automatizada através de plugins Gradle/Maven ou etapas Fastlane em compilações iOS.

Interpretação do relatório MobSF

Após executar o MobSF, o desenvolvedor recebe um relatório com indicadores de cor: vermelho — vulnerabilidade crítica, laranja — risco médio, amarelo — risco baixo. Cada aviso contém uma referência à categoria correspondente do OWASP Mobile Top 10, uma descrição do problema e uma recomendação de correção. É importante não apenas eliminar os avisos vermelhos, mas também analisar os laranjas: muitos deles (por exemplo, Activities exportadas sem proteção) podem se combinar para dar ao atacante um vetor de ataque. Recomenda-se atingir zero avisos vermelhos e não mais que 2–3 laranjas antes de cada lançamento. O relatório MobSF também inclui uma análise das permissões do aplicativo: qualquer permissão excessiva (por exemplo, acesso à câmera em uma calculadora) é sinalizada como violação do princípio do menor privilégio e deve ser removida do manifesto. Para aplicativos iOS, o MobSF realiza uma análise semelhante de arquivos .ipa, incluindo verificação do Info.plist para exceções ATS e análise de binários Mach-O para APIs inseguras como NSAllowsArbitraryLoads.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}