Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Security
Code

Protegendo as Comunicações no Android

by
Difficulty:BeginnerLength:MediumLanguages:

Portuguese (Português) translation by Luis Drum (you can also view the original English article)

Com todas as recentes violações de dados, a privacidade tornou-se um tema importante. Quase todos os apps comunicam-se através da rede, por isso é importante considerar a segurança das informações do usuário. Neste post, você vai aprender as melhores práticas atuais para proteger as comunicações de seu aplicativo Android.

Usar HTTPS

Enquanto você estiver desenvolvendo seu app, é prática recomendada limitar suas solicitações de rede para aquelas que são essenciais. Para as essenciais, certifique-se de que elas são feitos por HTTPS em vez de HTTP. HTTPS é um protocolo que criptografa o tráfego para que não seja facilmente interceptado por espiões. A coisa boa sobre o Android é que a migração é tão simples como mudar a URL de http para https.

Na verdade, o Android N e versões superiores podem impor o HTTPS usando a Configuração de Segurança de Rede do Android.

No Android Studio, selecione o diretório app/res/xml para seu projeto. Crie o diretório de xml se ele ainda não existir. Selecione-o e clique em File > New File. Chame-o network_security_config.xml. O formato para o arquivo é o seguinte:

Para dizer ao Android para usar esse arquivo, adicione o nome do arquivo para a tag de aplicativo no arquivo AndroidManifest.xml:

Atualizar Provedores de Criptografia

O protocolo HTTPS foi explorado diversas vezes ao longo dos anos. Quando os pesquisadores de segurança relatam vulnerabilidades, os defeitos geralmente são corrigidos. Aplicar as correções garante que as conexões de rede do seu aplicativo estão usando os protocolos padrão da indústria mais atualizados. As versões mais recentes dos protocolos contêm menos fraquezas do que as anteriores.

Para atualizar os provedores de criptografia, você precisará incluir os Serviços do Google Play. No seu arquivo de módulo build.gradle, adicione a seguinte linha à seção de dependências:

Os serviços da API SafetyNet tem muito mais recursos, incluindo a API de Navegação Segura que verifica URLs para ver se elas foram marcadas como uma ameaça conhecida e uma API reCAPTCHA  para proteger seu aplicativo contra spammers e outros tipos de tráfego malicioso.

Depois que você sincronizar o Gradle, você pode chamar o método installIfNeededAsync do ProviderInstaller:

O método onProviderInstalled() é chamado quando o provedor é atualizado com êxito, ou já está atualizado. Caso contrário, é chamado  onProviderInstallFailed(int errorCode, Intent recoveryIntent).

Certificado e Fixação de Chave Pública

Quando você faz uma conexão HTTPS com um servidor, um certificado digital é apresentado pelo servidor e validado pelo Android para certificar-se de que a conexão é segura. O certificado pode ser assinado com um certificado de uma autoridade certificadora mediadora. Esse certificado usado pela autoridade mediadora pode, por sua vez, ser assinado por outra autoridade mediadora, e assim por diante, o que é confiável, desde que o último certificado seja assinado por uma autoridade de certificação raiz que já seja considerada confiável pelo sistema operacional Android.

Se qualquer um dos certificados da cadeia de confiança não for válido, então a conexão não é segura. Embora este seja um bom sistema, não é infalível. É possível para um invasor instruir o sistema operacional Android para aceitar certificados personalizados. Proxies de interceptação podem possuir um certificado confiável, e se o dispositivo é controlado por uma empresa, a empresa pode ter configurado o dispositivo para aceitar seu próprio certificado. Esses cenários permitem um ataque "man in the middle", permitindo que o tráfego HTTPS seja descriptografado e lido.

A fixação de certificados é solucionada ao verificar o certificado do servidor que é apresentado contra uma cópia do certificado esperado. Isso evita que conexões sejam feitas quando o certificado é diferente do esperado.

Para implementar a fixação no Android N ou superior, você precisa adicionar um hash (chamado de pin) do certificado no arquivo network_security_config.xml. Aqui está um exemplo de implementação:

Para encontrar os pins para um site específico, você pode ir aos SSL Labs, entrar no site e clicar em Submit. Ou, se você estiver desenvolvendo um aplicativo para uma empresa, você pode pedir a empresa que faça isso.

Nota: Se você precisar oferecer suporte a dispositivos executando uma versão do sistema operacional mais antigo que o Android N, você pode usar a biblioteca TrustKit. Ela utiliza o arquivo Network Security Configuration exatamente da mesma forma.

Sanitização e Validação

Com todas as proteções até agora, suas conexões devem estar bastante seguras. Mesmo assim, não se esqueça da validação regular de programação. Não é seguro confiar cegamente em dados recebidos da rede. Uma boa prática de programação é o "design por contrato", onde as entradas e saídas de seus métodos satisfazem um contrato que define as expectativas específicas de interface.

Por exemplo, se seu servidor está esperando uma sequência de caracteres de 48 caracteres ou menos, certifique-se que a interface só retornará até 48 caracteres.

Se você está apenas esperando números do servidor, suas entradas devem verificar isto. Enquanto isso ajuda a evitar erros inocentes, também reduz a probabilidade de ataques de injeção e de corrupção de memória. Isto é especialmente verdadeiro quando os dados são passados para NDK ou JNI — código C e C++ nativo.

