OWASP Mobile Top 10 2024

O OWASP Mobile Top 10 é uma lista compilada pelo Open Web Application Security Project (OWASP), uma comunidade de segurança sem fins lucrativos voltada para o aprimoramento da segurança de software. Essa lista identifica e descreve as dez vulnerabilidades mais críticas e comuns que afetam os aplicativos móveis. O objetivo do OWASP Mobile Top 10 é aumentar a conscientização sobre as ameaças à segurança móvel e fornecer orientação aos desenvolvedores, profissionais de segurança e organizações para reduzir esses riscos.

Cada vulnerabilidade da lista é detalhada com uma descrição, indicadores que podem indicar sua presença, recomendações de atenuação e exemplos de ataques relacionados. Essas vulnerabilidades abrangem uma ampla gama de problemas de segurança, desde autenticação e autorização deficientes até armazenamento inseguro de dados e proteção criptográfica insuficiente. O OWASP Mobile Top 10 foi atualizado em 2024, após 8 anos, e reflete as últimas tendências e desafios no campo da segurança móvel, fornecendo assim uma orientação valiosa para a comunidade de desenvolvimento de aplicativos.

Vulnerabilidade M1: uso inadequado de credenciais

A vulnerabilidade M1, "Uso inadequado de credenciais", refere-se a práticas inadequadas relacionadas ao gerenciamento e ao armazenamento de credenciais em aplicativos móveis. Essa vulnerabilidade pode surgir quando as credenciais (como nomes de usuário, senhas, tokens de autenticação etc.) não são tratadas com segurança, expondo-as a possíveis invasores.

Indicadores de risco

 • Armazenamento inseguro: as credenciais são armazenadas em texto simples no sistema de arquivos do dispositivo, em bancos de dados não criptografados ou em preferências compartilhadas desprotegidas.

 • Transmissão insegura: As credenciais são enviadas pela rede sem criptografia (por exemplo, usando HTTP em vez de HTTPS).

 • Tratamento inadequado da sessão: as sessões não são invalidadas adequadamente ao fazer o logout, permitindo que um invasor reutilize os tokens de sessão.

 • Uso de mecanismos de autenticação desatualizados: uso de algoritmos de criptografia fracos ou métodos de autenticação que tenham sido comprometidos.

Mitigações recomendadas

 • Use o armazenamento seguro fornecido pelo sistema operacional (por exemplo, Keychain no iOS, Keystore no Android).
 • Evite armazenar credenciais em texto simples ou em locais não seguros.
 • Criptografe todas as comunicações que contenham credenciais usando TLS/SSL.
 • Implemente HTTPS com configurações seguras e certificados válidos.
 • Invalidar tokens de sessão ao fazer logout.
 • Use tokens de sessão com tempos de expiração e revogação adequados.
 • Implementar mecanismos seguros de renovação de tokens.
 • Use a autenticação multifator (MFA) sempre que possível.
 • Empregue algoritmos de criptografia e hash fortes e atualizados.
 • Não reutilize credenciais em diferentes serviços ou aplicativos.


Exemplos de ataques

Armazenamento inseguro:

Um invasor com acesso físico ao dispositivo ou por meio de uma exploração pode acessar um arquivo de texto simples contendo credenciais armazenadas não criptografadas, obtendo assim acesso não autorizado ao aplicativo ou aos serviços associados.

Interceptação de tráfego:

Se um aplicativo transmitir credenciais por HTTP, um invasor que possa interceptar o tráfego de rede (por exemplo, por meio de um ataque man-in-the-middle) poderá capturar as credenciais e usá-las para acessar o aplicativo.

Sequestro de sessão:

Se os tokens de sessão não forem devidamente invalidados no logout, um invasor que obtiver um token válido (por exemplo, por meio de um ataque XSS) poderá reutilizá-lo para acessar a sessão do usuário sem precisar conhecer as credenciais do usuário.

Autenticação desatualizada:

O uso de algoritmos de hash fracos, como o MD5, para armazenar senhas pode permitir que um invasor que obtenha o banco de dados de senhas decifre as senhas com relativa facilidade usando força bruta ou ataques de dicionário.

Vulnerabilidade M2: segurança inadequada da cadeia de suprimentos

