Skip to content

Most visited

Recently visited

navigation

Dicas de segurança

O Android tem recursos de segurança incorporados ao sistema operacional que reduzem significativamente a frequência e o impacto dos problemas de segurança de aplicativos. O sistema é projetado para que você possa compilar seus aplicativos normalmente com permissões padrão do sistema e de arquivos e evitar decisões difíceis sobre a segurança.

Alguns dos principais recursos de segurança que ajudam você a compilar aplicativos seguros incluem:

De qualquer forma, é importante se familiarizar com as práticas recomendadas para a segurança do Android apresentadas neste documento. Seguir estas práticas como hábitos gerais de criação de código reduzirá a probabilidade da introdução acidental de problemas de segurança que afetem seus usuários negativamente.

Armazenamento de dados

Uma das preocupações de segurança mais comuns para um aplicativo no Android é se os dados salvos no dispositivo podem ser acessados por outros aplicativos. Existem três maneiras fundamentais de salvar dados no dispositivo:

Usando o armazenamento interno

Por padrão, os arquivos que você criar no armazenamento interno podem ser acessados apenas por seu aplicativo. Essa proteção é implementada pelo Android e é suficiente para a maioria dos aplicativos.

De forma geral, você deve evitar o uso dos modos MODE_WORLD_WRITEABLE ou MODE_WORLD_READABLE para arquivos IPC pois eles não fornecem a capacidade de limitar o acesso de dados a aplicativos específicos, nem fornecem controle sobre o formato dos dados. Se quiser compartilhar seus dados com outros processos de aplicativos, considere o uso de um provedor de conteúdo, que oferece permissões de leitura e gravação para outros aplicativos e pode fazer concessões de permissões de acordo com cada caso.

Para fornecer proteção adicional a dados confidenciais, você pode optar por criptografar arquivos locais usando uma chave que não possa ser diretamente acessada pelo aplicativo. Por exemplo, uma chave pode ser inserida em um KeyStore e protegida por uma senha do usuário que não está armazenada no dispositivo. Embora isso não proteja os dados contra uma violação de raiz que possa monitorar a inserção de senhas do usuário, essa abordagem pode oferecer proteção para um dispositivo perdido sem criptografia do sistema de arquivos.

Usando o armazenamento externo

Arquivos criados em um armazenamento externo, como cartões SD, podem ser lidos e gravados globalmente. Como o armazenamento externo pode ser removido pelo usuário e modificado por qualquer aplicativo, você não deve armazenar nele informações confidenciais.

Seguindo o mesmo procedimento para dados de fontes não confiáveis, você deve validar as entradas ao manipular dados de armazenamentos externos. Recomendamos que você não armazene arquivos executáveis ou de classe em armazenamentos externos antes do carregamento dinâmico. Se seu aplicativo recuperar arquivos executáveis de um armazenamento externo, eles devem ser assinados e verificados criptograficamente antes do carregamento dinâmico.

Usando provedores de conteúdo

Provedores de conteúdo oferecem um mecanismo de armazenamento estruturado que pode ser limitado ao seu aplicativo ou exportado para permitir o acesso de outros aplicativos. Se você não pretende permitir que outros aplicativos acessem seu ContentProvider, marque-os como android:exported=false no manifesto. Caso contrário, defina o atributo android:exported como "true" para permitir que outros aplicativos acessem os dados armazenados.

Ao criar um ContentProvider que será exportado para o uso de outros aplicativos, você pode especificar uma só permissão de leitura e gravação ou permissões distintas de leitura e gravação no manifesto. Recomendamos a limitação das permissões àquelas necessárias para executar a tarefa em questão. Lembre-se de que é geralmente mais fácil adicionar permissões posteriormente para expor novos recursos do que removê-las e interromper usuários existentes.

Se você estiver usando um provedor de conteúdo para compartilhar dados somente entre seus próprios aplicativos, é preferível usar o conjunto de atributos android:protectionLevel definido para a proteção "signature". Permissões de assinatura não exigem a confirmação do usuário, portanto, eles proporcionam uma experiência melhor para o usuário e um acesso mais controlado aos dados do provedor de conteúdo quando os aplicativos que acessam os dados são assinados com a mesma chave.

