Artigo
06/14/2018

Maio de 2018

Volume 33, Número 5

Segurança - Detectar e Responder aos Dispositivos Android na raiz dos Aplicativos Xamarin

Problema de novembro último, eu ilustrado como você pode usar verificações de tempo de execução, uma injeção de código recurso incluído com o Visual de 2017 Studio, para proteger seus aplicativos do .NET Framework contra uso não autorizado de um depurador, bem como contra violação (msdn.com/magazine / mt845626). Desde então, um novo tipo de verificação foi disponibilizada. A verificação de raiz detecta quando um aplicativo xamarin está em execução em um dispositivo de "raiz", que permite que aplicativos comuns funcionar com permissões de administrador (acesso raiz).

Neste artigo de acompanhamento, explicarei por que dispositivos com raiz representam um risco de que todos os desenvolvedores do Android devem entender; detalha como xamarin os desenvolvedores podem usar raiz verifica para detectar e responder a esse risco; e demonstram práticas recomendadas com um cenário de exemplo.

Por que você precisa proteger contra raiz

A plataforma Xamarin permite a criação eficiente de aplicativos móveis para dispositivos Windows, iOS e Android. Os desenvolvedores familiarizados com linguagens .NET como c# podem assumir esse conhecimento e aplicá-lo para o espaço móvel. Tecnologias como xamarin. Forms abstraem muitos afastam as diferenças entre plataformas, reduzindo a complexidade e o custo e o risco de desenvolvimento de aplicativos de plataforma cruzada. Ao manter suas ferramentas Xamarin atualizado, você pode continuar dar suporte a novas versões e recursos de cada plataforma.

No entanto, alguns aspectos específicos da plataforma de desenvolvimento móvel merecem atenção do desenvolvedor. Um aspecto essa é a segurança. Cada plataforma tem riscos de segurança exclusivos e um modelo de segurança exclusivo para tratar esses riscos. Por exemplo, os sistemas de permissão diferem entre plataformas e às vezes até mesmo entre as versões da mesma plataforma.

Para aplicativos Android, dispositivos com raiz são uma preocupação de segurança particularmente importantes. Esses dispositivos foram modificados para permitir que os aplicativos interromper a proteção de segurança normal que impõe o sistema operacional. Isso pode expor o dispositivo muitos perigos, como malware e keyloggers roubo de senhas. Muitas vezes, os usuários raiz seus dispositivos para resolver um problema — como precisando de uma versão de um aplicativo que não está disponível para seu dispositivo, sem perceber a severidade dessas ameaças. Em outros casos, um usuário não pode até estar ciente de que o dispositivo tem raiz e, portanto, vulnerável.

Última setembro, o pagamento cartão setor Security Standards Council (PCI SSC) emitido versão 2.0, o Mobile pagamento aceitação de diretrizes de segurança para desenvolvedores. Para combater os riscos de segurança associados com dispositivos, as diretrizes recomendam os desenvolvedores de aplicativos móveis implementam detecção de raiz e um mecanismo de resposta para o aplicativo de quarentena (bit.ly/2H5ymge). Aqui está o texto relevante da seção 4.3 (ênfase adicionada):

[T] dispositivo deve ser monitorado para atividades que anular controls—e.g de segurança do sistema operacional., jailbreaking ou raiz, e, quando detectado, o dispositivo deve ser colocado em quarentena por uma solução que remove da rede, remove a aceitação de pagamento aplicativo do dispositivo, ou desativa a aplicação de pagamento. Detecção de jailbreak e raiz offline e quarentena automática são fundamentais porque alguns os invasores podem tentar colocar o dispositivo em um estado offline de desviar da detecção mais.

Além de riscos associados a um usuário legítimo operacional o aplicativo em um ambiente com raiz, um ambiente desse tipo também pode indicar um usuário mal-intencionado tentando fazer o aplicativo de engenharia reversa. Os invasores frequentemente usar dispositivos com raiz para estudar e criar violadas versões de aplicativos, que, em seguida, preenchimento com malware. O projeto segurança de aplicativo de Web aberta (OWASP) lista o código de violação como um dos riscos Top 10 Mobile (bit.ly/2GNbd4o) e especificamente chamadas de detecção de raiz e a resposta como uma maneira para combater esse risco. Se não fizer isso, de acordo com OWASP, pode levar a danos à reputação e lucros cessantes.