A vulnerabilidade M2, "Segurança inadequada da cadeia de suprimentos", refere-se aos riscos associados à cadeia de suprimentos de software no desenvolvimento de aplicativos móveis. Isso inclui o uso de componentes de terceiros, bibliotecas, estruturas e serviços externos que não são verificados ou mantidos adequadamente. A segurança de um aplicativo pode ser comprometida se qualquer um desses elementos contiver vulnerabilidades, for comprometido ou incluir intencionalmente código malicioso.

Indicadores de risco

 • Uso de bibliotecas obsoletas ou sem manutenção: integração de componentes de software que não recebem atualizações de segurança regulares.

 • Falta de verificação dos componentes: Não são realizadas verificações adequadas sobre a integridade e a autenticidade dos componentes de terceiros utilizados.

 • Falta de monitoramento contínuo: as vulnerabilidades dos componentes externos usados no aplicativo não são monitoradas ativamente.

 • Falta de políticas de segurança: falta de políticas e procedimentos claros para avaliar e gerenciar riscos na cadeia de suprimentos de software.


Mitigações recomendadas

 • Use assinaturas digitais e hashes para verificar a integridade e a autenticidade dos componentes de software.

 • Faça o download de componentes somente de fontes confiáveis e verificadas.

 • Mantenha atualizados todos os componentes de terceiros usados no aplicativo.

 • Monitore regularmente os bancos de dados de vulnerabilidade (como o NVD) para detectar problemas conhecidos nos componentes usados.

 • Realizar avaliações regulares de segurança e testes de penetração para identificar vulnerabilidades em componentes de terceiros.

 • Estabelecer um processo de avaliação e aprovação para a integração de novos componentes.

 • Implemente políticas de segurança claras que abordem a seleção, a avaliação e o uso de componentes de terceiros.

 • Promover uma cultura de segurança que valorize a importância de uma cadeia de suprimentos segura.


Exemplos de ataques

Injeção de código malicioso em bibliotecas:

Um invasor compromete uma biblioteca popular usada por muitos desenvolvedores. Os aplicativos que integram essa biblioteca sem verificar sua integridade podem incluir códigos maliciosos que permitem ao invasor executar códigos arbitrários nos dispositivos dos usuários.

Uso de componentes vulneráveis:

Um aplicativo usa uma versão desatualizada de uma biblioteca de criptografia que tem uma vulnerabilidade conhecida. Um invasor pode explorar essa vulnerabilidade para descriptografar dados confidenciais transmitidos ou armazenados pelo aplicativo.

Ataques à cadeia de suprimentos:

Um fornecedor de software terceirizado é comprometido, e o invasor injeta malware em uma atualização de software. Os desenvolvedores que integram essa atualização sem realizar as verificações adequadas podem, inadvertidamente, distribuir malware aos usuários finais.

Unidades não verificadas:

Um desenvolvedor inclui uma biblioteca de código aberto sem verificar sua origem ou histórico de segurança. A biblioteca contém um backdoor que permite que um invasor acesse remotamente o aplicativo e os dados do usuário.

Vulnerabilidade M3: autenticação/autorização insegura

A vulnerabilidade M3, "Autenticação/autorização insegura", refere-se a falhas nos mecanismos de autenticação e autorização de um aplicativo móvel. Isso inclui quaisquer pontos fracos na forma como os usuários se autenticam no aplicativo e como suas permissões e acesso a diferentes recursos dentro do aplicativo são tratados. As deficiências nesses mecanismos podem permitir que os invasores se façam passar por identidades, obtenham acesso não autorizado a recursos e dados ou aumentem os privilégios.

Indicadores de risco

 • Tokens de sessão que não expiram ou não são invalidados adequadamente quando o logout é feito.
 • Sessões que não são fechadas automaticamente após um período de inatividade.
 • Uso de senhas fáceis de adivinhar ou senhas sem requisitos mínimos de segurança.
 • Ausência de autenticação multifatorial (MFA).
 • Não limite o número de tentativas de login com falha.
 • Transmissão de credenciais não criptografadas.
 • Armazenamento de credenciais em texto simples no dispositivo.
 • Falta de controle adequado do acesso a recursos e funcionalidades.
 • Usuários que podem aumentar os privilégios devido a controles insuficientes.


