Segurança de Aplicativos Android

Seguranรงa de Aplicativos

Android Jeff Six

Novatec

Authorized Portuguese translation of the English edition of titled Application Security for the Android Plataform, First Edition ISBN 9781449315078 © 2012 Jeff Six. This translation is published and sold by permission of O'Reilly Media, Inc., the owner of all rights to publish and sell the same.

Tradução em português autorizada da edição em inglês da obra Application Security for the Android Plataform, First Edition ISBN 9781449315078 © 2012 Jeff Six. Esta tradução é publicada e vendida com a permissão da O'Reilly Media, Inc., detentora de todos os direitos para publicação e venda desta obra. © Novatec Editora Ltda. 2012.

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora.

Editor: Rubens Prates Tradução: Eduardo Kraszczuk Revisão técnica: João Paulo Lemos Escola Revisão gramatical: Patrizia Zagni Editoração eletrônica: Carolina Kuwabata ISBN: 978-85-7522-313-0 Histórico de impressões: Junho/2012

Primeira edição

Novatec Editora Ltda.

Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 Fax: +55 11 2950-8869 Email: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

Dados

Internacionais de Catalogação na Publicação (Câmara Brasileira do Livro, SP, Brasil) Six, Jeff Segurança de aplicativos Android / Jeff Six ; [tradução Eduardo Kraszczuk].

-- São Paulo : Novatec Editora ; Sebastopol, CA : O'Reilly, 2012.

Título original: Application security for the Android Platform.

ISBN 978-85-7522-313-0 1. Android (Programa de computador) - Medidas de segurança 2. Aplicação de programas Desenvolvimento 3. Computação móvel I. Título.

12-06640

CDD-005.26 Índices para catálogo sistemático: 1. Android : Plataforma de desenvolvimento para aplicativos móveis : Programa de computador 005.26

(CIP)

capítulo 1

Introdução

Bem-vindo, desenvolvedor! Este livro é para você: desenvolvedor de software que escreve para a plataforma móvel Android. Aqui, você aprenderá o que precisa saber sobre o mundo da segurança de aplicativos e a interação entre desenvolvimento de software e segurança da informação. No mundo de hoje, conhecimento sobre segurança de aplicativos é algo que pode diferenciar desenvolvedores.

Goste ou não, você irá entregar aplicativos em um ambiente muito ameaçador.

Embora a plataforma Android ainda seja bastante nova e ofereça grandes oportunidades, também é atacada rotineiramente por hackers maliciosos que querem comprometer aplicativos móveis – seus aplicativos móveis – para ganho próprio (note que não queremos dizer que o Android seja atacado mais do que outros sistemas, como navegadores web, formatos de documentos etc.; qualquer plataforma com um número razoável de usuários é um alvo hoje em dia, e o Android com certeza também é). Este livro irá ensinar a você o básico de como projetar e implementar aplicativos seguros e robustos para a plataforma Android. Também irá ensinar como hackers maliciosos podem ver seu aplicativo e como podem escolher atacá-lo, informação que você pode usar bem quando projetar e implementar seu app.

Como notado, o público deste livro são desenvolvedores que já estejam desenvolvendo para a plataforma móvel Android ou que planejam fazê-lo. O livro supõe que você tenha um conhecimento razoável do ambiente Android, inclusive como projetar, construir e implantar aplicativos. Entretanto, não supõe nenhum background em segurança de aplicativos, criptografia ou desenvolvimento de software seguro. O que você, como desenvolvedor, precisa saber sobre esses tópicos é exatamente o que este livro tem o objetivo de proporcionar.

Este livro existe para dar as informações de que você precisa – nem mais, nem menos – para efetivamente desenvolver nesse ambiente.

15

16

Segurança de aplicativos Android

Finalmente, antes de começarmos – obrigado. Obrigado por se interessar em segurança de aplicativos e em se esforçar para melhorar seu conhecimento de como criar aplicativos seguros e robustos. O único meio de o estado atual de aplicativos vulneráveis e constantemente explorados ser alterado é se os desenvolvedores virem a necessidade de estabelecer práticas e conhecimento de desenvolvimento mais seguro e se ganharem com esse conhecimento. Bem-vindo a essa jornada!

Segurança de aplicativos: por que você deveria se importar com isso?