Provedores de conteúdo também podem fornecer um acesso mais granular declarando o atributo android:grantUriPermissions e usando os sinalizadores FLAG_GRANT_READ_URI_PERMISSION e FLAG_GRANT_WRITE_URI_PERMISSION no objeto Intent que ativa o componente. O escopo dessas permissões pode ser mais limitado pelo <grant-uri-permission element>.

Ao acessar o provedor de conteúdo, use métodos de consulta parametrizada, como query(), update(), e delete(), para evitar possíveis injeções de SQL de fontes não confiáveis. Observe que o uso de métodos parametrizados não é suficiente se o argumento selection for incorporado ao concatenar dados do usuário antes de enviá-los ao método.

Não crie uma falsa sensação de segurança sobre a permissão de gravação. Considere que a permissão de gravação permite declarações SQL que possibilitam que alguns dados sejam confirmados usando cláusulas WHERE criativas e analisando os resultados. Por exemplo, um invasor pode verificar a presença de um número de telefone específico em um registro de chamadas ao modificar uma linha apenas se esse número já existir. Se os dados do provedor de conteúdo tiverem uma estrutura previsível, a permissão de gravação pode equivaler a uma permissão de leitura e gravação.

Uso de permissões

Como o Android isola os aplicativos uns dos outros, eles devem compartilhar recursos e dados de forma explícita. Isso é feito ao declarar as permissões necessárias para recursos adicionais não fornecidos pelo sandbox básico, incluindo o acesso a recursos do dispositivo, como a câmera.

Solicitação de permissões

Recomendamos a minimização do número de permissões solicitadas por seu aplicativo. Não ter acesso a permissões essenciais reduz o risco do uso indevido acidental dessas permissões, pode melhorar a adoção dos usuários e torna seu aplicativo menos vulnerável a invasores. Em geral, se uma permissão não é necessária para o funcionamento do seu aplicativo, você não deve solicitá-la.

Se for possível projetar seu aplicativo de forma que não exija permissões, essa é a abordagem preferencial. Por exemplo, em vez de solicitar o acesso a informações do dispositivo para criar um identificador exclusivo, crie um GUID para seu aplicativo (consulte a seção sobre o Gerenciamento dos dados do usuário). Ou, em vez de usar um armazenamento externo (que exige permissão), armazene dados no armazenamento interno.

Além de solicitar permissões, seu aplicativo pode usar <permissions> para proteger o IPC que apresenta riscos de segurança e será exposto a outros aplicativos, como um ContentProvider. Em geral, recomendamos o uso de controles de acesso além de permissões confirmadas pelo usuário sempre que possível, pois as permissões podem ser confusas para os usuários. Por exemplo, considere o uso do nível de proteção de assinatura em permissões para comunicação de IPC entre aplicativos fornecidos por um só desenvolvedor.

Não vaze dados protegidos por permissões. Isso ocorre quando seu aplicativo expõe dados pelo IPC que está disponível apenas porque seu aplicativo tem permissão para acessar esses dados. Os clientes da interface IPC do seu aplicativo podem não ter as mesmas permissões de acesso a dados. Mais detalhes sobre a frequência e os possíveis efeitos desse problema são apresentados nesta pesquisa, publicada na USENIX.

Criação de permissões

Em geral, você deve se empenhar para definir o menor número possível de permissões e atender aos seus requisitos de segurança. Criar uma nova permissão é relativamente incomum para a maioria dos aplicativos, pois as permissões definidas pelo sistema englobam muitas situações. Quando apropriado, execute verificações de acesso usando as permissões existentes.

Se for preciso criar uma nova permissão, considere se sua tarefa pode ser executada com um nível de proteção de "assinatura". Permissões de assinatura são transparentes ao usuário e só permitem o acesso de aplicativos assinados pelo mesmo desenvolvedor do aplicativo que executa a verificação de permissão.

Se você criar uma permissão com o nível de proteção "perigoso", considere as seguintes complexidades:

Cada uma dessas situações apresenta um desafio não técnico significativo para você, como desenvolvedor, além de confundir seus usuários. Por esse motivo, não incentivamos o uso do nível de permissão “perigoso”.

Uso da rede