Verificações de raiz

Detectando dispositivos raiz pode ser um desafio. Um dispositivo pode ser modificado usando várias técnicas diferentes, e o conjunto de técnicas disponíveis alterações ao longo do tempo e em versões do Android. Como resultado, o código de detecção de raiz deve evoluir e adaptar constantemente. Isso se deve ao fato de que algumas técnicas de raiz no mal-intencionado tentam ocultar seu uso, portanto o código de detecção de raiz bom também deve resolver esses contramedidas. Manter o código de detecção de raiz atualizado é difícil e não pode ser onde você desejar gastar seus recursos limitados.

Felizmente, você não precisa escrever seu próprio código para detectar a raiz. Proteção preemptiva - Dotfuscator Community Edition (CE), que está incluído no Visual Studio de 2017 para Windows, pode injetar raiz verifica seus aplicativos xamarin. Raiz verifica detectar ambientes com raiz, mesmo quando o dispositivo estiver offline. Além de uma ação padrão "sair do aplicativo", você pode configurar as verificações para responder a raiz chamando personalizadas de código do aplicativo.

Assim como Xamarin em si, raiz verifica reduzir a complexidade, o custo e o risco em comparação ao fazer sua própria implementação. Manter Dotfuscator atualizados e deixá-lo a lidar com a detecção de raiz — voltar a trabalhar nas partes interessantes do seu aplicativo mais rápido.

Cenário de exemplo

Para demonstrar raiz verifica, fornecidas um aplicativo de exemplo chamado TodoAzureAuth protegidos. Ela se baseia em uma amostra de xamarin. Forms existente, TodoAzureAuth (bit.ly/2InvU48) originalmente escrito por David Britch.

O restante deste artigo explica o aplicativo, a estratégia de proteção apliquei a ele, e como apliquei essa estratégia com verificações de raiz. Você pode usar este estudo de caso, bem como os cenários adicionais incluídos no repositório do GitHub do exemplo (bit.ly/2GQutOv), para saber mais abordagens para raiz verifica você pode aplicar aos seus próprios aplicativos xamarin.

Exemplo: TodoAzureAuth original se conecta a uma instância de aplicativo móvel do Microsoft Azure, permitindo que os usuários exibir e modificar uma lista de tarefas compartilhada. Para demonstrar como realizar a autenticação em um aplicativo Xamarin, o exemplo requer que o usuário fazer logon com uma conta do Google antes de acessar a lista de tarefas.

O aplicativo começa na página de logon, que não tem campos, apenas um botão de logon. Quando o usuário seleciona esse botão, o aplicativo delega o processo de logon para o sistema de OAuth do Google, que pode exigir que o usuário insira credenciais, incluindo uma senha. Como resultado, o aplicativo em si não lidar com as credenciais. Quando o usuário tiver conectado, o aplicativo exibe a página da lista de tarefas, permitindo que o usuário acesse a lista de tarefas compartilhada. O usuário pode fazer logoff e retornar à página de logon, selecionando o botão de Logout.

Estratégia de proteção: Neste artigo, eu tratado o projeto TodoAzureAuth Android, TodoAzure.Droid, como se ele estivesse tratando dados confidenciais, como faria de um aplicativo compatível com o PCI. Implementei uma estratégia de proteção adequadas usando Dotfuscator CE para injetar uma verificação de raiz do aplicativo, produzindo uma versão protegida do aplicativo, TodoAzureAuth protegidos.

O aplicativo protegido, quando o usuário seleciona o botão de logon, a verificação de raiz ativa. Se o aplicativo estiver em execução em um dispositivo com raiz, ele será encerrado abruptamente e todas as outras tentativas de executar o aplicativo também serão fechado depois que uma mensagem de erro curta, mesmo se o dispositivo não tem raiz. Figura 1 mostra uma visão geral do aplicativo protegido por essa estratégia.

