Segurança do aplicativo

Esta página descreve vários aspectos da segurança de apps.

Elementos de apps

O Android oferece uma plataforma de código aberto e um ambiente de apps para dispositivos móveis. O sistema operacional principal é baseado no kernel do Linux. Os apps Android são escritos com mais frequência na linguagem de programação Java e executados na máquina virtual Android Runtime (ART). No entanto, os apps também podem ser escritos em código nativo. Os apps são instalados de um único arquivo com a extensão APK.

Os principais elementos de criação de apps Android são:

• AndroidManifest.xml: o arquivo AndroidManifest.xml é o arquivo de controle que informa ao sistema o que fazer com todos os componentes de nível superior (especificamente atividades, serviços, broadcast receivers e provedores de conteúdo descritos abaixo) em um app. Ele também especifica quais permissões são necessárias.

• Atividades:uma atividade é, geralmente, o código de uma única tarefa focada no usuário usando a classe Activity. Uma atividade geralmente inclui a exibição de uma interface do usuário para o usuário, mas não precisa ser assim. Algumas atividades nunca mostram interfaces. Normalmente, uma das atividades do app é o ponto de entrada dele.

• Serviços:um serviço é um conjunto de códigos executado em segundo plano com base na classe Service. Ele pode ser executado no próprio processo ou no contexto do processo de outro app. Outros componentes se vinculam a um serviço e invocam métodos nele por chamadas de procedimento remoto. Um exemplo de serviço é um player de mídia: mesmo quando o usuário sai da interface de seleção de mídia, ele provavelmente ainda quer que a música continue tocando. Um serviço mantém a música tocando mesmo quando a interface é concluída.

• Broadcast receiver:um broadcast receiver é um objeto da classe BroadcastReceiver. Ele é instanciado quando um mecanismo de IPC conhecido como intent, uma instância da classe Intent, é emitido pelo sistema operacional ou por outro app. Um app pode registrar um receptor para a mensagem de bateria fraca, por exemplo, e mudar o comportamento com base nessas informações.

Modelo de permissão do Android: acessar APIs protegidas

Todos os apps no Android são executados em um sandbox de aplicativos. Por padrão, um app Android só pode acessar um intervalo limitado de recursos do sistema. O sistema gerencia o acesso de apps Android a recursos que, se usados de forma incorreta ou maliciosa, podem afetar negativamente a experiência do usuário, a rede ou os dados no dispositivo.

Essas restrições são implementadas de várias formas diferentes. Alguns recursos são restritos por uma falta intencional de APIs para a funcionalidade sensível. Por exemplo, não há uma API do Android para manipular diretamente o chip SIM. Em alguns casos, a separação de papéis oferece uma medida de segurança, como o isolamento por app do armazenamento. Em outros casos, as APIs sensíveis são destinadas ao uso por apps confiáveis e protegidas por um mecanismo de segurança conhecido como permissões.

Essas APIs protegidas incluem:

• Funções da câmera
• Dados de local (GPS)
• Funções do Bluetooth
• Funções de telefonia
• Funções de SMS/MMS
• Conexões de rede/dados

Esses recursos só podem ser acessados pelo sistema operacional. Para usar as APIs protegidas no dispositivo, um app precisa definir os recursos necessários no manifesto. Todas as versões do Android 6.0 e mais recentes usam um modelo de permissões de tempo de execução. Se um usuário solicitar um recurso de um app que exige uma API protegida, o sistema vai mostrar uma caixa de diálogo pedindo que o usuário negue ou permita a permissão.

Depois de concedidas, as permissões são aplicadas ao app enquanto ele estiver instalado. Para evitar confusão, o sistema não notifica o usuário novamente sobre as permissões concedidas ao app, e os apps que estão incluídos no sistema operacional principal ou agrupados por um OEM não solicitam permissões do usuário. As permissões são removidas se um app for desinstalado. Portanto, uma reinstalação subsequente resulta na exibição de permissões.

Nas configurações do dispositivo, os usuários podem ver as permissões dos apps que já instalaram. Os usuários também podem desativar algumas funcionalidades globalmente quando quiserem, como GPS, rádio ou Wi-Fi.

Se um app tentar usar um recurso protegido que não foi declarado no manifesto dele, a falha de permissão geralmente resulta em uma exceção de segurança enviada de volta ao app. As verificações de permissão de API protegida são aplicadas no nível mais baixo possível para evitar violações. Um exemplo de mensagem para o usuário quando um app é instalado ao solicitar acesso a APIs protegidas é mostrado na Figura 2.

