Skip to content

Proteção da Privacidade do Usuário em Aplicativos Móveis

Visão Geral

AVISO IMPORTANTE: O MASTG não é um manual jurídico e não abordará os detalhes específicos do GDPR ou de outras legislações possivelmente relevantes aqui. Em vez disso, este capítulo apresentará os tópicos relacionados à proteção da privacidade do usuário, fornecerá referências essenciais para suas próprias pesquisas e oferecerá testes ou diretrizes que determinam se um aplicativo adere aos requisitos relacionados à privacidade listados no OWASP MASVS.

O Problema Principal

Aplicativos móveis lidam com todos os tipos de dados sensíveis do usuário, desde informações de identificação e bancárias até dados de saúde, portanto, tanto os desenvolvedores quanto o público estão compreensivelmente preocupados com a forma como esses dados são tratados e onde acabam. Também vale a pena discutir os "benefícios que os usuários obtêm ao usar os aplicativos" versus "o preço real que estão pagando por isso" (muitas vezes sem nem mesmo ter consciência disso).

A Solução (pré-2020)

Para garantir que os usuários estejam adequadamente protegidos, legislações como o General Data Protection Regulation (GDPR) da União Europeia foram desenvolvidas e implementadas (aplicável desde 25 de maio de 2018). Essas leis podem forçar os desenvolvedores a serem mais transparentes em relação ao tratamento de dados sensíveis do usuário, o que geralmente é implementado por meio de políticas de privacidade.

O Desafio

Considere estas dimensões da privacidade em aplicativos móveis:

  • Developer Compliance: Os desenvolvedores precisam estar cientes das leis sobre privacidade do usuário para que seu trabalho esteja em conformidade. Idealmente, os seguintes princípios devem ser seguidos:
    • Abordagem de Privacy-by-Design (Art. 25 GDPR, "Proteção de dados desde a concepção e por padrão").
    • Principle of Least Privilege ("Cada programa e cada usuário do sistema deve operar usando o menor conjunto de privilégios necessário para concluir o trabalho.").
  • User Education: Os usuários precisam ser educados sobre seus dados sensíveis e informados sobre como usar o aplicativo corretamente (para garantir o manuseio e processamento seguros de suas informações).

Nota: Na maioria das vezes, os aplicativos afirmam lidar com determinados dados, mas na realidade não é o caso. O artigo da IEEE "Engineering Privacy in Smartphone Apps: A Technical Guideline Catalog for App Developers" de Majid Hatamian oferece uma introdução muito boa a este tópico.

Objetivos para a Proteção de Dados

Quando um aplicativo solicita informações pessoais de um usuário, o usuário precisa saber por que o aplicativo precisa desses dados e como eles são usados pelo aplicativo. Se houver um terceiro realizando o processamento real dos dados, o aplicativo também deve informar o usuário sobre isso.

Assim como a tríade clássica de objetivos de proteção de segurança: confidencialidade, integridade e disponibilidade, existem três objetivos de proteção propostos para a proteção de dados:

  • Unlinkability:
    • Os dados relevantes para a privacidade dos usuários não podem ser vinculados a qualquer outro conjunto de dados relevantes para a privacidade fora do domínio.
    • Inclui: minimização de dados, anonimização, pseudonimização, etc.
  • Transparency:
    • Os usuários devem saber como solicitar todas as informações que o aplicativo possui sobre eles e estar cientes de todas as informações que o aplicativo possui sobre eles.
    • Inclui: políticas de privacidade, educação do usuário, mecanismos adequados de registro e auditoria, etc.
  • Intervenability:
    • Os usuários devem saber como corrigir suas informações pessoais, solicitar sua exclusão, retirar qualquer consentimento dado a qualquer momento e receber instruções sobre como fazê-lo.
    • Inclui: configurações de privacidade diretamente no aplicativo, pontos únicos de contato para solicitações de intervenção de indivíduos (por exemplo, chat no aplicativo, número de telefone, e-mail), etc.

Para mais detalhes, consulte a Seção 5.1.1 "Introdução aos objetivos de proteção de dados" no documento da ENISA "Privacidade e proteção de dados em aplicações móveis".