Transações de rede são inerentemente arriscadas para a segurança, pois elas envolvem a transmissão de dados potencialmente privados para o usuário. As pessoas estão cada vez mais conscientes das questões de privacidade de um dispositivo móvel, especialmente quando esse dispositivo executa transações de rede. Dessa forma, é muito importante que seu aplicativo implemente todas as práticas recomendadas para manter os dados do usuário protegidos a todo o momento.

Uso de rede IP

A rede do Android não é muito diferente de outros ambientes Linux. A principal consideração é garantir que os protocolos apropriados sejam usados para dados confidenciais, como o HttpsURLConnection para o tráfego da Web seguro. Preferimos o uso do HTTPS em vez do HTTP em qualquer local que esse protocolo tenha suporte no servidor, pois os dispositivos móveis frequentemente se conectam a redes que não são protegidas, como pontos de acesso Wi-Fi públicos.

A comunicação de nível de soquete criptografada e autenticada pode ser facilmente implementada usando a classe SSLSocket. Considerando a frequência com a qual os dispositivos Android se conectam a redes sem fio desprotegidas usando Wi-Fi, o uso da rede segura é fortemente encorajado para todos os aplicativos que se comunicam por rede.

Observamos que alguns aplicativos usam as portas de rede localhost para gerenciar IPC confidencial. Essa abordagem não é recomendada, pois essas interfaces podem ser acessadas por outros aplicativos do dispositivo. Em vez disso, use um mecanismo de IPC do Android no qual a autenticação seja possível, como com um Service. (Vincular a INADDR_ANY é ainda pior do que usar um loopback, pois seu aplicativo poderá receber solicitações de qualquer lugar.)

Além disso, uma questão comum que deve ser enfatizada é garantir que você não confie em dados baixados de HTTP ou de outros protocolos não seguros. Isso inclui a validação de entradas no WebView e de qualquer resposta a intents emitidas por HTTP.

Uso da rede de telefonia

O protocolo SMS foi criado, principalmente, para a comunicação entre usuários e não é adequada para a transferência de dados de aplicativos. Devido às limitações do SMS, recomendamos o uso do Google Cloud Messaging (GCM) e da rede IP para o envio de mensagens de dados de um servidor Web para seu aplicativo em um dispositivo do usuário.

Esteja ciente de que o SMS não é criptografado ou fortemente autenticado na rede ou no dispositivo. Em particular, qualquer receptor de destinatário de SMS deve esperar que um usuário mal-intencionado possa ter enviado o SMS para o seu aplicativo — Não utilize dados SMS não autenticados para executar comandos essenciais. Além disso, esteja ciente de que o SMS pode estar sujeito a spoofing e/ou a interceptação na rede. No próprio dispositivo Android, as mensagens SMS são transmitidas como intents de transmissão, portanto, elas podem ser lidas ou capturadas por outros aplicativos que tenham a permissão READ_SMS.

Validação de entradas

A validação de entradas insuficiente é um dos problemas de segurança mais comuns que afetam os aplicativos, independentemente da plataforma executada. O Android não tem medidas no nível da plataforma para reduzir a exposição de aplicativos a problemas de validação de entradas e você deve usar esses recursos sempre que possível. Observe também que a seleção de linguagens com segurança de tipo tende a reduzir a probabilidade de problemas de validação de entradas.

Se você estiver usando o código nativo, qualquer dado lido dos arquivos, recebidos pela rede, ou recebidos por um IPC tem o potencial para introduzir um problema de segurança. Os problemas mais comuns são sobrecargas de buffer, uso após a liberação e erros off-by-one. O Android oferece diversas tecnologias, como ASLR e DEP, que reduzem a capacidade de exploração desses erros, mas elas não solucionam o problema inicial. Essas vulnerabilidades podem ser evitadas com a manipulação cuidadosa de ponteiros e o gerenciamento de buffers.

Linguagens dinâmicas baseadas em strings, como JavaScript e SQL, também estão sujeitas a problemas de validação de entradas devido a caracteres com escape e à injeção de script.

Se você estiver usando dados em consultas enviadas para um banco de dados SQL ou um provedor de conteúdo, a injeção de SQL pode ser um problema. A melhor defesa é o uso de consultas parametrizadas, conforme é discutido na seção acima sobre provedores de conteúdo. A limitação de permissões para somente leitura ou somente gravação também pode reduzir o potencial de risco relacionado à injeção de SQL.