Mitigações recomendadas

 • Implemente a autenticação multifator (MFA) para adicionar uma camada extra de segurança.

 • Exija senhas fortes e aplique políticas de alteração regular de senhas.

 • Limite o número de tentativas de login com falha e bloqueie temporariamente as contas após várias tentativas com falha.

 • Use tokens de sessão seguros e configure-os para expirar após um período de inatividade.

 • Certifique-se de que os tokens de sessão sejam invalidados corretamente ao fazer o logout.

 • Implemente cookies seguros com os sinalizadores HttpOnly e Secure para proteger os tokens de sessão.

 • Criptografe as credenciais durante a transmissão usando HTTPS.

 • Use o armazenamento seguro do sistema operacional (Keychain no iOS, Keystore no Android) para armazenar credenciais.

 • Implemente controles de acesso granular com base em funções e permissões.

 • Realize verificações de autorização no servidor para todas as operações confidenciais.

 • Evite depender exclusivamente de controles de autorização no lado do cliente.


Exemplos de ataques

Força bruta:

Um invasor tenta fazer login no aplicativo com várias combinações de nome de usuário e senha, aproveitando a falta de limitação de tentativas de login. Se o aplicativo não tiver proteção contra força bruta, o invasor poderá adivinhar as credenciais corretas.

Sequestro de sessão:

Se um aplicativo não invalidar corretamente os tokens de sessão ao fazer logout, um invasor que obtiver um token de sessão válido (por exemplo, por meio de um ataque XSS) poderá reutilizá-lo para obter acesso à conta do usuário.

Escalonamento de privilégios:

Um invasor com acesso a uma conta de usuário normal pode explorar falhas nos controles de autorização para obter acesso a funcionalidades ou dados reservados para administradores ou usuários com privilégios mais altos.

Ataques de phishing e man-in-the-middle:

Se as credenciais forem transmitidas sem criptografia, um invasor poderá interceptar as comunicações e capturar as credenciais usando um ataque man-in-the-middle. Ele também pode induzir os usuários a inserir suas credenciais em um site falso usando técnicas de phishing.

Vulnerabilidade M4: validação insuficiente de entrada/saída

A vulnerabilidade M4, "Insufficient Input/Output Validation" (Validação insuficiente de entrada/saída), refere-se à falha na validação adequada dos dados recebidos e enviados em um aplicativo móvel. Isso inclui a falha em validar ou sanitizar adequadamente os dados de entrada do usuário, as respostas da API, os dados recebidos de outros aplicativos ou os dados armazenados e processados internamente. Uma validação insuficiente pode permitir que os invasores injetem dados maliciosos, manipulem o comportamento do aplicativo e acessem dados confidenciais.

Indicadores de risco

 • Campos de formulário que aceitam qualquer tipo de dados sem restrições.

 • Nenhuma verificação de limites, formatos, tipos de dados ou caracteres permitidos é realizada nos dados inseridos pelo usuário.br>
 • Dados enviados ao navegador ou a outros aplicativos sem serem sanitizados, o que pode permitir a injeção de scripts ou comandos maliciosos.

 • Respostas de API que não são validadas antes de serem processadas pelo aplicativo.

 • Dados que são exibidos ao usuário sem serem filtrados ou sanitizados.

 • Falta de validação nas interações entre aplicativos.

 • Dados recebidos de outros aplicativos que não são validados antes do uso.


Mitigações recomendadas

 • Implemente validações robustas no lado do cliente e no lado do servidor para todas as entradas do usuário.

 • Use listas de permissões para definir tipos e formatos de dados permitidos.

 • Verificar limites, faixas e tamanhos dos dados inseridos.

 • Use bibliotecas e funções seguras para validar os dados de entrada.

 • Sanitizar todos os dados antes de exibi-los ao usuário ou enviá-los a outros aplicativos.

 • Escape corretamente os caracteres especiais para evitar injeções de scripts ou comandos.

 • Valide e higienize as respostas recebidas das APIs antes de processá-las ou exibi-las ao usuário.

 • Implemente controles de segurança adicionais para interações com APIs externas.

 • Valide os dados recebidos de outros aplicativos antes de usá-los.

 • Estabelecer protocolos de comunicação seguros e validar a autenticidade das fontes de dados.


Exemplos de ataques

Injeção de SQL:

Se um aplicativo não validar adequadamente os dados de entrada e permitir que um usuário insira dados maliciosos em um campo de formulário, um invasor poderá executar comandos SQL não autorizados que comprometam o banco de dados.

XSS (Cross-Site Scripting):

