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: 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: 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: 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.