Segurança... Por que você, como desenvolvedor, deveria se importar? No contexto da tecnologia da informação, segurança se refere a itens como firewalls, sistemas de detecção de intrusão, programas antivírus etc. Certamente alguém que escreve aplicativos de objetivo geral, como jogos, apps de calendarização e ferramentas de manipulação de fotos, não precisa se preocupar com segurança, certo? Errado!

Imagine que você escreve apps para ajudar pessoas ocupadas a gerenciar suas agendas e que você tire proveito de serviços de computação em nuvem para tornar a informação disponível a seus clientes em seus smartphones e tablets Android onde quer que eles estejam. Esse é um serviço muito útil e muitas das pessoas que o aproveitariam seriam aquelas muito ocupadas: executivos de serviços financeiros, por exemplo. Seu app decola e tem ampla adoção. Então, um executivo ocupado está conversando com um amigo de outra empresa em uma conferência e deixa escapar que sua empresa tem lido a agenda do executivo. Eles puderam ver com quem esse executivo se reuniu, em que acordos em potencial a empresa estava trabalhando e outras informações confidenciais.

Depois de alguma investigação, o executivo descobre que seu app de calendarização é vulnerável ao que no campo de segurança de aplicativo é chamado vulnerabilidade de injeção de comando, e um engenheiro inescrupuloso na empresa de seu concorrente descobriu e estava usando isso para atacar os dispositivos móveis da concorrência para obter informações sensíveis.

Vamos considerar outra situação: você escreve um app realmente legal que permite às pessoas acessar muitas de suas contas em redes sociais, todas em um só lugar. Os usuários são capazes de ver atualizações de suas conexões no Facebook, Google+, Twitter e em quaisquer outras redes sociais e serviços que surjam em um futuro próximo, tudo em um só lugar. Os usuários adoram essa

Capítulo 1 ■ Introdução

17

ferramenta e a usam o tempo todo. Tudo vai indo bem até que, numa manhã, você recebe um e-mail de um usuário que reclama que todos os detalhes de suas contas em redes sociais, incluindo suas senhas, foram publicados em um site hospedado em um servidor na Europa oriental. Você verifica o site e, realmente, detalhes de milhares de usuários foram publicados. Ao examinar seus registros contábeis, você verifica que eles são todos usuários de seu app de integração. O e-mail seguinte que você recebe confirma seus medos. É do hacker que roubou esses dados. Ele revela que escondeu um trecho de código em um app Android que ele liberou e que parecia, para instâncias de base de dados não protegidas, com o que seu app usou e recolheu todos os dados.

Agora, se você não quiser que ele libere toda essa informação publicamente, uma grande “taxa de proteção” será necessária.

De quem é a culpa nessas situações? Sua! Você não avaliou completamente o ambiente no qual os aplicativos móveis são executados. Já se foram os dias em que você podia lançar código inseguro e mal desenvolvido e ninguém se importava. Agora você está liberando seu código no que chamamos de ambiente de alto risco, mais comumente conhecido como internet. Seu software está sendo executado em um dispositivo que tem uma conexão constante com a internet e executa seu código em conjunto com centenas de outros apps, todos de diferentes autores, alguns dos quais são anônimos. Você não levou em conta que dados inesperados viessem da rede no primeiro exemplo e, no segundo, não protegeu corretamente os dados sensíveis de outros aplicativos que estava armazenando no dispositivo.

Anonimato completo do desenvolvedor não é totalmente possível, já que qualquer um que envia aplicativos para o Android Market precisa fornecer um cartão de crédito válido e informações de identidade correspondentes como parte do processo de registro. Então, há algum grau de segurança nesse caso. Entretanto, uma vez que é possível – muito fácil, de fato – permitir a instalação de aplicativos de outras fontes (e existem muitas fontes não oficiais de aplicativos por aí) em dispositivos Android, essa propriedade de identidade só se aplica a aplicativos obtidos na fonte oficial, o Android Market.

Então, quem precisa se preocupar em codificar corretamente seus aplicativos para resistir a tais ameaças? Fácil: qualquer um que esteja codificando qualquer aplicativo. Todos os desenvolvedores precisam ter uma compreensão básica de segurança do aplicativo. Você precisa entender por que é importante restringir o acesso a certos componentes de seu aplicativo, como sua base de dados. Você precisa entender o que é criptografia e como pode usar diferentes funções