Se um aplicativo exibir dados inseridos pelo usuário sem higienizá-los, um invasor poderá injetar scripts mal-intencionados que serão executados no navegador do usuário, permitindo o roubo de cookies, credenciais e outros dados confidenciais.

Injeção de comando:

Se um aplicativo móvel permitir que os dados de entrada sejam passados diretamente para a linha de comando do sistema operacional sem validação, um invasor poderá executar comandos arbitrários no dispositivo.

Manipulação de dados da API:

Se um aplicativo não validar as respostas da API externa antes de processá-las, um invasor que controle a API ou intercepte as comunicações poderá enviar dados maliciosos que alterem o comportamento do aplicativo ou exponham dados confidenciais.


Vulnerabilidade M5: comunicação insegura

A vulnerabilidade M5, "Comunicação insegura", refere-se à falta de proteção adequada dos dados transmitidos entre o aplicativo móvel e seus servidores de back-end ou entre o aplicativo e outros serviços. Essa falta de proteção pode permitir que os invasores interceptem, modifiquem ou escutem os dados transmitidos. As comunicações inseguras podem expor dados confidenciais, como credenciais de usuário, informações pessoais ou dados financeiros, a possíveis invasores.

Indicadores de risco

 • Transmissão de dados via HTTP em vez de HTTPS.

 • Uso de versões desatualizadas e vulneráveis de protocolos de segurança (por exemplo, SSL 2.0/3.0, TLS 1.0/1.1).

 • Falha na validação adequada de certificados SSL/TLS.

 • Uso de certificados autoassinados sem mecanismos de validação adequados.

 • Envio ou recebimento de dados confidenciais sem criptografia.

 • Armazenamento temporário de dados de texto simples durante a transmissão.

 • Não implementação de medidas para detectar e impedir ataques Man-in-the-Middle.

 • Não utilização de mecanismos de garantia de identidade do servidor e do cliente.


Mitigações recomendadas

 • Use HTTPS em vez de HTTP para todas as comunicações.

 • Implemente versões modernas e seguras do TLS (como o TLS 1.2 ou o TLS 1.3).

 • Validar adequadamente os certificados SSL/TLS do servidor.

 • Use certificados emitidos por autoridades de certificação confiáveis.

 • Implemente a fixação de certificados para garantir que o aplicativo se comunique apenas com servidores confiáveis.

 • Criptografe todos os dados confidenciais em trânsito e em repouso.

 • Use algoritmos de criptografia fortes e atualizados (como o AES com um tamanho de chave apropriado).

 • Implemente a detecção de alterações de certificados e alertas sobre possíveis ataques Man-in-the-Middle.

 • Use técnicas como HSTS (HTTP Strict Transport Security) para forçar o uso de HTTPS.

 • Implemente a autenticação mútua (certificados do lado do cliente) para garantir que o cliente e o servidor possam verificar a identidade um do outro.


Exemplos de ataques

Interceptação de tráfego (sniffing):

Um invasor pode usar ferramentas como o Wireshark para interceptar o tráfego HTTP não criptografado e obter informações confidenciais, como nomes de usuário, senhas ou dados pessoais.

Ataques Man-in-the-Middle:

Um invasor pode interceptar a comunicação entre o aplicativo móvel e o servidor apresentando um certificado SSL falso. Se o aplicativo não validar os certificados corretamente, o invasor poderá descriptografar e modificar o tráfego à vontade.

Ataques de downgrade:

Um invasor pode forçar o aplicativo a usar versões antigas e vulneráveis de protocolos de segurança (como o SSL 3.0), expondo a comunicação a vulnerabilidades conhecidas.
Injeção de conteúdo malicioso:
Se a comunicação não for criptografada, um invasor poderá modificar os dados em trânsito, injetando comandos e scripts maliciosos ou redirecionando os usuários para sites de phishing.


Vulnerabilidade M6: controles de privacidade inadequados

A vulnerabilidade M6, "Controles de privacidade inadequados", refere-se à falta de medidas adequadas para proteger a privacidade dos dados pessoais dos usuários em aplicativos móveis. Isso pode incluir coleta excessiva de dados, armazenamento inseguro de dados pessoais, falta de consentimento adequado e falta de transparência sobre como os dados são tratados e compartilhados. Essa vulnerabilidade pode levar a violações de privacidade, exposição de dados confidenciais e possíveis problemas legais.