Se não conseguir usar os recursos de segurança acima, recomendamos o uso de formatos de dados bem estruturados e a verificar se esses dados seguem o formato esperado. Embora a inclusão de caracteres na lista negra ou a substituição de caracteres possam ser estratégias eficazes, essas técnicas tendem ao erro na prática e devem ser evitadas sempre que possível.

Gerenciamento de dados do usuário

Em geral, a melhor abordagem para a segurança dos dados do usuário é minimizar o uso de APIs que acessem dados confidenciais ou pessoais do usuário. Se você tiver acesso aos dados do usuário e puder evitar o armazenamento ou a transmissão dessas informações, faça isso. Por fim, considere se existe uma maneira de implementar a lógica do seu aplicativo usando um hash ou um formado não reversivo dos dados. Por exemplo, seu aplicativo pode usar o hash de um endereço de e-mail como uma chave primária para evitar a transmissão ou o armazenamento do endereço de e-mail. Isso reduz as chances de exposição acidental dos dados e de tentativas de exploração do seu aplicativo por parte de invasores.

Se seu aplicativo acessar informações pessoais como senhas ou nomes de usuário, lembre-se de que algumas jurisdições podem exigir que você forneça uma política de privacidade explicando seu uso e armazenamento desses dados. Portanto, o uso das práticas recomendadas de segurança para minimizar o acesso aos dados do usuário também pode simplificar a conformidade.

Considere também se seu aplicativo pode estar expondo acidentalmente informações pessoais para outras partes, como componentes de terceiros para publicidade ou serviços de terceiros usados por seu aplicativo. Se não souber porque um componente ou serviço precisa de informações pessoais, não as forneça. Em geral, a redução do acesso a informações pessoais por parte do seu aplicativo reduzirá o potencial para problemas nessa área.

Se o acesso a dados confidenciais for necessário, avalie se essas informações devem ser transmitidas a um servidor ou se a operação pode ser executada no cliente. Considere executar qualquer código usando dados confidenciais no cliente para evitar a transmissão de dados do usuário.

Além disso, não deixe de evitar a exposição acidental de dados do usuário a outros aplicativos do dispositivo com um IPC muito permissivo, arquivos graváveis globalmente ou soquetes de rede. Esse é um caso especial de vazamento de dados protegidos por permissão, discutido na seção Solicitação de permissões.

Se um GUID for necessário, crie um número grande e exclusivo e armazene-o. Não use identificadores de telefone, como o número de telefone ou o IMEI, que podem ser associados a informações pessoais. Esse tópico é discutido em mais detalhes no Blog dos desenvolvedores Android.

Tenha cuidado ao escrever em registros no dispositivo. No Android, os registros são um recurso compartilhado e são disponibilizados para um aplicativo com a permissão READ_LOGS. Mesmo que os dados de registro do telefone sejam temporários e apagados após a reinicialização, o registro inapropriado de informações do usuário podem acabar vazando dados do usuário para outros aplicativos.

Uso do WebView

Como o WebView consome conteúdo Web que pode incluir HTML e JavaScript, o uso impróprio pode introduzir problemas comuns de segurança da Web como cross-site-scripting (injeção de JavaScript). O Android inclui diversos mecanismos para reduzir o escopo desses problemas em potencial ao limitar a capacidade do WebView à funcionalidade mínima exigida por seu aplicativo.

Se seu aplicativo não usar o JavaScript diretamente em um WebView, não chame setJavaScriptEnabled(). O código de exemplo usa esse método e pode ser reutilizado no aplicativo de produção, portanto, remova a chamada do método se ela não for necessária. Por padrão, o WebView não executa o JavaScript, logo, cross-site-scripting não é possível.

Use addJavaScriptInterface() com cuidado, pois ele permite que o JavaScript invoque operações normalmente reservadas a aplicativos Android. Se você usá-lo, exponha addJavaScriptInterface() somente para páginas da Web nas quais todas as entradas sejam confiáveis. Se entradas não confiáveis forem permitidas, um JavaScript não confiável poderá invocar métodos do Android no seu aplicativo. Em geral, recomendamos expor addJavaScriptInterface() apenas para o JavaScript contido no APL do seu aplicativo.