18

Segurança de aplicativos Android

criptográficas para fornecer proteções apropriadas aos dados que seu app está armazenando e processando. Você precisa entender como funciona o ambiente Android e como os apps podem ser escritos para serem seguros e robustos. Para sua felicidade, todos esses tópicos serão discutidos neste livro. Vamos atualizar você sobre o que precisa saber como desenvolvedor. Seu código e a proteção que você está oferecendo aos dados de seus clientes serão muito melhores.

Estado atual da segurança de aplicativos móveis no Android No final de 2011, o ecossistema Android teve muito a seu favor. Os telefones Android são extremamente populares e novos modelos parecem ser lançados em poucos dias. Existem milhares de apps no Android Market e o modelo de desenvolvimento baseado em Java é atraente para muitos desenvolvedores.

O Google continua a inovar nessa plataforma a passos largos. Na verdade, o Android 4.0 Ice Cream Sandwich já deverá estar disponível quando este livro for publicado1. Isso deve resolver as incompatibilidades atuais entre as versões para telefone e tablet.

Entretanto, nem tudo está bem no mundo do Android. Análises recentes de empresas contratadas encontraram diversos tipos de malwares embutidos em apps lançados no Android Market. Muito mais malwares foram encontrados em lojas de aplicativos que não são da Google. Enganando o usuário para que ele instale o aplicativo e fingindo ser uma ferramenta útil ou jogo, o software rouba dados do telefone e os envia a pessoas desconhecidas com motivações obscuras.

Alguns exemplos de apps Android maliciosos, descobertos e removidos do Market, são: • Super Guitar Solo; • Photo Editor; • Advanced Currency Converter; • Spider Man; • Hot Sexy Videos.

Essas pessoas tentarão fazer seu código malicioso se parecer com todas as variedades de apps legítimos para usuários desavisados os instalarem e executarem. Todos esses exemplos encontravam-se disponíveis no Android Market 1 N.T.: o Android 4.0 Ice Cream Sandwich foi lançado oficialmente para o público em outubro de 2011.

Capítulo 1 ■ Introdução

19

e foram baixados por muitos usuários antes de serem removidos. Na verdade, essa imitação de aplicativos e funções legítimas também não é exclusiva do Android Market; é uma característica de qualquer sistema de larga escala.

O Android foi projetado a partir do zero com um modelo de segurança robusto.

Contudo, será que esse modelo foi efetivo em mitigar esse tipo de ameaça? O fato de esse malware existir indica que o modelo não foi, nem poderia realmente ser, uma panaceia para a segurança da plataforma. Embora essa ameaça continue a existir, a abordagem sandbox2/permissões proporcionou alguns resultados satisfatórios. Inicialmente, reduz o escopo de funcionalidade para a maioria das aplicações (diminuindo as possibilidades de ataque do malware caso este seja executado em um dispositivo). O modelo de permissões também dá aos usuários melhores informações sobre o comportamento real dos aplicativos que eles estão instalando, e combinado com avaliações e feedbacks dos usuários por meio do Android Market (e outras fontes), os usuários podem pesquisar para detectar aplicativos maliciosos. Finalmente, malwares que têm sido vistos são mais limitados no seu escopo do que os que existem em outras plataformas (embora alguns malwares realmente explorem vulnerabilidades no próprio sistema Android para obter acesso ao nível de root e fazer coisas realmente desagradáveis). Dessa forma, embora a ameaça do malware no Android seja real e continuará a ser, o modelo de segurança, composto de permissionamentos e outros construtos3, fornece alguns benefícios reais e proteções aos usuários.

Além desses problemas específicos da plataforma Android, parece que a cada dia temos mais notícias relacionadas a comprometimento de dados privativos, com grupos de hackers liberando arquivos roubados e grandes companhias de segurança anunciando que descobriram invasões em grande número de corporações como forma de espionagem industrial (roubo de segredos corporativos). Agora, vamos observar que essas ações ocorreram contra sistemas de computadores em geral. Comprometimentos de dados em larga escala como este não foram vistos na plataforma Android. Embora a indústria de segurança de computadores tenha avançado muito em seu curto tempo de vida, as coisas claramente não estão funcionando muito bem e a necessidade dos desenvolvedores de liberar softwares menos vulneráveis é muito clara.