Como é muito desafiador (se não impossível em muitos casos) abordar tanto os objetivos de segurança quanto os de privacidade ao mesmo tempo, vale a pena examinar uma visualização na publicação da IEEE Protection Goals for Privacy Engineering chamada "The Three Axes" que nos ajuda a entender por que não podemos atingir 100% de cada um dos seis objetivos simultaneamente.

Embora uma política de privacidade tradicionalmente proteja a maioria desses processos, essa abordagem nem sempre é ideal porque:

  • Os desenvolvedores não são especialistas jurídicos, mas ainda precisam estar em conformidade com a legislação.
  • Os usuários quase sempre precisam ler políticas longas e verbosas.

A Nova Abordagem (Google e Apple)

Para enfrentar esses desafios e informar melhor os usuários, Google e Apple introduziram novos sistemas de rotulagem de privacidade (muito alinhados com a proposta do NIST) para ajudar os usuários a entender facilmente como seus dados estão sendo coletados, tratados e compartilhados, Consumer Software Cybersecurity Labeling. Suas abordagens podem ser vistas em:

Como este é um novo requisito em ambas as plataformas, esses rótulos devem ser precisos para tranquilizar os usuários e mitigar abusos.

Google ADA MASA Program

Como os testes de segurança regulares ajudam os desenvolvedores a identificar vulnerabilidades-chave em seus aplicativos, o Google Play permitirá que desenvolvedores que tenham concluído uma validação de segurança independente informem os usuários divulgando esse fato na seção de Data Safety do aplicativo. O compromisso do desenvolvedor com a segurança e a privacidade visa tranquilizar os usuários.

Como parte do processo para fornecer mais transparência na arquitetura de segurança do aplicativo, o Google introduziu o programa MASA (Mobile Application Security Assessment) como parte da App Defense Alliance (ADA). Como o MASA é um padrão globalmente reconhecido para segurança de aplicativos móveis no ecossistema de aplicativos móveis, o Google está reconhecendo a importância da segurança neste setor. Os desenvolvedores podem trabalhar diretamente com um parceiro Laboratório Autorizado para iniciar uma avaliação de segurança que é validada independentemente contra um conjunto de requisitos do MASVS Level 1, e o Google reconhecerá esse esforço permitindo que eles divulguem esses testes na seção de Data Safety do aplicativo.

Se você é um desenvolvedor e gostaria de participar, preencha o Independent Security Review form.

É claro que o teste é limitado e não garante a segurança completa do aplicativo. A revisão independente pode não ter como escopo verificar a precisão e integridade das declarações de Data Safety de um desenvolvedor, e os desenvolvedores permanecem exclusivamente responsáveis por fazer declarações completas e precisas na listagem de sua Play Store.

Referências

Você pode aprender mais sobre este e outros tópicos relacionados à privacidade aqui:

Testando a Privacidade em Aplicativos Móveis

Testadores de segurança devem estar cientes da lista do Google Play de violações comuns de privacidade, embora não seja exaustiva. Alguns dos exemplos estão abaixo:

  • Exemplo 1: Um aplicativo que acessa o inventário de aplicativos instalados de um usuário e não trata esses dados como dados pessoais ou sensíveis, enviando-os pela rede (violando o MSTG-STORAGE-4) ou para outro aplicativo por meio de mecanismos de IPC (violando o MSTG-STORAGE-6).
  • Exemplo 2: Um aplicativo exibe dados sensíveis, como detalhes de cartão de crédito ou senhas de usuário, sem autorização do usuário, por exemplo, biometria (violando o MSTG-AUTH-10).
  • Exemplo 3: Um aplicativo que acessa dados do telefone ou da lista de contatos de um usuário e não trata esses dados como dados pessoais ou sensíveis, além de enviá-los por uma conexão de rede não segura (violando o MSTG-NETWORK-1).
  • Exemplo 4: Um aplicativo coleta a localização do dispositivo (o que aparentemente não é necessário para seu funcionamento adequado) e não possui uma divulgação proeminente explicando qual recurso usa esses dados (violando o MSTG-PLATFORM-1).

Você pode encontrar mais violações comuns no Google Play Console Help indo para Policy Centre -> Privacy, deception and device abuse -> User data.

Como você pode esperar, essas categorias de teste estão relacionadas entre si. Ao testá-las, você frequentemente está testando indiretamente a proteção da User Privacy Protection. Esse fato permitirá que você forneça relatórios melhores e mais abrangentes. Muitas vezes, você poderá reutilizar evidências de outros testes para testar a User Privacy Protection.