Indicadores de risco

 • O aplicativo solicita permissões para acessar mais informações do que o necessário para sua operação.

 • Coleta de dados confidenciais sem justificativa clara ou necessidade funcional.

 • O consentimento explícito do usuário não é solicitado antes que os dados pessoais sejam coletados e processados.

 • Termos de serviço e políticas de privacidade pouco claros ou difíceis de entender.

 • Armazenamento de dados pessoais sem criptografia.

 • Transmissão de dados pessoais sem o uso de conexões seguras (como HTTPS).

 • Os usuários não podem acessar, modificar ou excluir seus dados pessoais.

 • Falta de opções para os usuários limitarem a coleta de dados.

 • Dados pessoais compartilhados com terceiros sem informar adequadamente os usuários.

 • Não é especificado com quem os dados são compartilhados e para qual finalidade.

Mitigações recomendadas

 • Colete somente os dados necessários para a operação do aplicativo.

 • Avalie e justifique cada solicitação de permissão ou coleta de dados confidenciais.

 • Solicitar o consentimento explícito e específico dos usuários antes de coletar e processar seus dados pessoais.

 • Fornecer termos de serviço e políticas de privacidade claros, acessíveis e fáceis de entender.

 • Criptografar dados pessoais em repouso e em trânsito.

 • Use conexões seguras (como HTTPS) para a transmissão de dados.

 • Fornecer aos usuários opções para acessar, modificar e excluir seus dados pessoais.

 • Implemente controles de privacidade que permitam aos usuários limitar a coleta e o uso de seus dados.

 • Informe claramente os usuários sobre quais dados são coletados, como são usados e com quem são compartilhados.

 • Estabeleça e comunique políticas claras sobre o compartilhamento de dados com terceiros.


Exemplos de ataques

Exposição de dados confidenciais:

Um aplicativo que armazena dados pessoais sem criptografia pode ser explorado por um invasor que obtém acesso ao dispositivo ou ao banco de dados, expondo informações confidenciais, como nomes, endereços, números de telefone etc.

Falta de consentimento informado:

Um aplicativo que coleta dados de localização em segundo plano sem o consentimento explícito do usuário pode estar violando a privacidade do usuário, permitindo potencialmente o rastreamento e a vigilância não autorizados.

Interceptação de dados pessoais:

Se um aplicativo transmitir dados pessoais por meio de uma conexão não segura (HTTP em vez de HTTPS), um invasor que interceptar o tráfego poderá capturar informações confidenciais, como credenciais de login, dados financeiros etc.

Dados compartilhados de forma inadequada:

Um aplicativo que compartilha dados pessoais com terceiros sem informar adequadamente os usuários pode levar à exploração desses dados por anunciantes, corretores de dados ou até mesmo agentes mal-intencionados, comprometendo a privacidade do usuário.


Vulnerabilidade M7: proteções binárias insuficientes

A vulnerabilidade M7, "Proteções Binárias Insuficientes", refere-se à falta de medidas adequadas para proteger o código binário de um aplicativo móvel contra análise, manipulação e engenharia reversa. Essas proteções são essenciais para evitar que os invasores obtenham informações confidenciais, descubram vulnerabilidades no aplicativo ou modifiquem seu comportamento para realizar atividades mal-intencionadas.

Indicadores de risco

 • O código binário não é ofuscado, o que facilita a análise e a engenharia reversa.

 • Não há verificações de integridade implementadas para detectar modificações não autorizadas no código do aplicativo.

 • Ferramentas e configurações de depuração não desativadas na versão de produção do aplicativo.

 • Nenhuma técnica é usada para impedir o uso de ferramentas de análise e descompilação.

 • Informações confidenciais, como chaves de criptografia e credenciais, armazenadas diretamente no código binário.

