Esta seção contém recomendações para garantir a segurança dos apps em dispositivos Android.
Revisão de código-fonte
A revisão do código-fonte pode detectar uma ampla variedade de problemas de segurança, incluindo os identificados neste documento. O Android recomenda fortemente a revisão manual e automatizada do código-fonte.
- Siga orientações de segurança abrangentes ao realizar análises para garantir a cobertura. Use padrões internos ou externos relevantes para garantir análises consistentes e completas.
- Execute um linter, como o linter 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 estouros de buffer e erros de um a menos.
- O sistema de build do Android oferece suporte a muitos dos sanitizadores do LLVM, como AddressSanitizer e UndefinedBehaviorSanitizer, que podem ser usados para análise em tempo de execução de problemas relacionados à memória. Combinados com fuzzing, compatível com o Android por meio do libFuzzer, os sanitizadores podem descobrir casos extremos incomuns que exigem mais investigação.
- Um avaliador de segurança experiente deve analisar códigos de maior risco, como criptografia, processamento de pagamentos e tratamento de PII.
Testes automatizados
Os testes automatizados ajudam a detectar uma ampla variedade de problemas de segurança e precisam ser realizados regularmente.
- Execute regularmente a versão mais recente do CTS durante todo 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 nosso processo de build automatizado, que é executado várias vezes por dia.
- Automatize o teste de segurança de interfaces, incluindo testes com entradas malformadas (teste de fuzzing). O sistema de build do Android oferece suporte ao libFuzzer para escrever testes de fuzzing.
Verificação de vulnerabilidades
A verificação de vulnerabilidades ajuda 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 resolver essas vulnerabilidades e evitar riscos para usuários e dispositivos.
- Verifique todos os apps pré-instalados usando uma ferramenta de verificação de vulnerabilidades de apps reconhecida pelo setor e corrija as vulnerabilidades detectadas.
Aplicativos potencialmente nocivos
É importante garantir que os apps pré-instalados no dispositivo não sejam aplicativos 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 todos os apps pré-carregados em busca de vulnerabilidades.
Para mais informações sobre PHAs e como o Google está combatendo esses apps na Play Store, consulte a documentação para desenvolvedores do Google Play Protect.
Instalação e permissões de apps
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. Analise cuidadosamente os apps com privilégios do sistema, já que eles podem ter permissões muito sensíveis.
- Verifique se todas as permissões solicitadas são relevantes e necessárias para a funcionalidade do app específico.
- Garanta que haja uma divulgação ao usuário para todos os apps pré-instalados que usam a
permissão
INSTALL_PACKAGES. - Verifique se o desenvolvedor tem uma 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.
- Verifique se o desenvolvedor tem obrigação contratual de verificar todos os URLs de download de apps de atualização automática e de instalação com a API Google Navegação Segura antes de veicular apps no 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 assinar apps, é importante considerar se um app está disponível apenas em um único dispositivo ou em vários.
- Verifique se os apps não estão assinados com uma chave de conhecimento público, como a chave de desenvolvedor do AOSP.
- Verifique se as chaves usadas para assinar apps são gerenciadas de maneira consistente com as práticas padrão do setor para processar chaves sensíveis, incluindo um módulo de segurança de hardware (HSM) que oferece acesso limitado e auditável.
- Verifique se os apps não estão assinados com a chave da plataforma. Isso dá a um app acesso a permissões de assinatura da plataforma, que são muito poderosas e destinadas apenas ao uso por componentes do sistema operacional. Os apps do sistema precisam usar permissões privilegiadas.
- Verifique se apps com o mesmo nome de pacote não estão assinados com chaves diferentes. Isso geralmente acontece ao criar um app para diferentes dispositivos, principalmente ao usar a chave da plataforma. Se o app for independente de dispositivo, use a mesma chave em todos eles. Se o app for específico para um dispositivo, crie nomes de pacotes exclusivos por dispositivo e chave.
Isolar apps e processos
O modelo de sandbox do Android oferece mais segurança para apps e processos quando usado corretamente.
Isolar processos de raiz
Os processos raiz são o alvo mais frequente de ataques de escalonamento de privilégios. Reduzir o número de processos raiz diminui o risco de escalonamento 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 root. Se um processo precisar ser executado como root em um dispositivo, documente-o em uma solicitação de recurso do AOSP para que 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 entre processos (IPC, na sigla em inglês). Por exemplo, reduza a funcionalidade 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 soquete 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 devem ser executados com o identificador único (UID) compartilhado do sistema. Se for necessário que um app use o UID compartilhado do sistema ou outro serviço privilegiado (por exemplo, telefone), o app não poderá exportar serviços, receptores de transmissão ou provedores de conteúdo que possam ser acessados por apps de terceiros instalados pelos usuários.
- Verifique se os dispositivos executam o código mínimo necessário como sistema. Quando possível, use um processo do Android com um UID próprio 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 IPC apenas a 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 aplicativos para 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 ativada especificamente pelo app e pelo usuário, nenhum app deve violar essa expectativa.
- Verifique se os processos de root não acessam dados em pastas de dados de apps individuais, a menos que usem um método de depuração do Android documentado.
- Verifique se os processos raiz não acessam a memória dos apps, a menos que usem um método de depuração do Android documentado.
- Verifique se os dispositivos não incluem apps que acessam dados ou a memória de outros apps ou processos.