O mesmo é verdadeiro para o envio de dados para o servidor. Não envie dados cegamente, especialmente se forem gerados pelo usuário. Por exemplo, é recomendável limitar o comprimento da entrada do usuário, especialmente se ela será executada por um servidor SQL ou qualquer tecnologia que irá executar o código.

Embora proteger um servidor contra ataques esteja além do escopo deste artigo, como um desenvolvedor móvel, você pode fazer sua parte, removendo caracteres para a linguagem que o servidor está usando. Dessa forma, a entrada não é suscetível a ataques de injeção. Alguns exemplos são remoção de aspas, ponto e vírgula e barras, quando eles não são essenciais para a entrada do usuário:

Se você sabe exatamente o formato que é esperado, você deve verificar  isto. Um bom exemplo é a validação de e-mail:

Arquivos também podem ser verificados. Se você está enviando uma foto para o seu servidor, você pode verificar se é uma foto válida. Os primeiros dois bytes e os últimos dois bytes são sempre FF D8 e D9 FF para o formato JPEG.

Tenha cuidado ao exibir um alerta de erro que mostra diretamente uma mensagem do servidor. Mensagens de erro podem divulgar depuração privada ou informações relacionadas à segurança. A solução é fazer com que o servidor envie um código de erro que o cliente procura para mostrar uma mensagem predefinida.

Comunicação com Outros Aplicativos

Enquanto você está protegendo a comunicação de e para o dispositivo, é importante proteger o IPC também. Há casos onde os desenvolvedores tem deixado arquivos compartilhados ou implementaram sockets para troca de informações confidenciais. Isto não é seguro. É melhor usar Intents. Você pode enviar dados usando uma Intent, fornecendo o nome de pacote como este:

Para transmitir dados para mais de um app, você deve impor que apenas aplicativos assinados com sua chave de assinatura receberão os dados. Caso contrário, as informações enviadas podem ser lidas por qualquer aplicativo que se registre para receber a transmissão. Da mesma forma, um aplicativo mal-intencionado pode enviar uma transmissão para seu aplicativo se você se registrou para receber a transmissão. Você pode usar uma permissão ao enviar e receber transmissões onde a assinatura é usada como protectionLevel. Você pode definir uma permissão personalizada no arquivo manifest, como esta:

Então, você pode conceder a permissão assim:

Ambos os apps precisam ter as permissões no arquivo de manifesto para funcionar. Para enviar a transmissão:

Como alternativa, você pode usar setPackage(String) ao enviar uma transmissão para restringi-la a um conjunto de aplicativos que correspondam ao pacote especificado. Configurar android:exported para false no arquivo manifest excluirá transmissões recebidas de fora do seu aplicativo.

Criptografia de Ponta a Ponta

É importante compreender os limites do HTTPS para proteger comunicações de rede. Na maioria das implementações de HTTPS, a criptografia é encerrada no servidor. Por exemplo, sua conexão ao servidor de uma empresa pode ser via HTTPS, mas uma vez que o tráfego atinge o servidor, é descriptografado. Ele pode então ser encaminhado para outros servidores, estabelecendo outra sessão HTTPS ou enviando-o sem criptografia. A corporação é capaz de ver a informação que tenha sido enviada, e na maioria dos casos isso é uma exigência para as operações de negócios. No entanto, isso também significa que a empresa poderia passar as informações para terceiros sem criptografia.

Há uma tendência recente chamada "criptografia end-to-end", onde apenas os dois  dispositivos  de comunicação finais podem ler o tráfego. Um bom exemplo é um aplicativo de bate-papo criptografado onde dois dispositivos móveis estão se comunicando com o outro através de um servidor; apenas o remetente e o receptor podem ler mensagens do outro.

Uma analogia para ajudar você a entender a criptografia de ponta a ponta é imaginar que você quer que alguém lhe envie uma mensagem que só você pode ler. Para fazer isso, você fornecer-lhe uma caixa com um cadeado aberto nela (chave pública) enquanto você mantém  a chave do cadeado (chave privada). O usuário grava uma mensagem, coloca-a na caixa, fecha o cadeado e envia-a para você. Só você pode ler a mensagem, porque você é o único com a chave para abrir o cadeado.

Com a criptografia de ponta a ponta, ambos os usuários enviam uns aos outros as suas chaves. O servidor fornece apenas um serviço de comunicação, mas ele não pode ler o conteúdo da comunicação. Embora os detalhes da implementação estejam além do escopo deste artigo, é uma tecnologia poderosa. Se você quiser saber mais sobre essa abordagem, um ótimo lugar para começar é o repositório do GitHub para o projeto open-source Signal.

Conclusão

Com todas as novas leis de privacidade como GDPR, a segurança é cada vez mais importante. Muitas vezes é um aspecto negligenciado do desenvolvimento de aplicativos móveis.

Neste tutorial, você observou as melhores práticas de segurança, incluindo o uso de HTTPS, fixação de certificado, sanitização de dados e criptografia de ponta a ponta. Estas práticas devem servir como uma base para a segurança ao desenvolver seu aplicativo móvel. Se você tiver alguma dúvida, sinta-se livre para deixá-las abaixo e enquanto você está aqui, confira alguns dos meus outros tutoriais sobre segurança de apps Android!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.