Mitigações recomendadas

 • Usar ferramentas de ofuscação para tornar o código binário mais difícil de entender e analisar.

 • Ofusque o código nativo e o código Java/Kotlin em aplicativos Android e Swift/Objective-C em aplicativos iOS.

 • Implemente verificações de integridade em tempo de execução para detectar e responder a modificações não autorizadas no código.

 • Use hashes e assinaturas digitais para verificar a integridade dos binários.

 • Certifique-se de que as opções de depuração e as ferramentas de desenvolvimento estejam desativadas nas versões de produção do aplicativo.

 • Use técnicas como a antidepuração para detectar e impedir o uso de depuradores no aplicativo.

 • Use técnicas para dificultar o uso de ferramentas de análise e descompilação, como o empacotamento de código nativo e o uso de ambientes de execução seguros.

 • Implementar ambientes de detecção de emulador e análise estática.

 • Evite armazenar chaves de criptografia, credenciais e outras informações confidenciais diretamente no código binário.

 • Use o armazenamento seguro fornecido pelo sistema operacional (Keychain no iOS, Keystore no Android) para lidar com informações confidenciais.


Exemplos de ataques

Engenharia reversa:

Um invasor usa ferramentas como o Apktool para descompilar um aplicativo Android e analisar seu código. Sem as proteções adequadas, o invasor pode identificar vulnerabilidades, extrair informações confidenciais ou modificar o comportamento do aplicativo para seu próprio benefício.

Modificação de binários:

Um invasor modifica o código binário de um aplicativo para remover recursos de segurança, como verificações de autenticação, e redistribui o aplicativo modificado. Isso pode permitir o uso não autorizado do aplicativo ou a exploração de vulnerabilidades.

Extração de chaves de criptografia:

Un atacante analiza el código binario de una aplicación para extraer claves de cifrado almacenadas en texto plano. Con estas claves, el atacante puede descifrar datos sensibles, comprometiendo la privacidad y seguridad del usuario.

Uso de ferramentas de depuração:

Uso de ferramentas de depuração: Se um aplicativo não desativar as opções de depuração na versão de produção, um invasor poderá usar ferramentas de depuração para interceptar e modificar o fluxo de execução do aplicativo, permitindo a exploração de vulnerabilidades ou a manipulação de dados.


Vulnerabilidade M8: configuração incorreta da segurança

A vulnerabilidade M8, "Configuração incorreta da segurança", refere-se à configuração incorreta dos componentes de segurança em um aplicativo móvel ou em seu ambiente. Isso pode incluir configurações padrão inseguras, permissões excessivas, opções de depuração ativadas na produção e erros na configuração do servidor de back-end. As configurações incorretas podem permitir que os invasores explorem os pontos fracos do aplicativo, acessando dados confidenciais ou comprometendo sua operação.

Indicadores de risco

 • Uso de configurações padrão que não são seguras por padrão

 • Não altere as senhas padrão de bancos de dados, servidores ou serviços.

 • O aplicativo solicita mais permissões do que o necessário para sua operação.

 • O princípio do menor privilégio não se aplica às configurações de acesso.

 • Opções de depuração ou registros detalhados ativados na versão de produção.

 • Exposição de informações confidenciais por meio de registros detalhados ou mensagens de erro.

 • Servidores de back-end configurados sem HTTPS.

 • Não há configurações de segurança, como a Content Security Policy (CSP) ou a proteção contra ataques XSS.

 • Não manter os componentes do aplicativo e do servidor atualizados.

 • Uso de versões obsoletas e vulneráveis de bibliotecas ou estruturas.


Mitigações recomendadas

 • Revise e proteja todas as configurações padrão antes de implementar o aplicativo.

 • Altere as senhas padrão e proteja as configurações de acesso ao serviço.

 • Solicite apenas as permissões estritamente necessárias para a operação do aplicativo.

 • Aplique o princípio do menor privilégio em todas as configurações de acesso.

 • Certifique-se de que as opções de depuração e os registros detalhados estejam desativados na versão de produção.

 • Use registros apropriados que não exponham informações confidenciais.

 • Use HTTPS para todas as comunicações entre o aplicativo e os servidores.

 • Implementar políticas de segurança, como CSP, proteção XSS e validação de entrada.

 • Aplique atualizações e patches de segurança regularmente.

 • Use versões atualizadas e seguras de bibliotecas e estruturas.


Exemplos de ataques

Exploração de configurações padrão:

Um invasor pode obter acesso ao banco de dados de um aplicativo porque as senhas padrão não foram alteradas. Isso permite que o invasor acesse dados confidenciais armazenados no banco de dados.

Licenças excessivas:

Um aplicativo móvel que solicita permissões para acessar localização, contatos e câmera, sem necessidade funcional, expõe mais dados do usuário do que deveria. Um invasor que explora uma vulnerabilidade no aplicativo pode acessar esses dados excessivos.