2 N.T.: um sandbox é um mecanismo de segurança para separar programas que estão sendo executados. Muitas vezes, é usado para exeutar códigos não testados, ou programas não confiáveis de terceiros, fornecedores ou websites não confiáveis (fonte: Wikipédia) 3 N.T.: construto é um elemento não tangível, criado para realizar uma determinada função (a rigor, tudo em programação são construtos, já que nenhum deles existe fisicamente).

20

Segurança de aplicativos Android

Segurança: risco = vulnerabilidade + ameaça + consequências Segurança trata de gerenciar riscos. Você nunca terá um sistema de segurança perfeito. As declarações mais honestas já feitas sobre estar 100% certo de que seus dados estão seguros são conhecidas como a “Lei de Richards de segurança de computadores”, que data de 19924.

A primeira lei: não compre um computador. A segunda lei: se você comprar um computador, não o ligue. Esses são conselhos muito úteis e práticos, não?

Falando sério, segurança de aplicativo trata de trocas. Pense de novo no exemplo discutido na seção anterior, que fala de um app de integração de redes sociais.

Se precisarmos de garantia perfeita, uma garantia de 100%, de que os nomes de usuários e senhas não serão comprometidos, o único meio de realizar isso seria não armazená-los de forma alguma. Entretanto, tal ação tornaria impraticável todo o conceito de seu aplicativo. Precisamos assumir algum risco para fornecer quaisquer serviços úteis.

Compare isto a um exemplo do mundo real. Cartões de crédito podem ser roubados, e se seu cartão for roubado e usado pelo ladrão, você poderá precisar passar por alguns processos demorados e irritantes para recuperá-lo. Quando você entrega seu cartão de crédito ao garçom de um restaurante para pagar a conta, há uma chance de ele passá-lo em um dispositivo de cópia na cozinha que lhe permita clonar esse cartão e usá-lo fraudulentamente. O único modo de impedir que esse ataque ocorra, com 100% de certeza, é nunca usar seus cartões de crédito de nenhum modo que você os perca de vista (de fato, é assim que os pagamentos ocorrem na Europa, onde os garçons trazem a máquina leitora de cartões a sua mesa... Mas você conseguiria identificar uma copiadora de cartões ligada à leitora?). Você sempre corre algum risco quando entrega o cartão, entretanto não precisa levar dinheiro para pagar uma refeição. Você obtém alguns pontos de fidelidade de sua companhia de cartão e um extrato detalhado de suas compras todos os meses. Na sociedade moderna, a maioria das pessoas decidiu que essas recompensas superam os riscos e estão dispostas a entregar seu cartão de crédito.

Como essa decisão é tomada? Como sabemos se a recompensa vale o risco?

A primeira coisa que precisamos entender é o que é risco. Existem três componentes primários do risco: vulnerabilidade, ameaça e consequências. Vamos examinar cada um separadamente para ver de onde vem o risco.

4 Fonte: http://virusbusters.itcs.umich.edu/um- resources/vb-interview.html

Capítulo 1 ■ Introdução

21

Vulnerabilidade permite que uma ação não intencional e indesejada tenha lugar. No nosso exemplo do cartão de crédito, a vulnerabilidade é que não vemos nosso cartão de crédito o tempo todo nem temos controle sobre o que acontece com ele nesse ponto (alguém pode também observar que ter um método de identificação universalmente autenticado, como um número de cartão de crédito, é também uma vulnerabilidade nesse cenário. Por que saber o número do cartão de crédito é aceito como prova suficiente de que você é o dono do cartão?). A ampla disponibilidade de copiadoras de cartões também é um componente da vulnerabilidade. Se o cartão não pudesse ser duplicado de modo rápido e fácil, a situação seria menos preocupante.

Ameaça é o segundo componente do risco. Uma ameaça é algo, ou alguém, que pode obter vantagens de uma vulnerabilidade. Nesse caso, a ameaça é um garçom que pega o cartão e o clona, usando-o para fazer compras fraudulentas. Aqui, podemos julgar que a ameaça é provavelmente baixa. A maioria dos garçons são pessoas honestas e trabalhadoras, então a ameaça, neste caso, é muito menor do que poderia ser se estivéssemos usando o cartão para comprar aparelhos eletrônicos roubados em vez de uma refeição, uma vez que é mais provável que um indivíduo que venda bens roubados roube também as informações de seu cartão. Assim, nesta situação, mesmo a vulnerabilidade sendo alta, a ameaça não é particularmente alta.