As permissões padrão do sistema estão descritas em Manifest.permission. Os apps podem declarar as próprias permissões para outros apps usarem. Essas permissões não estão listadas no local acima.

Ao definir uma permissão, um atributo "protectionLevel" informa ao sistema como o usuário precisa ser informado sobre apps que exigem a permissão ou quem pode manter uma permissão. Os detalhes sobre como criar e usar permissões específicas do app estão descritos na Lista de verificação de segurança.

Alguns recursos do dispositivo, como a capacidade de enviar intents de transmissão de SMS, não estão disponíveis para apps de terceiros, mas podem ser usados por apps pré-instalados pelo OEM. Essas permissões usam a permissão signatureOrSystem.

Como os usuários entendem os apps de terceiros

O Android se esforça para deixar claro aos usuários quando eles estão interagindo com apps de terceiros e informa sobre os recursos que esses apps têm. Antes da instalação de qualquer app, o usuário recebe uma mensagem clara sobre as diferentes permissões que o app está solicitando. Depois da instalação, o usuário não recebe mais solicitações para confirmar permissões.

Há muitos motivos para mostrar permissões imediatamente antes da instalação. É quando o usuário está analisando ativamente informações sobre o app, o desenvolvedor e a funcionalidade para determinar se ele atende às necessidades e expectativas. Também é importante que eles ainda não tenham estabelecido um compromisso mental ou financeiro com o app e possam comparar facilmente o app com outras alternativas.

Algumas outras plataformas usam uma abordagem diferente para notificação do usuário, solicitando permissão no início de cada sessão ou enquanto os apps estão em uso. A visão do Android é que os usuários troquem de apps sem problemas quando quiserem. Fornecer confirmações a cada vez deixaria o usuário mais lento e impediria o Android de oferecer uma ótima experiência. Ao revisar as permissões no momento da instalação, o usuário tem a opção de não instalar o app se não se sentir confortável.

Além disso, muitos estudos de interface do usuário mostraram que o excesso de solicitações faz com que o usuário comece a clicar em OK em qualquer caixa de diálogo mostrada. Um dos objetivos de segurança do Android é transmitir informações importantes de segurança ao usuário de forma eficaz, o que não pode ser feito usando caixas de diálogo que o usuário aprendeu a ignorar. Ao apresentar as informações importantes uma vez e apenas quando necessário, o usuário tem mais chances de pensar no que está aceitando.

Algumas plataformas optam por não mostrar nenhuma informação sobre a funcionalidade do app. Essa abordagem impede que os usuários entendam e discutam facilmente os recursos do app. Embora não seja possível que todos os usuários tomem decisões totalmente informadas, o modelo de permissões do Android facilita o acesso a informações sobre apps para uma ampla variedade de usuários. Por exemplo, solicitações inesperadas de permissões podem levar usuários mais sofisticados a fazer perguntas críticas sobre a funcionalidade do app e compartilhar suas preocupações em lugares como o Google Play, onde elas ficam visíveis para todos os usuários.

Permissões na instalação do app: Google Tradutor	Permissões de um app instalado: Gmail

Figura 1. Exibição de permissões para apps.

Comunicação entre processos

Os processos podem se comunicar usando qualquer um dos mecanismos tradicionais do tipo Unix. Exemplos incluem o sistema de arquivos, sockets locais ou sinais. No entanto, as permissões do Linux ainda são válidas.

O Android também oferece novos mecanismos de IPC:

• Binder:um mecanismo de chamada de procedimento remoto leve baseado em recursos projetado para alto desempenho ao realizar chamadas no processo e entre processos. O Binder é implementado usando um driver Linux personalizado. Para uma descrição da classe, consulte Binder.

• Serviços:os serviços podem fornecer interfaces diretamente acessíveis usando o binder. Para uma descrição mais detalhada, consulte Elementos de apps.

• Intents:uma intent é um objeto de mensagem simples que representa uma intenção de fazer algo. Por exemplo, se o app quiser mostrar uma página da Web, ele expressa a intenção de visualizar o URL criando uma instância de intent e entregando-a ao sistema. O sistema localiza outra parte do código (nesse caso, o navegador) que sabe como processar essa intent e a executa. As intents também podem ser usadas para transmitir eventos interessantes (como uma notificação) em todo o sistema. Para uma descrição da classe, consulte Intent.

• Provedores de conteúdo:um provedor de conteúdo é um depósito de dados que oferece acesso a dados no dispositivo. O exemplo clássico é o provedor de conteúdo usado para acessar a lista de contatos do usuário. Um app pode acessar dados que outros apps expuseram com um provedor de conteúdo, e um app também pode definir o próprio provedor de conteúdo para expor dados próprios. Para uma descrição da classe, consulte ContentProvider.