Figura 1 Visão geral do aplicativo de exemplo TodoAzureAuth protegido

Essa estratégia está de acordo com as recomendações feitas pelas diretrizes PCI, citadas anteriormente:

O aplicativo monitora o dispositivo para a raiz.
O aplicativo colocar em quarentena o dispositivo desabilitando si mesmo se raiz for detectado.
Esse controle de segurança funciona mesmo quando o dispositivo estiver offline.

Quando o aplicativo desabilita a mesmo, os alertas de mensagem de erro o usuário que o dispositivo é seguro. Apesar de não usado no exemplo, um aplicativo usando esse cenário pode também "phone home" para uma plataforma de análise, como o Centro de aplicativo do Visual Studio (bit.ly/2pYMuk5).

Além de seguir as diretrizes PCI, essa estratégia também alinhado com a recomendação de OWASP para desligar o aplicativo em um ambiente com raiz para evitar a engenharia reversa. Configurei a verificação de raiz para ativar a outras partes no código, não apenas o processo de logon, para que se um invasor produz uma versão violada do aplicativo com detecção de raiz do processo de logon removida, outras partes do aplicativo ainda possam reagir a raiz. Dotfuscator ofuscado também o código adicionando outra camada de proteção para o aplicativo e a verificação de raiz.

Nem todos os aplicativos têm os mesmos requisitos de segurança e, portanto, nem todos os aplicativos devem reagir a raiz da mesma maneira. Escolhi uma abordagem estrita para o exemplo, mas uma estratégia mais branda pode permitir que o aplicativo ser executado em dispositivos com raiz em determinadas circunstâncias. Para obter um exemplo, consulte "Uma alternativa estratégia de proteção".

Protegido por exemplo: Você pode exibir o exemplo TodoAzureAuth protegidos usando o link do GitHub fornecido anteriormente. Na ramificação mestre padrão, eu já tiver configurado a CE Dotfuscator para proteger TodoAzure.Droid com uma verificação de raiz para que o aplicativo atenda a estratégia explicada anteriormente. Você pode seguir o histórico de Git, começando com o branch de verificações de antes, para ver como apliquei as etapas neste artigo para o exemplo.

Consulte o Leiame do exemplo para obter detalhes sobre como configurar, compilar e executar o exemplo. O arquivo Leiame também inclui detalhes sobre outras ramificações presentes no repositório que demonstram estratégias de proteção diferente daquele usado neste artigo, como a estratégia detalhada em "Uma alternativa estratégia de proteção".

Compilações de integração Dotfuscator Xamarin

Como o Dotfuscator opera em assemblies .NET (arquivos. dll e .exe), plataforma móvel não formatos, como pacotes do Android (arquivos. Apk), tive Dotfuscator integrar o processo de build Xamarin. Configurando a integração requer instalar e registrar Dotfuscator CE, download de um arquivo de destinos do MSBuild especializado e modificando o arquivo de projeto para incluir os destinos. Eu escrevi sobre como executar essas etapas de integração para o Blog do Xamarin, portanto, consulte as instruções em bit.ly/2w9em6c.

Observação importante: Raiz verifica exigem Dotfuscator CE versão 5,35 ou posterior para 2017 do Visual Studio. Você sempre pode obter a versão mais recente no bit.ly/2fuUeow.

Segui as instruções de Xamarin Blog para proteger a versão do arquivo de projeto TodoAzure.Droid | Configuração de build AnyCPU. Este artigo aborda apenas a este projeto Android porque verifica raiz são um recurso específico do Android, mas você também pode seguir as instruções do Xamarin Blog para proteger o iOS e Windows UWP (plataforma Universal) com ofuscação de código.

Configurando a proteção Dotfuscator

