Esta seção contém recomendações para garantir a segurança de apps em dispositivos Android.
Revisão do código-fonte
A análise do código-fonte pode detectar uma ampla gama de problemas de segurança, incluindo aqueles identificados neste documento. O Android incentiva fortemente a revisão manual e automatizada do código-fonte.
- Siga as orientações de segurança abrangentes ao realizar análises para garantir a cobertura. Use padrões internos ou externos relevantes para garantir avaliações consistentes e completas.
- Execute um lint, como o lint do Android Studio, em todo o código do app usando o SDK do Android e corrija os problemas identificados.
- Analise o código nativo usando uma ferramenta automatizada que pode detectar problemas de gerenciamento de memória, como estouro de buffer e erros de um.
- O sistema de build do Android oferece suporte a muitos dos limpadores LLVM, como AddressSanitizer e UndefinedBehaviorSanitizer, que podem ser usados para análise de tempo de execução de problemas relacionados à memória. Combinados com fuzzing, que é aceito no Android pela libFuzzer, os limpadores podem descobrir casos extremos incomuns que exigem mais investigação.
- Um assessor de segurança experiente precisa analisar o código de risco mais alto, como criptografia, processamento de pagamentos e processamento de PII.
Testes automatizados
Os testes automatizados podem ajudar a detectar uma ampla gama de problemas de segurança e devem ser realizados regularmente.
- Execute a versão mais recente do CTS regularmente durante o processo de desenvolvimento para detectar problemas antecipadamente e reduzir o tempo de correção. O Android usa o CTS como parte da integração contínua no processo de build automatizado, que é executado várias vezes por dia.
- Automatizar testes de segurança de interfaces, incluindo testes com entradas malformadas (testes de imprecisão). O sistema de build do Android oferece suporte à libFuzzer para escrever testes de fuzz.
Verificação de vulnerabilidades
A verificação de vulnerabilidades pode ajudar a garantir que os apps pré-instalados não tenham vulnerabilidades de segurança conhecidas. A detecção avançada pode reduzir o tempo e o custo necessários para lidar com essas vulnerabilidades e evitar riscos para usuários e dispositivos.
- Verifique todos os apps pré-instalados usando uma ferramenta de verificação de vulnerabilidades reconhecida pelo setor e resolva as vulnerabilidades detectadas.
Aplicativos potencialmente nocivos
É importante garantir que os apps pré-instalados no seu dispositivo não sejam apps potencialmente nocivos (PHAs, na sigla em inglês). Você é responsável pelo comportamento de todos os apps incluídos nos seus dispositivos. Antes do lançamento do dispositivo, verifique se há vulnerabilidades em todos os apps pré-carregados.
Para mais informações sobre PHAs e como o Google está combatendo esse tipo de app na Play Store, consulte a documentação para desenvolvedores do Google Play Protect.
Instalação de apps e permissões
Permissões excessivas para apps pré-instalados podem criar um risco de segurança. Restrinja os apps pré-instalados às permissões mínimas necessárias e garanta que eles não tenham acesso a permissões ou privilégios desnecessários. As permissões do app são descritas no AndroidManifest.xml.
- Não conceda permissões ou privilégios desnecessários a apps pré-instalados. Revise completamente os apps com privilégios do sistema, porque eles podem ter permissões muito sensíveis.
- Verifique se todas as permissões solicitadas são relevantes e necessárias para a funcionalidade desse app específico.
- Garanta que haja uma declaração do usuário para todos os apps pré-instalados que usam a
permissão
INSTALL_PACKAGES. - Verifique se o desenvolvedor tem a obrigação contratual de não instalar apps como UID 0.
- Avalie as permissões declaradas no manifesto de todos os apps a serem instalados pela rede do desenvolvedor.
- O desenvolvedor precisa estar obrigado por contrato a verificar todos os URLs de download de apps de atualização automática e instalação com a API Google Safe Browsing antes de enviar apps para o dispositivo.
Assinatura de apps
As assinaturas de apps têm um papel importante na segurança do dispositivo e são usadas para verificações de permissões e atualizações de software. Ao selecionar uma chave para usar em apps de assinatura, é importante considerar se um app está disponível apenas em um único dispositivo ou se é comum em vários dispositivos.
- Verifique se os apps não são assinados com uma chave conhecida publicamente, como a chave de desenvolvedor do AOSP.
- Garanta que as chaves usadas para assinar apps sejam gerenciadas de maneira consistente com as práticas padrão do setor para lidar com chaves sensíveis, incluindo um módulo de segurança de hardware (HSM) que ofereça acesso limitado e auditável.
- Verifique se os apps não são assinados com a chave da plataforma. Isso dá ao app acesso a permissões de assinatura da plataforma, que são muito poderosas e devem ser usadas apenas por componentes do sistema operacional. Os apps do sistema precisam usar permissões privilegiadas.
- Confira se apps com o mesmo nome de pacote não estão assinados com chaves diferentes. Isso geralmente ocorre ao criar um app para dispositivos diferentes, especialmente ao usar a chave da plataforma. Se o app for independente do dispositivo, use a mesma chave em todos os dispositivos. Se o app for específico para dispositivos, crie nomes de pacotes exclusivos por dispositivo e chave.
Isolar apps e processos
O modelo de sandbox do Android oferece segurança extra para apps e processos quando usado corretamente.
Isolar processos raiz
Os processos raiz são o alvo mais frequente de ataques de elevação de privilégios. Reduzir o número de processos raiz reduz o risco de elevação de privilégios.
- Verifique se os dispositivos executam o código mínimo necessário como raiz. Sempre que possível, use um processo normal do Android em vez de um processo raiz. Se um processo precisar ser executado como raiz em um dispositivo, documente o processo em uma solicitação de recurso do AOSP para que ele possa ser analisado publicamente.
- Sempre que possível, o código raiz precisa ser isolado de dados não confiáveis e acessado por comunicação interprocesso (IPC). Por exemplo, reduza a funcionalidade de raiz a um pequeno serviço acessível pelo Binder e exponha o serviço com permissão de assinatura a um app com poucos ou nenhum privilégio para processar o tráfego de rede.
- Os processos raiz não podem detectar um socket de rede.
- Os processos raiz não podem incluir um ambiente de execução de uso geral, como uma VM Java.
Isolar apps do sistema
Em geral, os apps pré-instalados não podem ser executados com o identificador exclusivo do sistema compartilhado (UID). Se for necessário que um app use o UID compartilhado do sistema ou de outro serviço privilegiado (por exemplo, smartphone), ele não poderá exportar serviços, broadcast receivers ou provedores de conteúdo que possam ser acessados por apps de terceiros instalados pelos usuários.
- Garanta que os dispositivos executem o código mínimo necessário como sistema. Sempre que possível, use um processo do Android com o próprio UID em vez de reutilizar o UID do sistema.
- Sempre que possível, o código do sistema precisa ser isolado de dados não confiáveis e expor o IPC apenas para outros processos confiáveis.
- Os processos do sistema não podem detectar um soquete de rede. Esse é um requisito do CTS.
Isolar processos
O sandbox de apps Android oferece aos apps uma expectativa de isolamento de outros processos no sistema, incluindo processos raiz e depuradores. A menos que a depuração seja especificamente ativada pelo app e pelo usuário, nenhum app pode violar essa expectativa.
- Verifique se os processos raiz não acessam dados em pastas de dados de apps individuais, a menos que usem um método de depuração do Android documentado.
- Os processos raiz não podem acessar a memória de apps, a menos que usem um método de depuração do Android documentado.
- Verifique se os dispositivos não incluem nenhum app que acesse dados ou memória de outros apps ou processos.