Testando a Divulgação da Privacidade de Dados no App Marketplace

Este documento está interessado apenas em determinar quais informações relacionadas à privacidade estão sendo divulgadas pelos desenvolvedores e discutir como avaliar essas informações para decidir se parecem razoáveis (da mesma forma que você faria ao testar permissões).

Embora seja possível que os desenvolvedores não estejam declarando certas informações que de fato estão sendo coletadas e/ou compartilhadas, esse é um tópico para um teste diferente. Neste teste, você não deve fornecer garantia de violação de privacidade.

Static Analysis

Para realizar uma análise estática, siga estas etapas:

  1. Pesquise o aplicativo na loja de aplicativos correspondente (por exemplo, Google Play, App Store).
  2. Vá para a seção "Privacy Details" (App Store) ou "Safety Section" (Google Play).
  3. Determine se há alguma informação disponível.

O aplicativo passa no teste desde que o desenvolvedor tenha cumprido as diretrizes da loja de aplicativos e incluído os rótulos e explicações necessários. As divulgações do desenvolvedor na loja de aplicativos devem ser armazenadas como evidência, para que você possa usá-las posteriormente para determinar possíveis violações de privacidade ou proteção de dados.

Dynamic Analysis

Como uma etapa opcional, você também pode fornecer algum tipo de evidência como parte deste teste. Por exemplo, se você estiver testando um aplicativo iOS, pode facilmente ativar a gravação de atividade do aplicativo e exportar um Privacy Report que contém acesso detalhado do aplicativo a diferentes recursos, como fotos, contatos, câmera, microfone, conexões de rede, etc.

Uma análise dinâmica tem muitas vantagens para testar outras categorias do MASVS e fornece informações muito úteis que você pode usar para testar a comunicação de rede para o MASVS-NETWORK ou ao testar a interação do aplicativo com a plataforma para o MASVS-PLATFORM. Ao testar essas outras categorias, você pode ter feito medições semelhantes usando outras ferramentas de teste. Você também pode fornecer isso como evidência para este teste.

Embora as informações disponíveis devam ser comparadas com o que o aplicativo realmente deve fazer, esta será uma tarefa longe de trivial que pode levar de vários dias a semanas para ser concluída, dependendo de seus recursos e das capacidades de suas ferramentas automatizadas. Esses testes também dependem muito da funcionalidade e do contexto do aplicativo e devem ser idealmente realizados em uma configuração de white box trabalhando muito de perto com os desenvolvedores do aplicativo.

Testando a Educação do Usuário sobre Melhores Práticas de Segurança

Determinar se o aplicativo educa os usuários e os ajuda a entender as necessidades de segurança é especialmente desafiador se você pretende automatizar o processo. Recomendamos usar o aplicativo extensivamente e tentar responder às seguintes perguntas sempre que aplicável:

  • Fingerprint usage: Quando as fingerprints são usadas para autenticação, fornecendo acesso a transações/informações de alto risco,

    o aplicativo informa o usuário sobre possíveis problemas ao ter várias fingerprints de outras pessoas registradas no dispositivo também?

  • Rooting/jailbreaking: Quando a detecção de root ou jailbreak é implementada,

    o aplicativo informa o usuário sobre o fato de que certas ações de alto risco acarretarão risco adicional devido ao status de jailbroken/rooted do dispositivo?

  • Specific credentials: Quando um usuário recebe um código de recuperação, uma senha ou um PIN do aplicativo (ou define um),

    o aplicativo instrui o usuário a nunca compartilhá-lo com mais ninguém e que apenas o aplicativo o solicitará?

  • Application distribution: No caso de um aplicativo de alto risco e para evitar que os usuários baixem versões comprometidas do aplicativo,

    o fabricante do aplicativo comunica adequadamente a maneira oficial de distribuir o aplicativo (por exemplo, pelo Google Play ou pela App Store)?

  • Prominent Disclosure: Em qualquer caso,

    o aplicativo exibe divulgação proeminente de acesso, coleta, uso e compartilhamento de dados? por exemplo, o aplicativo usa o App Tracking Transparency Framework para solicitar permissão no iOS?

Outras referências incluem: