Qualquer aplicativo pode acessar componentes públicos que não tenham uma permissão de acesso explicitamente atribuída em sua definição de manifesto.

O valor padrão do atributo exported para os componentes de atividade, receptor e serviço em um aplicativo Android depende da presença ou ausência de um intent-filter. A presença de um intent-filter implica que o componente destina-se para uso externo, definindo assim o atributo exported como "true". Esse componente agora está acessível para qualquer outro aplicativo na plataforma Android.

Exemplo 1: Veja a seguir um exemplo de uma atividade do Android com um intent-filter e sem nenhuma permissão de acesso explícito definida.

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

Esta atividade pode ser explorada por aplicativos mal-intencionados.

Qualquer aplicativo pode acessar componentes públicos que não tenham uma permissão de acesso explicitamente atribuída em sua definição de manifesto. Os provedores de conteúdo Android são exportados por padrão para aplicativos que definem android:minSdkVersion ou android:targetSdkVersion como "16" ou anterior. Para aplicativos que definem qualquer um desses atributos como "17" ou posterior, o padrão é "false".

Exemplo 1: Veja a seguir um exemplo de um provedor de conteúdo Android declarado sem uma permissão de acesso explícita ou um sinalizador exportado.

 <provider android:name=".ContentProvider"/> 

O Android depende de um provedor de segurança para fornecer comunicações de rede seguras. No entanto, de vez em quando, vulnerabilidades são encontradas no provedor de segurança padrão. Para se proteger contra essas vulnerabilidades, o Google Play Services oferece uma maneira de atualizar automaticamente o provedor de segurança de um dispositivo para proteção contra explorações conhecidas. Ao chamar os métodos do Google Play Services, seu aplicativo pode garantir que está sendo executado em um dispositivo que possui as atualizações mais recentes para proteção contra explorações conhecidas.

O recurso de configuração de segurança de rede permite que os aplicativos personalizem suas configurações de segurança de rede em um arquivo de configuração declarativo e seguro sem modificar o código do aplicativo. Essas configurações podem ser definidas para domínios específicos e para um aplicativo específico. Os principais recursos desse recurso são os seguintes:
- Âncoras de confiança personalizadas: Personalize quais Autoridades de Certificação (CA) são confiáveis para as conexões seguras de um aplicativo. Por exemplo, confiar em certificados autoassinados específicos ou restringir o conjunto de CAs públicas nas quais o aplicativo confia.
- Substituições apenas de depuração: Depure com segurança conexões seguras em um aplicativo sem risco adicional para a base instalada.
- Desativação do tráfego de texto simples: Proteja os aplicativos do uso acidental de tráfego de texto não criptografado.
- Fixação de certificado: Restrinja a conexão segura de um aplicativo a certificados específicos.

Transmissões enviadas sem a permissão do receptor ficam acessíveis a qualquer receptor. Se essas transmissões contiverem dados confidenciais ou acessarem um receptor mal-intencionado, o aplicativo poderá ficar comprometido.

Exemplo 1: O código a seguir envia uma transmissão sem especificar a permissão do receptor.

...
context.sendBroadcast(intent);
...

As transmissões do sistema podem ser enviadas para componentes privados. Os componentes precisam ser públicos para receber transmissões que não são do sistema de terceiros. Ao se registrar para receber tanto transmissões do sistema quanto transmissões que não são do sistema em um único componente, parte da funcionalidade do componente (a parte do sistema) é desnecessariamente exposta a terceiros.

Ao declarar uma permissão personalizada, existem quatro opções para especificar o nível de proteção da permissão: normal, dangerous, signature e signature or system. Normal as permissões são concedidas a qualquer aplicativo que as solicite. Dangerous as permissões são concedidas somente após a confirmação do usuário. Signature as permissões são concedidas apenas a aplicativos assinados pela mesma chave de desenvolvedor do pacote que define a permissão. Signature or system permissões são semelhantes às permissões signature, mas também são concedidas a pacotes na imagem do sistema Android.