O terceiro componente do risco é a consequência. Isso se refere ao que poderia ocorrer se quaisquer dessas coisas ruins que estamos considerando realmente acontecessem. Se entregarmos nosso cartão de crédito ao garçom e ele o copiar e, então, clonar, quais serão as consequências? Se não houvesse mitigações aplicadas (veja mais sobre isso a seguir), o atacante poderia facilmente comprar milhares de dólares em bens pelos quais seríamos cobrados, potencialmente arruinando nosso crédito e requerendo muitas horas de trabalho árduo para solucionar essa situação. As consequências de ter nosso cartão de crédito clonado se a ameaça tiver sucesso em explorar a vulnerabilidade provavelmente serão sérias.

O que temos aqui a respeito de risco? O sistema atual tem uma séria vulnerabilidade, já que você não vê o cartão o tempo todo e pode ser facilmente clonado com o dispositivo correto (que está amplamente disponível para qualquer um que queira). A ameaça é provavelmente muito baixa, já que a maioria dos garçons não quer roubar informações de nossos cartões. As consequências do sucesso em explorar tal vulnerabilidade, entretanto, podem ser muito grandes.

22

Segurança de aplicativos Android

Considere todos esses fatores juntos e terá uma boa ideia de qual é o risco de pagar uma refeição com o cartão de crédito: o resultado não será particularmente positivo. Esta é a definição básica de risco: é uma função que envolve vulnerabilidade, ameaça e consequências.

Então por que as pessoas estão dispostas a entregar seus cartões regularmente? O risco não está no nível que acabamos de calcular. As partes envolvidas implementaram mitigações para reduzir esse risco. Como vimos, o risco é uma função que envolve vulnerabilidade, ameaça e consequências. Se a gravidade de qualquer um desses três itens puder ser reduzida, o risco geral diminuirá.

No nosso exemplo, as companhias de cartão de crédito fizeram muito para mitigar as consequências para o consumidor. Nos Estados Unidos, a responsabilidade por cobranças feitas em um cartão comprometido é limitada a 50 dólares e muitas companhias de cartão estabelecem esse valor em zero. Então, se um cliente fosse pagar uma refeição e o cartão fosse clonado e usado fraudulentamente, não seria responsabilizado pela cobrança e tais ocorrências não teriam impacto negativo na classificação de crédito dele. As companhias de cartão de crédito assumem esse risco porque precisam reduzir as consequências do comprometimento de cartões de crédito para reduzir o risco (para o consumidor) associado a usar os cartões para um nível aceitável. Uma vez que as consequências reais de um comprometimento são muito pequenas, os clientes não hesitam em usar cartões, já que o risco é muito reduzido devido a essa mitigação.

Pense um pouco sobre o exemplo do cartão de crédito – que outras mitigações seriam aplicadas a esse exemplo para reduzir a vulnerabilidade, ameaça, ou consequências? Você provavelmente pensou em algumas delas.

Um pouco sobre segurança de dispositivo e conta de usuário É possível e, em alguns casos, muito desejável seu aplicativo aprender sobre o status de segurança do dispositivo no qual está sendo executado. Usando a API Device Management, apresentada no Android 2.2, aplicativos podem determinar políticas de senha em dispositivos, determinar se os recursos de encriptação estão habilitados e outras funções similares. Esses recursos são úteis em algumas situações, mas estão um pouco fora do escopo deste livro.

Mesmo assim, se você precisar determinar ou influenciar o estado de alguns recursos de segurança do dispositivo, é bom saber que essa API existe, então se considere informado.

Outro tópico importante é a segurança de uma conta no Google. Dispositivos Android são quase sempre ligados a uma conta no Google e aos serviços do

Capítulo 1 ■ Introdução

23

Google fornecidos pelos aplicativos Android que usam tipicamente essa conta.

Portanto, é muito importante manter sua conta no Google segura e inacessível a todos. O Google fornece diversos recursos de segurança que podem e devem ser habilitados, como a capacidade de requerer autenticação de dois fatores para acessar sua conta (você precisa saber sua senha e também digitar um código enviado para seu telefone celular quando tentar acessar sua conta), configurar um endereço de e-mail secundário para permitir recuperação da conta etc. Há tantos itens dentro do Android relacionados a essa conta do Google que a segurança deve ser prioridade máxima.

