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.

O padrão Java requer que as implementações de Object.equals(), Comparable.compareTo() e Comparator.compare() retornem um valor especificado se seus parâmetros forem null. Comportamentos inesperados poderão ocorrer se esse contrato não for seguido.

Exemplo 1: A seguinte implementação do método equals() não compara seu parâmetro com null.

public boolean equals(Object object)
{
   return (toString().equals(object.toString()));
}

Violações de privacidade ocorrem quando:

1. Informações privadas de usuários entram no programa.

2. Os dados são gravados em um local externo, como o console, o sistema de arquivos ou a rede.
Exemplo 1: O código a seguir contém uma instrução de log que rastreia os registros adicionados a um banco de dados, armazenando o conteúdo em um arquivo de log.

pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

O código no Example 1 registra uma senha de texto sem formatação no sistema de arquivos. Embora muitos desenvolvedores confiem no log de eventos como um local de armazenamento seguro para os dados, ele não deve ser confiado de forma implícita, especialmente quando a privacidade é uma preocupação.

A privacidade é uma das maiores preocupações no mundo móvel por alguns motivos. Um deles é uma chance muito maior de perda do dispositivo. O outro tem a ver com a comunicação entre processos de aplicativos móveis. Com plataformas móveis, os aplicativos são baixados de várias fontes e são executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta e é por isso que os autores de aplicativos precisam ser cuidadosos a respeito de quais informações eles incluem em mensagens endereçadas a outros aplicativos em execução no dispositivo. Informações confidenciais nunca devem fazer parte da comunicação entre processos de aplicativos móveis.

Exemplo 2: O código a seguir lê o nome de usuário e a senha de um determinado site em um repositório WebView do Android e os transmite a todos os receptores registrados.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    Intent i = new Intent();
    i.setAction("SEND_CREDENTIALS");
    i.putExtra("username", username);
    i.putExtra("password", password);
    view.getContext().sendBroadcast(i);
  }
});
...

Esse exemplo demonstra vários problemas. Em primeiro lugar, por padrão, credenciais WebView são armazenadas em texto sem formatação e não estão em hash. Se um usuário tiver um dispositivo raiz (ou usar um emulador), ele poderá ler senhas armazenadas para sites específicos. Em segundo lugar, credenciais de texto sem formatação são transmitidas para todos os receptores registrados, o que significa que qualquer receptor registrado para ouvir intenções com a ação SEND_CREDENTIALS receberá a mensagem. A transmissão nem mesmo é protegida com uma permissão para limitar o número de destinatários, embora, neste caso, não recomendemos o uso de permissões como correção.

Dados privados podem entrar em um programa de várias maneiras:

- Diretamente do usuário em formato de senha ou informações pessoais

- Acessados a partir de um banco de dados ou outro repositório de dados pelo aplicativo

- Indiretamente de um parceiro ou de terceiros

Normalmente, no contexto do ambiente móvel, essas informações privadas incluem (juntamente com senhas, SSNs e outras informações pessoais gerais):

- Localização

- Número do celular

- Números de série e IDs de dispositivo

- Informações sobre a operadora de rede

- Informações de correio de voz


Às vezes, dados não rotulados como privados podem ter uma implicação de privacidade em um contexto diferente. Por exemplo, números de identificação de aluno geralmente não são considerados privados, pois não há um mapeamento explícito e publicamente disponível para as informações pessoais de um aluno individual. No entanto, se uma escola gerar números de identificação com base em números de segurança social de alunos, esses números de identificação deverão ser considerados privados.

Preocupações de segurança e privacidade muitas vezes parecem competir umas com as outras. Sob o ponto de vista da segurança, você deve registrar todas as operações importantes para que qualquer atividade anormal possa ser identificada mais tarde. No entanto, quando dados privados estão envolvidos, essa prática pode gerar riscos.