Depois que eu integrado Dotfuscator no processo de compilação do projeto TodoAzure.Droid, configurei a proteção por meio da interface do usuário do Dotfuscator CE. As configurações de proteção de um projeto são salvos em um arquivo de configuração Dotfuscator especializado, que a integração de compilação adiciona ao seu projeto na primeira vez que ele cria.

Criando o arquivo de configuração Dotfuscator: Usando o Visual Studio de 2017, criei o TodoAzure.Droid configuração para a plataforma AnyCPU, que é a configuração que tenha definido para usar Dotfuscator de compilação de projeto na versão. Isso produziu um novo Dotfuscator arquivo de configuração, DotfuscatorConfig.xml, no diretório do projeto. Adicionei esse novo arquivo ao controle de origem, pode personalizar e reaplique a proteção com base em que a personalização posterior.

A compilação também criou um diretório de DotfuscatorReports no meu diretório de projeto, que é onde o Dotfuscator grava vários arquivos de relatório quando ele é executado como parte da integração. Porque o conteúdo do diretório atualiza todas as compilações, tive meu controle do código-fonte ignorar esse diretório.

Abertura Dotfuscator: Para personalizar o arquivo de configuração Dotfuscator, abri CE Dotfuscator interface do usuário do Visual Studio de 2017 escolhendo Ferramentas | Proteção preemptiva - Dotfuscator. Na UI Dotfuscator exibida, escolhi arquivo | Abra o projeto, navegar até o diretório do projeto TodoAzure.Droid e selecionado DotfuscatorConfig.xml, o arquivo de configuração Dotfuscator. A UI Dotfuscator atualizado para exibir esse arquivo de configuração Dotfuscator protege dois assemblies: TodoAzure.Droid.dll em si e o assembly (PCL) da biblioteca de classes portátil TodoAzure.dll.

Tenha em mente que a opção de criar o projeto na UI Dotfuscator não executa etapas de empacotamento do Xamarin. Para garantir que o pacote Android contém os assemblies protegidos, compile o projeto do Visual Studio ou o MSBuild, em vez disso.

Ativando a injeção de código: As verificações são parte dos recursos de injeção de código Dotfuscator. Para habilitar a injeção de código, eu pequeno o nó de injeção na barra de navegação Dotfuscator e marcada a opção Enable. Cor do texto do nó injeção alterado de cinza para preto, indicando que a injeção foi habilitada.

Exibindo configurado verificações: A página Dotfuscator verifica exibe uma lista de todas as verificações configuradas para um arquivo de configuração carregado, neste caso DotfuscatorConfig.xml no projeto TodoAzure.Droid. Para exibir esta página, eu selecionado o nó de injeção e alternar para a guia de verificações.

Quando eu visitada primeiro essa lista, estava vazia. Depois de configurado, verificar uma nova raiz, como explicarei na próxima seção, a lista atualizada para incluir uma linha para essa verificação, como visto no Figura 2. Pode exibir a configuração para a seleção clicando duas vezes em que a linha.

Figura 2 o Dotfuscator verifica a página, mostrando uma verificação de raiz

Observe que você pode configurar mais de uma verificação de raiz para um único arquivo de configuração Dotfuscator, embora não fazer isso para este artigo. Para obter um exemplo de um aplicativo protegido por várias verificações, consulte o aplicativo AdventureWorksSalesClient .NET Framework que escrevi sobre novembro passado.

Adicionando uma verificação de raiz

Página de verificações, adicionei uma verificação de raiz clicando no botão Adicionar seleção de raiz. Quando foi feito, Dotfuscator exibida uma nova janela para configurar a nova verificação. Figura 3 mostra a configuração terminar; esta seção explica o significado de cada configuração e por que escolhi essas configurações.

Figura 3 configuração da verificação de raiz — locais adicionais ocultados pelo nó TodoAzure.dll recolhido

Locais: Cada seleção está associada um ou mais métodos no aplicativo, chamado locais. Quando o aplicativo chama um método desses, a verificação de raiz ativa, detectando no momento, se o dispositivo parece ter raiz. Depois de executar todos os configurado a funcionalidade de emissão de relatórios e resposta, supondo que essas medidas não sair do aplicativo, a seleção retorna o controle para a parte superior do método.