Embora seja possível implementar IPC usando outros mecanismos, como soquetes de rede ou arquivos graváveis globalmente, estes são os frameworks de IPC do Android recomendados. Os desenvolvedores Android são incentivados a usar práticas recomendadas para proteger os dados dos usuários e evitar a introdução de vulnerabilidades de segurança.

APIs sensíveis a custos

Uma API sensível a custos é qualquer função que possa gerar um custo para o usuário ou para a rede. A plataforma Android colocou APIs sensíveis a custos na lista de APIs protegidas controladas pelo SO. O usuário precisa conceder permissão explícita a apps de terceiros que solicitam o uso de APIs sensíveis a custos. Entre essas APIs, estão incluídas:

• Telefonia
• SMS/MMS
• Rede/Dados
• Faturamento no aplicativo
• Acesso por NFC

O Android 4.2 adiciona mais controle ao uso de SMS. O Android envia uma notificação se um app tentar enviar um SMS para um código curto que usa serviços premium, o que pode gerar cobranças adicionais. O usuário poderá escolher se quer permitir que o app envie a mensagem ou a bloqueie.

Acesso ao chip

O acesso de baixo nível ao chip não está disponível para apps de terceiros. O SO processa todas as comunicações com o chip, incluindo o acesso a informações pessoais (contatos) na memória do chip. Os apps também não podem acessar comandos AT, já que eles são gerenciados exclusivamente pela camada de interface de rádio (RIL). A RIL não oferece APIs de alto nível para esses comandos.

Informações pessoais

O Android colocou APIs que fornecem acesso a dados do usuário no conjunto de APIs protegidas. Com o uso normal, os dispositivos Android também acumulam dados do usuário em apps de terceiros instalados por eles. Os apps que escolhem compartilhar essas informações podem usar verificações de permissão do SO Android para proteger os dados de apps de terceiros.

Figura 2. O acesso a dados sensíveis dos usuários só está disponível por APIs protegidas.

Os provedores de conteúdo do sistema que provavelmente contêm informações pessoais ou de identificação pessoal, como contatos e calendário, foram criados com permissões claramente identificadas. Essa granularidade oferece ao usuário uma indicação clara dos tipos de informações que podem ser fornecidas ao app. Durante a instalação, um app de terceiros pode pedir permissão para acessar esses recursos. Se a permissão for concedida, o app poderá ser instalado e ter acesso aos dados solicitados a qualquer momento enquanto estiver instalado.

Por padrão, os apps que coletam informações pessoais restringem esses dados apenas ao app específico. Se um app optar por disponibilizar os dados para outros apps por IPC, o app que concede acesso poderá aplicar permissões ao mecanismo de IPC que são aplicadas pelo sistema operacional.

Dispositivos de entrada de dados sensíveis

Os dispositivos Android geralmente oferecem dispositivos de entrada de dados sensíveis que permitem que os apps interajam com o ambiente ao redor, como câmera, microfone ou GPS. Para que um app de terceiros acesse esses dispositivos, ele precisa primeiro receber acesso explícito do usuário usando as permissões do SO Android. Após a instalação, o instalador pede ao usuário permissão para o sensor por nome.

Se um app quiser saber a localização do usuário, ele vai precisar de uma permissão para acessar essa informação. Após a instalação, o instalador pergunta ao usuário se o app pode acessar a localização dele. A qualquer momento, se o usuário não quiser que nenhum app acesse a localização dele, ele pode executar o app Configurações, acessar Localização e segurança e desmarcar as opções Usar redes sem fio e Ativar satélites de GPS. Isso desativa os serviços baseados em localização para todos os apps no dispositivo do usuário.

Metadados do dispositivo

O Android também se esforça para restringir o acesso a dados que não são intrinsecamente sensíveis, mas podem revelar indiretamente características sobre o usuário, as preferências dele e a maneira como ele usa um dispositivo.

Por padrão, os apps não têm acesso a registros do sistema operacional, histórico do navegador, número de telefone ou informações de identificação de hardware ou rede. Se um app solicitar acesso a essas informações no momento da instalação, o instalador vai perguntar ao usuário se o app pode acessar as informações. Se o usuário não conceder acesso, o app não será instalado.

Autoridades certificadoras