Se seu aplicativo acessar dados confidenciais com um WebView, você pode querer usar o método clearCache() para excluir arquivos armazenados localmente. Cabeçalhos do lado do servidor como o no-cache também podem ser usados para indicar que um aplicativo não deve armazenar em cache conteúdos específicos.

Dispositivos que executam plataformas mais antigas que o Android 4.4 (nível de API 19) usam uma versão do webkit que tem diversos problemas de segurança. Como solução alternativa, se seu aplicativo estiver sendo executado nesses dispositivos, ele deve confirmar que os objetos WebView exibem apenas conteúdo confiável. Você também deve usar o objeto de segurança atualizável Provider para garantir que seu aplicativo não seja exposto a possíveis vulnerabilidades no SSL, conforme é descrito em Atualizar seu provedor de segurança para proteger-se contra explorações de SSL. Se seu aplicativo precisar renderizar conteúdo da Web aberta, considere fornecer seu próprio renderizador para mantê-lo atualizado com os últimos patches.

Gerenciamento de credenciais

Em geral, recomendamos minimizar a frequência de solicitações de credenciais do usuário — para tornar os ataques de phishing mais evidentes e reduzir sua probabilidade de sucesso. Em vez disso, use um token de autorização e atualize-o.

Quando possível, nomes de usuários e senhas não devem ser armazenados no dispositivo. Em vez disso, realize a autenticação usando o nome de usuário e a senha fornecidos pelo usuário e então use um token de autorização de curta duração específico para serviços.

Serviços que poderão ser acessados por vários aplicativos devem ser acessados usando AccountManager. Se possível, use a classe AccountManager para invocar um serviço baseado na nuvem e não armazene senhas no dispositivo.

Após usar AccountManager para recuperar um Account, CREATOR antes de passar qualquer credencial para que você evite passar acidentalmente as credenciais para aplicativos errados.

Se as credenciais forem usadas apenas por aplicativos criados por você, você pode verificar o aplicativo que acessar o AccountManager usando checkSignature(). Como alternativa, se apenas um aplicativo usará as credenciais, você pode usar um KeyStore para armazenamento.

Uso da criptografia

Além de fornecer isolamento de dados, oferecer suporte criptografia para todo o sistema de arquivos e fornecer canais de comunicação seguros, o Android fornece diversos algoritmos para proteger dados usando a criptografia.

Em geral, tente usar o mais alto nível de implementação de estrutura pré-existente que ofereça suporte ao seu caso de uso. Se precisar recuperar um arquivo de um local conhecido de forma segura, um simples URI HTTPS pode ser adequado e não exige conhecimento de criptografia. Se precisar de um túnel seguro, considere usar HttpsURLConnection ou SSLSocket, em vez de criar seu próprio protocolo.

Se precisar implementar seu próprio protocolo, recomendamos que você não implemente seus próprios algoritmos criptográficos. Use algoritmos criptográficos como os da implementação de AES ou RSA fornecida na classe Cipher.

Use um gerador de número aleatório seguro, SecureRandom, para inicializar qualquer chave criptográfica, KeyGenerator. O uso de uma chave que não for gerada por um gerador de número aleatório seguro reduz significativamente a força do algoritmo e pode permitir ataques off-line.

Se precisar armazenar uma chave para uso repetido, use um mecanismo como KeyStore que ofereça armazenamento de longo prazo e recuperação de chaves criptográficas.

Uso da comunicação entre processos

Alguns aplicativos tentam implementar IPC usando técnicas tradicionais do Linux, como soquetes de rede e arquivos compartilhados. Incentivamos o uso de recursos do sistema Android para IPC, como Intent, Binder ou Messenger com um Service e BroadcastReceiver. Os mecanismos de IPC do Android permitem que você verifique a identidade do aplicativo que estiver se conectando ao seu IPC e defina políticas de segurança para cada mecanismo de IPC.

Muitos dos elementos de segurança são compartilhados entre mecanismos de IPC. Se seu mecanismo de IPC não for destinado ao uso de outros aplicativos, defina o atributo android:exported como "false" no elemento de manifesto do componente, por exemplo, para o elemento <service>. Isso é útil para aplicativos que consistem de vários processos no mesmo UID, ou se você decidir posteriormente durante o desenvolvimento que não deseja expor a funcionalidade como IPC, mas não quiser reprogramar o código.