Opções de depuração ativadas na produção:

Se um aplicativo tiver opções de depuração ativadas, um invasor poderá obter informações detalhadas sobre o funcionamento interno do aplicativo, incluindo possíveis pontos de entrada para explorações.

Falta de HTTPS nas comunicações:

Um aplicativo que se comunica com seu servidor backend via HTTP permite que um invasor execute um ataque man-in-the-middle para interceptar e manipular dados transmitidos, inclusive credenciais de usuário e outros dados confidenciais.

Atualizações e patches não aplicados:

Um aplicativo que usa uma biblioteca desatualizada e vulnerável pode ser explorado por um invasor para executar códigos maliciosos ou comprometer dados. As vulnerabilidades conhecidas podem ser facilmente exploradas se os patches de segurança disponíveis não forem aplicados.


Vulnerabilidade M9: armazenamento inseguro de dados

A vulnerabilidade M9, "Armazenamento inseguro de dados", refere-se à falta de medidas adequadas para proteger os dados armazenados em um dispositivo móvel. Essa vulnerabilidade pode permitir que os invasores acessem dados confidenciais, como credenciais de usuário, informações pessoais e dados financeiros, se conseguirem comprometer o dispositivo ou acessar seus arquivos de armazenamento.

Indicadores de risco

 • Dados confidenciais armazenados sem criptografia no armazenamento local do dispositivo.

 • Uso de APIs de armazenamento que não fornecem criptografia ou medidas de segurança adequadas.

 • Dados confidenciais registrados em arquivos de registro acessíveis.

 • Bancos de dados locais que não implementam criptografia para dados confidenciais armazenados.

 • Arquivos de dados confidenciais que não têm permissões de acesso restrito apropriadas.


Mitigações recomendadas

 • Use criptografia forte (como AES) para todos os dados confidenciais armazenados localmente.

 • Implemente a criptografia em repouso e em trânsito.

 • Use as APIs de armazenamento seguro fornecidas pelo sistema operacional (por exemplo, Keychain no iOS e Keystore no Android).

 • Evite usar armazenamento externo não seguro para dados confidenciais.

 • Armazene o mínimo possível de dados confidenciais localmente.

 • Considere se determinados dados precisam ser armazenados no dispositivo.

 • Evite registrar dados confidenciais em arquivos de registro.

 • Certifique-se de que os registros estejam protegidos e acessíveis somente a usuários autorizados.

 • Defina as permissões de arquivo apropriadas para restringir o acesso a dados confidenciais.

 • Use os mecanismos de controle de acesso do sistema operacional para proteger os arquivos.


Exemplos de ataques

Acesso a dados de texto simples:

Se um aplicativo armazenar as credenciais do usuário em texto simples no armazenamento local, um invasor que obtiver acesso físico ao dispositivo ou conseguir comprometê-lo por meio de malware poderá ler esses dados sem a necessidade de descriptografar nada.

Exploração de APIs de armazenamento inseguras:

Um aplicativo que usa uma API de armazenamento sem a criptografia adequada pode permitir que um invasor acesse facilmente os dados armazenados por meio de aplicativos maliciosos ou ferramentas de análise de dados.

Extração de dados de registro:

Se um aplicativo registrar dados confidenciais, como tokens de autenticação, em arquivos de log, um invasor com acesso a esses arquivos poderá roubar esses dados e comprometer as contas dos usuários.

Comprometimento de bancos de dados locais não criptografados:

Se um aplicativo armazenar informações pessoais em um banco de dados SQLite não criptografado, um invasor que obtiver acesso ao arquivo do banco de dados poderá ler todas as informações sem autenticação adicional.

Acesso a arquivos com permissões inadequadas:

Se os arquivos que contêm dados confidenciais tiverem permissões de acesso excessivamente amplas, eles poderão ser acessados por qualquer aplicativo ou usuário do dispositivo. Isso pode levar à exposição de informações críticas.

Vulnerabilidade M10: criptografia insuficiente

A vulnerabilidade M10, "Criptografia insuficiente", refere-se ao uso inadequado ou fraco de técnicas de criptografia em um aplicativo móvel para proteger dados confidenciais. Isso pode incluir o uso de algoritmos de criptografia fracos, implementação inadequada de criptografia e falha na proteção adequada de chaves e dados confidenciais. A implementação inadequada da criptografia pode permitir que os invasores acessem, modifiquem ou comprometam dados confidenciais, comprometendo a segurança do aplicativo e a privacidade dos usuários.