O Android inclui um conjunto de autoridades certificadoras do sistema instaladas, que são confiáveis em todo o sistema. Antes do Android 7.0, os fabricantes de dispositivos podiam modificar o conjunto de CAs enviados nos dispositivos deles. No entanto, os dispositivos com Android 7.0 e versões mais recentes têm um conjunto uniforme de CAs do sistema, já que a modificação por fabricantes de dispositivos não é mais permitida.

Para ser adicionada como uma nova CA pública ao conjunto padrão do Android, a CA precisa concluir o Processo de inclusão de CA da Mozilla e enviar uma solicitação de recurso para o Android ( https://code.google.com/p/android/issues/entry) para que a CA seja adicionada ao conjunto padrão de CAs do Android no Android Open Source Project (AOSP).

Ainda há CAs específicas de dispositivos que não devem ser incluídas no conjunto principal de CAs do AOSP, como CAs privadas de operadoras que podem ser necessárias para acessar com segurança componentes da infraestrutura da operadora, como gateways de SMS/MMS. Recomendamos que os fabricantes de dispositivos incluam as CAs particulares apenas nos componentes/apps que precisam confiar nelas. Para mais detalhes, consulte Configuração de segurança de rede.

Assinatura de apps

A assinatura de código permite que os desenvolvedores identifiquem o autor do app e atualizem o app sem criar interfaces e permissões complicadas. Todos os apps executados na plataforma Android precisam ser assinados pelo desenvolvedor. Os apps que tentam instalar sem serem assinados são rejeitados pelo Google Play ou pelo instalador de pacotes no dispositivo Android.

No Google Play, a assinatura de apps une a confiança que o Google tem com o desenvolvedor e a confiança que o desenvolvedor tem com o app. Os desenvolvedores sabem que o app é fornecido sem modificações para o dispositivo Android, e eles podem ser responsabilizados pelo comportamento do app.

No Android, a assinatura de apps é a primeira etapa para colocar um app no sandbox de aplicativos. O certificado do app assinado define qual ID de usuário está associado a qual app. Apps diferentes são executados com IDs de usuário diferentes. A assinatura de apps garante que um app não possa acessar nenhum outro app, exceto por IPC bem definido.

Quando um app (arquivo APK) é instalado em um dispositivo Android, o gerenciador de pacotes verifica se o APK foi assinado corretamente com o certificado incluído nele. Se o certificado (ou, mais precisamente, a chave pública no certificado) corresponder à chave usada para assinar qualquer outro APK no dispositivo, o novo APK terá a opção de especificar no manifesto que compartilha um UID com os outros APKs assinados de maneira semelhante.

Os apps podem ser assinados por terceiros (OEM, operadora, mercado alternativo) ou autoassinados. O Android oferece assinatura de código usando certificados autoassinados que os desenvolvedores podem gerar sem assistência ou permissão externa. Os apps não precisam ser assinados por uma autoridade central. No momento, o Android não realiza a verificação da CA para certificados de apps.

Os apps também podem declarar permissões de segurança no nível de proteção de assinatura, restringindo o acesso apenas a apps assinados com a mesma chave, mantendo UIDs e sandboxes de aplicativos distintos. Um relacionamento mais próximo com uma caixa de isolamento de aplicativo compartilhada é permitido pelo recurso de UID compartilhado, em que dois ou mais apps assinados com a mesma chave de desenvolvedor podem declarar um UID compartilhado no manifesto.

Verificação de apps

O Android 4.2 e versões mais recentes oferecem suporte à verificação de apps. Os usuários podem ativar a Verificação de apps para que os apps sejam avaliados por um verificador antes da instalação. A verificação de apps pode alertar o usuário se ele tentar instalar um app que possa ser perigoso. Se um app for especialmente nocivo, ela poderá bloquear a instalação.

Gerenciamento de direitos digitais

A plataforma Android oferece um framework de gerenciamento de direitos digitais (DRM) extensível que permite aos apps gerenciar conteúdo protegido por direitos de acordo com as restrições de licença associadas ao conteúdo. O framework de DRM oferece suporte a vários esquemas de DRM. Os esquemas compatíveis com um dispositivo são definidos pelo fabricante do dispositivo.

O framework de DRM do Android é implementado em duas camadas arquitetônicas (consulte a Figura 3):

• Uma API de framework de DRM, que é exposta aos apps pelo framework de apps Android e executada pela VM ART para apps padrão.

• Um gerenciador de DRM de código nativo que implementa o framework de DRM e expõe uma interface para plug-ins de DRM (agentes) processarem o gerenciamento de direitos e a descriptografia para vários esquemas de DRM.

Figura 3. Arquitetura do DRM na plataforma Android.