Para a seleção deste cenário, selecionei vários locais. O local usado pela primeira vez no aplicativo é TodoAzure.Droid.MainActivity.AuthenticateAsync, que coordena a uma solicitação de logon. Usando este local significa que a verificação de raiz executará sua detecção e a resposta sempre que inicia o processo de logon.

Por que a estratégia de proteção, um aplicativo em execução em um dispositivo com raiz é encerrado quando atingir primeiro o método AuthenticateAsync. Então por que adicionar outros métodos que ocorrem posteriormente no ciclo de vida do aplicativo como locais adicionais? Isso é para ajudar a proteger contra a engenharia reversa o aplicativo. Se um invasor cria uma versão violada do aplicativo que ignora ou remove o código de verificação de raiz no AuthenticateAsync, esses outros locais ainda poderá reagir a um ambiente com raiz.

Alguns desses locais adicionais são definidos em TodoAzure.dll. Isso pode ser surpreendente, como o assembly contém lógica comuns a todas as plataformas de Xamarin, não apenas Android. Como pode Dotfuscator injetar uma verificação de raiz — que detecta raiz Android dispositivos — em um assembly independente de plataforma? Lembre-se de que esse arquivo de configuração Dotfuscator é específico para o projeto TodoAzure.Droid que referencia o projeto TodoAzure. Quando Dotfuscator modifica TodoAzure.dll, ele irá modificar apenas o assembly que o Visual Studio ou cópias de MSBuild para usam no projeto atual, TodoAzure.Droid. Assembly do projeto TodoAzure original permanece inalterado.

Notificação do aplicativo: Verificações podem relatar os resultados de sua detecção para o código do aplicativo. Isso permite que você personalizou comportamentos de emissão de relatórios e resposta, enquanto a ter as verificações injetados pelo identificador Dotfuscator o trabalho de detecção. O código do aplicativo que recebe o resultado de detecção é chamado de um aplicativo do coletor de notificação.

Para atender a estratégia de proteção nesse cenário, eu precisava ter o aplicativo desabilitar em si, para que execuções futuras do aplicativo de saída com uma mensagem de erro. Escolhi adicionar isso desabilitação lógica em um método, TodoAzure.App.DisableIfCompromised, e usá-lo como coletor a verificação, definindo as seguintes propriedades de verificação:

ApplicationNotificationSinkElement: O tipo de elemento de código; Nesse caso, um método.
ApplicationNotificationSinkName: O nome simples do elemento de código; Nesse caso, DisableIfCompromised.
ApplicationNotificationSinkOwner: O tipo que contém o elemento de código; Nesse caso, TodoAzure.App.

Qualquer um dos locais de verificação pode chamar esse método de coletor conforme ele é público e estático. Para ser compatível com uma seleção, o método é síncrona (não assíncronas), aceita um argumento único bool e tem um tipo de retorno void.

Quando ativado, a verificação chama o método, passando o verdadeiro argumento se o dispositivo tem raiz e FALSO caso contrário. Quando esse argumento é verdadeiro — ou seja, quando a verificação detecta raiz — o método salva um valor para o armazenamento local, indicando que o aplicativo está desabilitado agora. Uma propriedade associada, IsDisabled, expõe o valor salvo:

// Definitions in TodoAzure.App
private const string DisabledPropertyKey = "AppStatus";
public static void DisableIfCompromised(bool wasCompromised)
{
  if (!wasCompromised) { return; }
  Current.Properties[DisabledPropertyKey] = new Random().Next();
  SavePropertiesNow();
}
public static bool IsDisabled =>
  Current.Properties.ContainsKey(DisabledPropertyKey);

Depois que o aplicativo está desabilitado, execuções futuras necessário mostrar uma mensagem de erro e a saída. Para fazer isso, eu substitui TodoAzure.LoginPage.OnAppearing, que é chamado logo antes da página de logon é mostrada quando o aplicativo for iniciado. Se o aplicativo estiver desabilitado, esse método oculta a página de logon, exibe uma caixa de diálogo de erro e, em seguida, sai.