Se seu IPC for acessado por outros aplicativos, você pode aplicar uma política de segurança usando o elemento <permission>. Se o IPC estiver entre seus próprios aplicativos separados que foram assinados com a mesma chave, é preferível usar a permissão de nível "signature" no android:protectionLevel.

Uso de intents

As intents são o mecanismo preferencial para IPC assíncrono no Android. Dependendo dos requisitos do seu aplicativo, você pode usar sendBroadcast(), sendOrderedBroadcast() ou uma intent explícita para um componente de aplicativo específico.

Observe que transmissões ordenadas podem ser "consumidas" por um destinatário, portanto, elas podem não ser entregues para todos os aplicativos. Se você estiver enviando uma intent que precise ser entregue para um destinatário específico, use uma intent explícita que declare o destinatário com nameintent.

Os remetentes de uma intent podem verificar se o destinatário tem uma permissão que especifique uma permissão não nula com a chamada do método. Apenas aplicativos com essa permissão receberão a intent. Se for possível que os dados em uma intent de transmissão sejam confidenciais, considere aplicar uma permissão para garantir que aplicativos mal-intencionados não possam se registrar para receber essas mensagens sem as permissões apropriadas. Nessas circunstâncias, você também deve considerar invocar o destinatário diretamente em vez de gerar uma transmissão.

Observação: Os filtros de intent não devem ser considerados um recurso de segurança — componentes podem ser invocados com intents explícitas e podem não ter dados em conformidade com o filtro de intent. Você deve realizar a validação de entradas no seu destinatário de intent para confirmar se ele está formatado corretamente para o destinatário, o serviço ou a atividade que foi invocada.

Uso de serviços

Um Service é frequentemente usado para fornecer recursos para o uso de outros aplicativos. Cada classe de serviço deve ter uma declaração <service> correspondente no arquivo de manifesto.

Por padrão, os serviços não são exportados e não podem ser invocados por qualquer outro aplicativo. No entanto, se você adicionar filtros de intent na declaração de serviço, ela será exportada por padrão. É recomendável declarar o atributo android:exported explicitamente para garantir que ele se comporte da forma desejada. Os serviços também podem ser protegidos usando o atributo android:permission. Ao fazer isso, outros aplicativos precisarão declarar um elemento <uses-permission> correspondente em seus próprios manifestos para poderem iniciar, interromper ou vincular o serviço.

Um serviço pode proteger chamadas de IPC individuais dentro dele com permissões ao chamar checkCallingPermission() antes de executar a implementação dessa chamada. Geralmente recomendamos o uso de permissões declarativas no manifesto, pois elas são menos propensas a lapsos.

Uso de interfaces binder e messenger

O uso de Binder ou Messenger é o mecanismo preferencial para o IPC de estilo RPC no Android. Eles proporcionam uma interface bem definida que possibilita a autenticação mútua dos pontos de extremidade, se necessário.

Recomendamos o design de interfaces de forma que não exija verificações de permissões específicas de interface. Os objetos Binder e Messenger não são declarados no manifesto do aplicativo e, dessa forma, não é possível aplicar permissões declarativas diretamente neles. Eles geralmente herdam permissões declaradas no manifesto do aplicativo para o Service ou a Activity na qual são implementados. Se você estiver criando uma interface que exija autenticação e/ou controles de acesso, esses controles devem ser explicitamente adicionados como código na interface Binder ou Messenger.

Se você estiver fornecendo uma interface que exija controles de acesso, use checkCallingPermission() para verificar se o autor da chamada tem uma permissão obrigatória. Isso é especialmente importante antes de acessar um serviço em nome do chamador, pois a identidade do seu aplicativo é passada para outras interfaces. Se você estiver invocando uma interface fornecida por um Service, a invocação bindService() poderá falhar se você não tiver permissão para acessar o serviço em questão. Se você estiver chamando uma interface fornecida localmente por seu próprio aplicativo, pode ser útil usar o clearCallingIdentity() para satisfazer as verificações de segurança internas.

Para obter mais informações sobre como executar IPC com um serviço, consulte Serviços vinculados.

Uso de destinatários de transmissão

Um BroadcastReceiver gerencia as solicitações assíncronas iniciadas por uma Intent.