Exemplo 1: Veja a seguir um exemplo de uma permissão personalizada declarada com o nível de proteção normal.

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

Um provedor de conteúdo declarado com a permission combinada de leitura e gravação estará acessível para as entidades que solicitam acesso de leitura ou gravação ao provedor. No entanto, em muitos casos, assim como no caso de arquivos em um sistema de arquivos, as entidades que precisam de acesso de leitura aos dados armazenados pelo provedor não devem ter permissão para modificar os dados. Configurar o atributo permission não permite distinguir entre usuários de dados e interações que afetam a integridade dos dados.

Exemplo 1: Veja a seguir um exemplo de um provedor de conteúdo declarado com o atributo permission de acesso combinado de leitura e gravação.

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/> 

Transmissões persistentes não podem ser protegidas com uma permissão e, portanto, são acessíveis a qualquer receptor. Se essas transmissões contiverem dados confidenciais ou acessarem um receptor mal-intencionado, o aplicativo poderá ficar comprometido.

Exemplo 1: O código a seguir envia uma transmissão persistente.

...
context.sendStickyBroadcast(intent);
...

Definir novas permissões no namespace android.permission pode ter consequências inesperadas quando o sistema operacional é atualizado. Se a versão mais recente do sistema operacional definir exatamente a mesma permissão, o Android Package Management Service (PMS) concederá silenciosamente a permissão ao aplicativo, sem pedir ao usuário que permita ataques de escalonamento de privilégios.

Como este componente espera receber apenas mensagens de transmissão do sistema e não de outros componentes, ele deve ser privado (inacessível para outros componentes)

Os cookies são estritamente um mecanismo HTTP, de acordo com a RFC 2109. Não deve haver expectativa razoável de que eles trabalhem para protocolos que não sejam HTTP, incluindo file://. Não está claro qual deve ser seu comportamento e quais regras de compartimentalização de segurança devem ser aplicadas. Por exemplo, os arquivos HTML baixados para o disco local da Internet compartilham os mesmos cookies que qualquer código HTML instalado localmente?

Não é recomendável que os desenvolvedores criem seus aplicativos usando APIs não documentadas ou ocultas. Não há garantias de que o Google não irá remover ou alterar essas APIs no futuro e, portanto, elas devem ser evitadas. Dessa forma, usar esses métodos ou campos tem um alto risco de violar seu aplicativo.

O código tenta usar o objeto Camera depois que ele já foi liberado. Qualquer referência adicional ao objeto Camera sem a reaquisição do recurso lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir usa um botão de alternância para ativar e desativar a visualização da câmera. Depois que o usuário tocar no botão uma vez, a visualização da câmera será interrompida, e o recurso da câmera será liberado. No entanto, se ele tocar no botão novamente, startPreview() será chamado no objeto Camera anteriormente liberado.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

O código tenta usar o objeto de mídia depois que ele já foi liberado. Qualquer referência adicional a esse objeto de mídia sem a reaquisição do recurso lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir usa um botão de pausa para alternar a reprodução da mídia. Depois que o usuário tocar no botão uma vez, a música ou o vídeo atual será pausado, e o recurso da câmera será liberado. No entanto, se ele tocar no botão novamente, start() será chamado no recurso de mídia anteriormente liberado.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

O código tenta usar o manipulador de banco de dados SQLite do Android depois que ele já foi fechado. Qualquer referência adicional ao manipulador sem o restabelecimento da conexão com o banco de dados lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir pode ser de um programa que armazena em cache valores de usuário temporariamente na memória, mas que pode chamar flushUpdates() para confirmar as alterações no disco. O método fecha corretamente o manipulador de banco de dados depois de gravar atualizações no banco de dados. No entanto, quando flushUpdates() é chamado novamente, o objeto de banco de dados é referenciado novamente antes da reinicialização.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Identificadores específicos de hardware e dispositivos são mantidos persistentes entre limpezas de dados e redefinições de fábrica. Não se deve confiar nesses identificadores para gerar identificadores exclusivos usados para autorizar ou autenticar usuários.