// Definition in TodoAzure.LoginPage
protected override async void OnAppearing()
{
  if (App.IsDisabled)
  {
    IsVisible = false;
    var message = "The security of this device has been compromised. "
      + " The app will exit.";
    await DisplayAlert("App deactivated", message, "Exit App");
    App.Exit(); // Delegates to platform-specific exit logic
  }
  base.OnAppearing();
}

Como também quero proteger contra a engenharia reversa, fizemos medidas adicionais para garantir que o aplicativo seria mais resiliente a esse ataque. Eu usou um nome vago para o valor salvo, AppStatus e defina o valor como um número aleatório que obscurece o significado do valor. Também configurei Dotfuscator para ofuscar o aplicativo, renomeando identificadores como DisableIfCompromised, para que um invasor exibindo código descompilado não identificará facilmente este método como sendo de interesse. Para obter detalhes sobre como configurei ofuscação de renomeação, consulte o Leiame do exemplo.

Ação: Enquanto o coletor (o método DisableIfCompromised) define uma propriedade para garantir que as execuções futuras do encerramento do aplicativo, ele não se sair do aplicativo quando raiz é detectada pela primeira vez. Em vez disso, configurei a verificação para fazer isso automaticamente, definindo a propriedade de verificação de ação para sair.

Quando a verificação detecta um dispositivo de raiz, ele notifica o coletor e imediatamente encerra o aplicativo. Fazendo com que a verificação, em vez de coletor, execute essa saída inicial, se espalhar várias cópias da lógica de saída por meio do aplicativo. Assim como ocorre com vários locais, várias cópias da lógica de saída permitem que o aplicativo para melhor se defender quando um invasor tem removido algumas das verificações de raiz.

Compilar e testar o aplicativo

Depois de configurar a verificação de raiz, foi encerrado a janela de verificação selecionando Okey, em seguida, salvei minhas alterações ao arquivo de configuração Dotfuscator escolhendo arquivo | Salve o projeto. Criei TodoAzure.Droid no Visual Studio para testar o aplicativo protegido, para verificar se eu configurado corretamente a verificação de raiz para impor a estratégia de proteção desejado.

Testei o aplicativo em um dispositivo não raiz, em um dispositivo com raiz e em um emulador. No dispositivo não raiz, o aplicativo funcionava normalmente, permitindo que eu entrar para exibir a lista de tarefas pendentes. No entanto, no dispositivo com raiz e no emulador, depois de selecionar o botão de logon, o aplicativo abruptamente fechada. Depois de executar novamente o aplicativo, o aplicativo exibida a caixa de diálogo de erro mostrada na Figura 4; depois de fechar a caixa de diálogo, o aplicativo foi encerrado mais uma vez. Para exibir a página de logon novamente, tive desinstalar e reinstalar o aplicativo.

Figura 4 o TodoAzure.Droid protegido em execução no emulador

Conclusão

Espero que este artigo ajudou a acender uma maneira de detectar de maneira eficiente e responder à raiz dispositivos Android usando ferramentas gratuitas incluídas com o Visual Studio. Embora eu tenha usado um aplicativo de exemplo conhecido como referência, você pode aplicar as ideias apresentadas neste artigo para todos os tipos de aplicativos xamarin e várias outras estratégias de proteção.

Se você estiver interessado em aprender mais sobre as verificações, é recomendável ler o artigo da MSDN Magazine anterior. Nela, discutido tipos adicionais de verificação que você pode aplicar a aplicativos do .NET Framework e como usar verifica pode impedir violações de dados.

Você também pode estar interessado em recursos avançados de verificação e ofuscação do Dotfuscator Professional Edition (bit.ly/2xgEZcs) ou a ferramenta complementar para Java e tradicionais aplicativos Android, proteção preemptivo - DashO (bit.ly/2ffHTrN). Você pode manter atualizado com todas as melhorias no verificações e proteção preemptivo seguindo preemptivo soluções no Twitter (twitter.com/preemptive) e visite nosso blog (preemptive.com/blog).