Por padrão, os destinatários são exportados e podem ser invocados por qualquer outro aplicativo. Se seu BroadcastReceiver for usado por outros aplicativos, pode ser recomendável aplicar permissões de segurança para destinatários usando o elemento <receiver> no manifesto do aplicativo. Isso impedirá que aplicativos que não tenham as permissões apropriadas enviem uma intent ao BroadcastReceiver.

Carregamento dinâmico de código

Nós desencorajamos veementemente o carregamento de código fora do APK do seu aplicativo. Isso pode aumentar significativamente a probabilidade de comprometimento do aplicativo por injeção ou violação de código. Essa abordagem também adiciona complexidade ao gerenciamento de versões e ao teste de aplicativos. Por fim, ela pode também impossibilitar a verificação do comportamento de um aplicativo, portanto, pode ser proibida em alguns ambientes.

Se seu aplicativo carregar código dinamicamente, o mais importante a se lembrar sobre o código dinamicamente carregado é que ele é executado com as mesmas permissões de segurança que o APK do aplicativo. O usuário tomou a decisão de instalar seu aplicativo com base em sua identidade e ele espera que você forneça o código executado no aplicativo, incluindo o código dinamicamente carregado.

O principal risco de segurança associado ao carregamento dinâmico de código é que o código precisa ser originado em uma fonte verificável. Se os módulos forem incluídos diretamente no seu APK, eles não poderão ser modificados por outros aplicativos. Isso é válido independentemente de o código ser uma biblioteca nativa ou uma classe carregada usando DexClassLoader. Nós temos muitas instâncias de aplicativos que tentam carregar código de locais não seguros, como códigos baixados da rede por meio de protocolos não criptografados ou de locais globalmente graváveis, como um armazenamento externo. Esses locais poderiam permitir que um usuário da rede modificasse o conteúdo em trânsito ou que outro aplicativo no dispositivo de um usuário modificasse o conteúdo no dispositivo, respectivamente.

Segurança em uma máquina virtual

A Dalvik é uma máquina virtual (VM) de tempo de execução do Android. A Dalvik foi criada especificamente para o Android, mas muitas das preocupações relacionadas com a segurança do código em outras máquinas virtuais também se aplicam ao Android. Em geral, você não deve se preocupar com problemas de segurança relacionados à máquina virtual. Seu aplicativo é executado em um ambiente de sandbox seguro, portanto, outros processos no sistema não podem acessar seu código ou seus dados privados.

Se tiver interesse em entrar em mais detalhes sobre o assunto de segurança de máquinas virtuais, recomendamos que você se familiarize com a literatura existente sobre o assunto. Dois dos recursos mais populares são:

Este documento se concentra nas áreas específicas ao Android ou que diferem de outros ambientes de VM. Para desenvolvedores que têm experiência com a programação de VMs em outros ambientes, existem duas questões amplas que podem ser diferentes na programação de aplicativos para Android:

Segurança no código nativo

Em geral, nós incentivamos os desenvolvedores a usar o Android SDK para o desenvolvimento de aplicativos em vez de usar o código nativo com o Android NDK. Aplicativos criados com código nativo são mais complexos, menos portáteis e mais propensos a incluir erros comuns de corrupção de memória, como sobrecargas de buffer.

O Android é criado com o kernel do Linux e estar familiarizado com as práticas recomendadas para a segurança do desenvolvimento em Linux é especialmente útil se você pretende usar o código nativo. As práticas de segurança do Linux estão fora do escopo deste documento, mas um dos recursos mais populares é “Secure Programming for Linux and Unix HOWTO”, disponível em http://www.dwheeler.com/secure-programs.

Uma diferença importante entre o Android e a maioria dos ambientes Linux é o sandbox de aplicativos. No Android, todos os aplicativos são executados no sandbox de aplicativos, incluindo os criados com código nativo. No nível mais básico, uma boa maneira de considerar esse cenário para desenvolvedores com experiência em Linux é saber que cada aplicativo recebe um UID exclusivo com permissões muito limitadas. Isso é discutido em mais detalhes na Visão geral de segurança do Android e você deve estar familiarizado com as permissões do aplicativo, mesmo que esteja usando o código nativo.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Siga o Google Developers no WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience. (Dec 2017 Android Platform & Tools Survey)