Evolução da segurança da informação: por que os aplicativos são o mais importante Quem pratica a segurança deve se preocupar com vários itens. O campo fundamental geralmente se concentra em fornecer três serviços: confidencialidade, integridade e disponibilidade (CID). Confidencialidade se refere a ter certeza que somente as pessoas (dispositivos ou sistemas etc.) que devem ter acesso a certa informação têm esse acesso. Por exemplo, no exemplo do app de integração de redes sociais que discutimos, os nomes de usuário e senhas armazenados devem estar disponíveis somente para o app e respectivo serviço a que os usuários pertencem. Integridade se refere a garantir que os dados não sejam alterados por ninguém que não devesse estar fazendo isso. No app de calendarização que discutimos, um pouco de código escondido em um jogo instalado em um telefone não seria capaz de mudar a agenda de compromissos do usuário, fazendo que ele perca reuniões importantes. Disponibilidade se refere a garantir que os serviços estejam funcionando como deveriam. Por exemplo, um atacante que envie várias requisições falsas a um servidor não deve ser capaz de interromper o serviço para usuários legítimos. Essa tríade CID é um modelo muito geral e simples para aplicativos que precisam ser protegidos.

A segurança do aplicativo é muito importante hoje em dia. Quinze anos atrás, o principal assunto de interesse era o sistema operacional. No final dos anos 1990, os atacantes constantemente descobriam e exploravam condições conhecidas como buffer overflow em sistemas e serviços baseados em Unix (vamos discutir os buffer overflows em geral um pouco mais tarde). No começo dos anos 2000, o alvo mudou para sistemas operacionais de desktop, especificamente o Windows XP, em que um grande número de vulnerabilidades foi descoberta, que davam aos atacantes acesso total a sistemas, a capacidade de

24

Segurança de aplicativos Android

ler, modificar ou destruir os dados contidos. Na verdade, embora o Windows Vista estivesse sendo desenvolvido ao mesmo tempo que o Windows XP estava sendo explorado tão rapidamente, a Microsoft congelou o desenvolvimento do Vista para concentrar seus esforços em consertar a segurança do XP. Levou muito tempo, mas a Microsoft avançou muito na produção de código sólido, seguro e robusto. Os sistemas operacionais Windows modernos são muito menos exploráveis do que as versões anteriores.

Esse sucesso em reforçar o sistema operacional fez que os atacantes se direcionassem para outros alvos. Durante algum tempo, os dispositivos de rede como switches e roteadores foram os alvos preferidos e, posteriormente, os aplicativos.

Se o sistema operacional no qual é executado um aplicativo é muito mais difícil de explorar, o que dizer sobre o próprio aplicativo? Pelo aplicativo, os atacantes teriam acesso aos dados no sistema da mesma forma e hoje se escrevem mais aplicativos do que sistemas operacionais. Então, a experiência que os desenvolvedores de sistemas operacionais obtiveram escrevendo código com menos vulnerabilidades e a mitigação contra as consequências de uma exploração de sucesso estão muito menos disponíveis no nível do aplicativo. Em razão desses fatores, os aplicativos são atacados o tempo todo hoje. Os atacantes se moveram do ambiente cheio de vulnerabilidades do sistema operacional para o ainda cheio de vulnerabilidades ambiente do aplicativo. Você, como desenvolvedor de aplicativos, precisa estar pronto para elas.

Sua função: proteger os dados Você escreve os apps. Os apps precisam processar alguns dados. Os atacantes querem fazer coisas ruins – roubar, alterar ou bloquear o acesso a esses dados.

Quando o usuário escolhe usar seu app, ele confia a você todos os dados que ele fornece. Ele também confia que seu aplicativo tenha sido escrito corretamente para que nenhum dos outros dados armazenados no seu dispositivo seja comprometido por executar seu aplicativo. Se você escrever apps e quiser que as pessoas os usem, você precisará se esforçar muito para proteger seus clientes. Seu trabalho é simples: escreva seus aplicativos para que eles façam o que seus usuários esperam que eles façam, nem mais nem menos. Realizar esse trabalho é menos simples.