Embora existam muitas maneiras de manipular dados privados sem segurança, um risco comum está relacionado a equívocos de confiança. Os programadores muitas vezes confiam no ambiente operacional em que um programa é executado e, portanto, julgam aceitável armazenar informações privadas no sistema de arquivos, no registro ou em outros recursos localmente controlados. No entanto, mesmo se o acesso a determinados recursos for restrito, isso não garante que os indivíduos que possuem esse acesso possam ser confiáveis. Por exemplo, em 2004, um funcionário sem escrúpulos da AOL vendeu cerca de 92 milhões de endereços de email privados de clientes para um remetente de spam que comercializava um site de jogatina em atividade fora do país [1].

Em resposta a tais explorações notórias, a coleta e o gerenciamento de dados privados estão se tornando cada vez mais regulamentados. Dependendo da sua localização, do tipo de negócios administrado e da natureza de quaisquer dados privados que ela manipule, uma organização pode ser obrigada a cumprir uma ou mais das seguintes normas federais e estaduais:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Apesar dessas normas, violações de privacidade continuam a ocorrer com uma frequência alarmante.

A classe HttpRequest fornece acesso programático a variáveis das coleções QueryString, Form, Cookies ou ServerVariables sob a forma de um acesso de array (por exemplo, Request["myParam"]). Quando há mais de uma variável com o mesmo nome, o .NET Framework retorna o valor da variável que aparece primeiro quando as coleções são pesquisadas, na ordem seguinte: QueryString, Form, Cookies e depois ServerVariables. Como QueryString vem em primeiro lugar na ordem de pesquisa, é possível que parâmetros QueryString substituam valores de formulários, cookies e variáveis de servidor. Da mesma forma, valores de formulário podem substituir variáveis nas coleções Cookies e ServerVariables, enquanto variáveis da coleção Cookies podem substituir as de ServerVariables.
Exemplo 1: Imagine que um aplicativo de operações bancários armazena temporariamente o endereço de e-mail de um usuário em um cookie e lê esse valor quando deseja entrar em contato com o usuário. O código a seguir lê o valor do cookie e envia um saldo de conta ao endereço de e-mail especificado.

...
    String toAddress = Request["email"];        //Expects cookie value
    Double balance = GetBalance(userID);
    SendAccountBalance(toAddress, balance);
...

Suponha que o código no Example 1 seja executado durante uma visita a http://www.example.com/GetBalance.aspx. Se um invasor puder fazer com que um usuário autenticado clique em um link que solicita http://www.example.com/GetBalance.aspx?email=evil%40evil.com, um e-mail com o saldo da conta desse usuário será enviado para evil@evil.com.

A classe HttpRequest fornece acesso programático a variáveis das coleções QueryString, Form, Cookies ou ServerVariables sob a forma de um acesso de array (por exemplo, Request["myParam"]). Quando há mais de uma variável com o mesmo nome, o .NET Framework retorna o valor da variável que aparece primeiro quando as coleções são pesquisadas, na ordem seguinte: QueryString, Form, Cookies e depois ServerVariables. Como QueryString vem em primeiro lugar na ordem de pesquisa, é possível que parâmetros QueryString substituam valores de formulários, cookies e variáveis de servidor. Da mesma forma, valores de formulário podem substituir variáveis nas coleções Cookies e ServerVariables, enquanto variáveis da coleção Cookies podem substituir as de ServerVariables.
Exemplo 1: O código a seguir verifica a variável de servidor do cabeçalho HTTP Referer para ver se a solicitação é proveniente de www.example.com antes de apresentar o conteúdo.

    ...
    if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
        ServeContent();
    else
        Response.Redirect("http://www.example.com/");
    ...

Suponha que o código no Example 1 seja executado durante uma visita a http://www.example.com/ProtectedImages.aspx. Se um invasor realizar uma solicitação direta para a URL, o cabeçalho de referência adequado não será definido e a solicitação falhará. No entanto, se o invasor enviar um parâmetro HTTP_REFERER artificial com o valor necessário, como http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com, a pesquisa retornará esse valor de QueryString em vez de ServerVariables, e a verificação será bem-sucedida.