Além disso, o vazamento de identificadores universalmente exclusivos, que podem ser associados a informações pessoais, representa uma ameaça à segurança e à privacidade do usuário.

Vulnerabilidades de Sequestro de Carregamento de Classe Android assumem duas formas:

- Um invasor pode alterar o nome dos diretórios pesquisados pelo programa para carregar classes, apontando o caminho para um diretório sobre o qual ele tem controle: o invasor controla explicitamente os caminhos que devem ser pesquisados em busca de classes.

- Um invasor pode alterar o ambiente no qual a classe é carregada: o invasor controla implicitamente o que o nome do caminho significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar os diretórios pesquisados por classes a serem carregadas. Vulnerabilidades de Sequestro de Carregamento de Classe Android desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como uma string, ou parte de uma string, que representa um diretório de biblioteca para procurar classes a serem carregadas.



3. Ao executar o código no caminho da biblioteca, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir usa o userClassPath alterável pelo usuário para determinar o diretório no qual procurar classes a serem carregadas.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

Esse código permite que um invasor carregue uma biblioteca e execute possivelmente um código arbitrário com o privilégio elevado do aplicativo, sendo capaz de modificar o resultado de userClassPath de forma que ele aponte para um caminho diferente que o invasor pode controlar. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor de userClassPath, ele poderá enganar o aplicativo de forma com que este aponte para um diretório controlado pelo invasor e, portanto, poderá carregar as classes que ele definiu usando os mesmos privilégios que o aplicativo original.

Exemplo 2: O código a seguir usa a userOutput modificável pelo usuário para determinar o diretório em que os arquivos DEX otimizados devem ser escritos.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

Esse código permite que um invasor especifique o diretório de saída para arquivos DEX otimizados (ODEX). Isso então permite que um usuário mal-intencionado altere o valor de userOutput para um diretório que ele pode controlar, como um armazenamento externo. Quando isso for conseguido, será simplesmente uma questão de substituir o arquivo ODEX processado por um arquivo ODEX mal-intencionado para que este seja executado com os mesmos privilégios do aplicativo original.

Os aplicativos Android podem ser configurados para produzir binários de depuração. Esses binários fornecem mensagens de depuração detalhadas e não devem ser usados em ambientes de produção. O atributo debuggable da tag <application> define se os binários compilados devem incluir informações de depuração.

O uso de binários de depuração faz com que um aplicativo forneça ao usuário o máximo de informações possível sobre si mesmo. Os binários de depuração devem ser usados em um ambiente de desenvolvimento ou teste e podem representar um risco de segurança se forem implantados em produção. Os invasores podem aproveitar as informações adicionais adquiridas com a saída de depuração para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

Vulnerabilidades de travessia de caminho de Zip ocorrem quando um agente malicioso consegue especificar nomes de entrada de arquivo Zip em um determinado arquivo Zip. Quando um nome de entrada de arquivo Zip é especificado maliciosamente, um invasor pode substituir o conteúdo dos principais arquivos do sistema quando o arquivo Zip correspondente é expandido. Os invasores podem usar expressões idiomáticas de travessia de caminho, como ../ e / para acessar arquivos do sistema que de outra forma estariam fora do escopo do programa. Os aplicativos Android que têm como alvo o Android 14 e versões posteriores podem, por padrão, lançar uma exceção quando expressões idiomáticas como ../ e/ são detectadas durante a extração do arquivo Zip. Esse recurso de segurança pode ser substituído ou desabilitado completamente.

Exemplo 1: O código a seguir desabilita a proteção contra Zip Entry Overwrite.

...
dalvik.system.ZipPathValidator.clearCallback();
...