Indicadores de risco

 • Implementação de algoritmos de criptografia obsoletos ou fracos, como DES ou RC4.

 • Uso de chaves de criptografia fracas ou previsíveis, como senhas simples ou senhas derivadas de informações facilmente acessíveis.

 • Dados confidenciais armazenados ou transmitidos sem criptografia ou com criptografia insuficiente.

 • Armazenamento inseguro de chaves de criptografia, como armazená-las em texto simples ou armazenamento inseguro.

 • Implementação incorreta de protocolos de segurança, como SSL/TLS, que podem permitir ataques man-in-the-middle ou expor dados confidenciais.

Mitigações recomendadas

 • Use algoritmos de criptografia modernos e seguros, como o AES, para proteger dados confidenciais.

 • Evite algoritmos obsoletos ou considerados fracos.

 • Gerar chaves de criptografia fortes e aleatórias usando funções criptográficas seguras.

 • Evite usar senhas ou padrões previsíveis para a geração de chaves.

 • Criptografe todos os dados confidenciais, tanto em repouso quanto em trânsito, usando algoritmos de criptografia fortes.

 • Use bibliotecas criptográficas confiáveis e bem testadas para implementar a criptografia.

 • Armazene chaves de criptografia de forma segura usando mecanismos como o Keychain no iOS ou o Keystore no Android.

 • Evite armazenar chaves em texto simples ou em locais acessíveis a aplicativos não autorizados.

 • Configurar e usar protocolos de segurança, como SSL/TLS, de forma adequada e segura.

 • Ative as opções de configuração segura, como criptografia de ponta a ponta e validação de certificado, para proteger as comunicações.


Exemplos de ataques

Ataques de força bruta em chaves fracas:

Um invasor pode realizar um ataque de força bruta contra uma chave de criptografia fraca ou previsível para descriptografar dados confidenciais armazenados ou transmitidos pelo aplicativo.

Ataques de dicionário a senhas mal protegidas:

Se um aplicativo armazenar senhas de usuários usando criptografia fraca ou sem a proteção adequada, um invasor poderá usar um ataque de dicionário para decifrar as senhas e obter acesso não autorizado às contas de usuários.

Ataques Man-in-the-Middle em comunicações não seguras:

Se um aplicativo transmitir dados confidenciais sem criptografia ou com criptografia fraca, um invasor que interceptar a comunicação poderá ler e modificar os dados, comprometendo a confidencialidade e a integridade das informações.

Exploração de chaves de criptografia armazenadas desprotegidas:

Se as chaves de criptografia forem armazenadas de forma insegura, como em texto simples em um arquivo de configuração, um invasor que obtenha acesso a essas chaves poderá descriptografar dados confidenciais armazenados ou transmitidos pelo aplicativo.

Exploração de protocolos de segurança mal configurados:

Se um aplicativo usar protocolos de segurança, como SSL/TLS, de forma incorreta ou insegura, um invasor poderá explorar os pontos fracos da configuração para realizar ataques man-in-the-middle e comprometer as comunicações.

Conclusão

Essas vulnerabilidades representam uma ampla gama de riscos de segurança que podem afetar os aplicativos móveis. Desde problemas fundamentais, como o manuseio inadequado de credenciais e a falta de autenticação, até falhas críticas no armazenamento e na transmissão de dados confidenciais, essas vulnerabilidades comprometem a privacidade, a integridade e a segurança dos aplicativos móveis e dos dados do usuário.

Para lidar efetivamente com essas vulnerabilidades, é fundamental implementar uma combinação de medidas de segurança técnica e processos de desenvolvimento seguros. Isso inclui a adoção de boas práticas de criptografia, o uso adequado de criptografia e autenticação, a implementação de controles de acesso adequados, testes de segurança completos e treinamento da equipe em questões de segurança.

Ao adotar medidas proativas para identificar, corrigir e atenuar essas vulnerabilidades, as organizações podem melhorar significativamente a segurança de seus aplicativos móveis, protegendo assim os usuários e os dados confidenciais. A conscientização contínua sobre as ameaças à segurança móvel e o compromisso com as práticas recomendadas de segurança são essenciais para garantir uma experiência móvel segura e confiável para todos os usuários.