MASTG-BEST-0002: Remover Código de Logging

Idealmente, uma build de release não deve usar nenhuma função de logging, facilitando a avaliação da exposição de dados sensíveis.

Usando ProGuard

Ao preparar a build de produção, você pode usar ferramentas como Proguard (incluída no Android Studio). Para determinar se todas as funções de logging da classe android.util.Log foram removidas, verifique o arquivo de configuração do ProGuard (proguard-rules.pro) para as seguintes opções (de acordo com este exemplo de remoção de código de logging e este artigo sobre como habilitar o ProGuard em um projeto do Android Studio):

-assumenosideeffects class android.util.Log
{
  public static boolean isLoggable(java.lang.String, int);
  public static int v(...);
  public static int i(...);
  public static int w(...);
  public static int d(...);
  public static int e(...);
  public static int wtf(...);
}

Note que o exemplo acima apenas garante que as chamadas para os métodos da classe Log serão removidas. Se a string que será logada for construída dinamicamente, o código que constrói a string pode permanecer no bytecode. Por exemplo, o seguinte código emite um StringBuilder implícito para construir a instrução de log:

Exemplo em Java:

Log.v("Private key tag", "Private key [byte format]: " + key);

Exemplo em Kotlin:

Log.v("Private key tag", "Private key [byte format]: $key")

O bytecode compilado, no entanto, é equivalente ao bytecode da seguinte instrução de log, que constrói a string explicitamente:

Exemplo em Java:

Log.v("Private key tag", new StringBuilder("Private key [byte format]: ").append(key.toString()).toString());

Exemplo em Kotlin:

Log.v("Private key tag", StringBuilder("Private key [byte format]: ").append(key).toString())

O ProGuard garante a remoção da chamada do método Log.v. Se o restante do código (new StringBuilder ...) será removido depende da complexidade do código e da versão do ProGuard.

Isso representa um risco de segurança porque a string (não utilizada) vaza dados em texto simples na memória, que podem ser acessados via debugger ou memory dumping.

Infelizmente, não existe uma solução definitiva para esse problema, mas uma opção seria implementar uma facilidade de logging personalizada que receba argumentos simples e construa as instruções de log internamente.

SecureLog.v("Private key [byte format]: ", key);

Em seguida, configure o ProGuard para remover suas chamadas.

Logging Personalizado

Você pode implementar uma facilidade de logging personalizada e desativá-la de uma vez apenas para as builds de release.

Tests

MASTG-TEST-0231: Referências a APIs de Logging MASTG-TEST-0203: Uso em Tempo de Execução de Logging APIs