Uma estratégia de proteção alternativo

Este artigo apresenta uma estratégia para detectar e responder a raiz de dispositivos, mas outras estratégias também são possíveis. A estratégia que você escolher deve ser apropriada para seu aplicativo, o contexto no qual seu aplicativo é usado e os riscos de segurança você deseja endereço. Você pode aplicar raiz verifica para implementar a estratégia escolhida. Por exemplo, se seu aplicativo não deve ser encerrado em nenhuma circunstância, você pode configurar uma verificação de raiz para desabilitar alguns recursos quando raiz é detectado, em vez de saindo do aplicativo.

Um único aplicativo ainda pode precisar reagir a raiz de maneiras diferentes dependendo informações conhecidas em tempo de execução. Considere um aplicativo disponível em várias regiões geográficas. A resposta do aplicativo para raiz talvez precise variam por região de acordo com as leis locais e os regulamentos, especialmente se essa resposta inclui a enviar relatórios de incidentes para o desenvolvedor ("transmita para casa").

Ao desenvolver uma estratégia de proteção, você também deve considerar o impacto que terá sua estratégia dos usuários do seu aplicativo que intencionalmente ter modificado seus dispositivos de boa-fé. Esses usuários"power" podem ser uma parte significativa da sua base de clientes e a desabilitação de dispositivos com raiz pode baixá-los para fora de seu aplicativo. Você precisa avaliar os riscos de segurança associados com dispositivos contra os riscos de negócios associados ficando exposta à perda usuários legítimos de tais dispositivos.

Neste artigo, eu assumido que TodoAzure.Droid tratados dados confidenciais e, assim, para impedir o roubo de dados e fazer engenharia reversa, com os dispositivos devem estar totalmente proibidos. Se, em vez disso, tinha tratados os dados como não sensíveis, poderia implementei uma estratégia de proteção que permite que os dispositivos com raiz em certas circunstâncias, tornando o aplicativo mais acessível para usuários avançados. Essa estratégia alternativo, em vez do aplicativo desabilitando em si, o aplicativo avisa o usuário quando um dispositivo de raiz é detectado. Esse aviso garante que o usuário está ciente do status do dispositivo e riscos associados inseguro como roubo de credenciais. O usuário pode escolher cancelar a tentativa de logon ou aceitar os riscos e continuar a fazer logon.

Na ramificação do repositório do GitHub protegidos TodoAzureAuth Avisar usuários, configurei Dotfuscator CE para proteger TodoAzure.Droid com uma verificação de raiz que implementa essa estratégia de proteção alternativo. O arquivo Leiame na ramificação explica os pontos mais refinados da configuração.

Observe que essa estratégia alternativa faz uma compensação entre a ameaça de engenharia reversa e acessibilidade para usuários avançados. Sob essa estratégia, atores ruins ainda poderá instalar o aplicativo em um dispositivo com raiz para fins de engenharia reversa; a caixa de diálogo de aviso não interrompê-los. Usei ainda Dotfuscator a ofuscar o aplicativo, fornecendo um grau de proteção de engenharia reversa. Um aplicativo real pode implementar controles adicionais, como exigir autenticação especial para usar o aplicativo em um dispositivo com raiz.

A Figura mostra o aviso exibido pelo aplicativo quando executado em um dispositivo com raiz.

Figura um TodoAzure.Droid, protegido por essa estratégia alternativa, em execução no emulador, depois que o usuário seleciona o botão de logon

Joe Sewellé um engenheiro de software e escritor técnico equipe Dotfuscator soluções preemptivo. Ele escreveu anteriormente da MSDN Magazine e o Blog oficial da Xamarin.

Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: David Britch
David Britch trabalha no grupo de documentação Xamarin na Microsoft. Escreveu para uma variedade de publicações de desenvolvimento de software, incluindo manuais, documentação de orientação, implementações de referência, white papers, vídeos e instrutor de cursos

Compartilhar via