Garantir que somente a minha App acesse meu webservice

[Carlos H. F. M. Rodrigues]

Pessoal estou pesquisando uma solução para um situação.

Garantir que somente minha App acesse meu Webservice, sendo que meu App é de utilidade publica (Informações de linhas de ônibus e comerciais da cidade onde moro) não será obrigatório login por facebook e gmail.

Cenário: 

1 - No meu Webservice consigo validar o HTTP_USER_AGENT, validando somente requisições de SmarthPhone.

(http://www.newmediacampaigns.com/blog/three-ways-to-target-mobile-devices)

2 - Se colocar um Hash Token no meu App para acessar meu WebService, uma engenharia reversa já quebraria isso. (http://pt.stackoverflow.com/questions/34899/como-fazer-engenharia-reversa-de-um-aplicativo-android)

Se vocês poderem dar sugestão de segurança do que e como eu poderia garantir que somente a minha App acesse meu webservice.

[Diego Rocha]

UserAgent também é mascarável, posso escrever um programa em qualquer linguagem que fará uma requisição passando o mesmo UserAgent do smartphone.

Se você colocar um certificado ssl e só permitir acesso ao WS por https poderá usar o Token sem riscos de engenharia reversa (em tese hahahha).

Atenciosamente,

Diego Rocha

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jhosef Marks]

Gera um token dinâmico pra cada requisição com tempo de expiração...

Pode somar um token seu, mais a data e alguma outra coisa e no ws valida antes de devolver uma resposta...

OAuth tbem pode ser uma opção.

Att,

Jhosef Marks de Carvalho

Celular: (47) 9708-6420

skype: jhosef.marks
Twitter: @jhosefmarks

[Eduardo Baião]

Joshef, a sugestão do token dinâmico funciona bem quando a aplicação exige que usuário se autentique. E numa aplicação onde isso não seja uma exigência?

[Thiago Silva]

Se só sua aplicação pode acessar o WS de uma forma ou de outra isso é um tipo de autenticação. A diferença é que não é autenticação por usuário e sim por aplicação, é um escopo bem mais amplo. 

Como dito pelo Jhosef eu criaria um esquema de Token.

O Eduardo comentou que isso se aplicaria para autenticação de usuário, mas a questão em discussão não deixa de ser um tipo de autenticação.

Eu ficaria com Token.

Att.

Thiago Silva

Desenvolvedor - Rerum Engenharia de Sistemas.

[Diego Rocha]

Baião, a forma como ele sugeriu já é funcional sem login.
O app ao enviar a requisição gera o token seguindo uma fórmula única que ele vai inventar, essa forma leva em consideração o horário atual. Um token usado é inutilizado, outra requisição gera outro token
O servidor ao receber, valida o horário da requisição ou se o token já foi utilizado e se for antigo sabe que é fraude (alguém capturou um token antigo e quer usar de novo).

O complicado dessa abordagem é achar uma fórmula pra gerar o token que não seja fácil de sofrer engenharia reversa, ao mesmo tempo que o servidor precisa faze-lo.

Acredito que HTTPS seja a melhor saída pois eles já lidam com chaves assimétricas, e em tese, ninguém conseguiria ver nenhum cabeçalho das requisições.
Então você poderia usar um token fixo, ou um qualquer outra validação específica que não seja de ida-e-volta, já que dá pra supor que ninguém conseguirá achar esse token analizando a rede.

Atenciosamente,

Diego Rocha

2015-03-17 14:45 GMT-03:00 Eduardo Baião <eduard...@gmail.com>:

[Eduardo Baião]

Entendi Diego e Thiago.

É que estou partindo do pressuposto de que alguém inevitavelmente irá fazer a engenharia reversa, tendo com isso acesso ao algoritmo que gera o token.

Para este caso, ainda não encontrei uma solução.

[Diego Rocha]

Mesmo com o HTTPS acha que vão conseguir engenharia reversa?! Só o OBAMA pra pegar pela rede. Ou através de descompilar o apk e achar as strings fixas e coisas do tipo... Mas dá pra ofuscar isso com o ProGuard

Atenciosamente,

Diego Rocha

[Eduardo Baião]

Hehehe.

Eu estava falando da descompilação.

O ProGuard resolve 100%?

[Neto Lobo]

Estou na mesma situação sua Carlos, nas minhas pesquisa encontrei esse site, vê se te ajuda https://stormpath.com/blog/secure-your-rest-api-right-way/

Confiram meus apps Android no Google Play

https://play.google.com/store/apps/developer?id=Neto+Lobo

@netolobo

[Diego Rocha]

Baião, não sei :-/

Neto, basicamente ele falou pra usar HTTPS e Token (oauth se for login de usuario) que já foi debatido.

Tirando os possíveis problema com decompilar, seria esse método que eu usaria, um token (forte contra força bruta) de app enviado nas requisições protegido em HTTPS.

Atenciosamente,

Diego Rocha

[Cleber - Android Developer]

Você utilizaria uma abordagem de key de acesso aleatórias, onde um seu app gera um key utilizando um calculo de Data Hora e um chave de "encrypt". 

No seu app você envia a requisição para o seu WS com essa key.  

No seu WS você testa se a sua KEY é válida.

Utilize o proguard para dificultar a engenharia reversa, ou utilize um .so (vulgo dll no windows) separado do app

Outra coisa para dificultar é que você só pode utilizar a key uma unica vez.

Mas isso tudo é apenas para dificultar o acesso, pois mesmo com o proguard ou .so, mas o cara tem que ser muito bom e filha da puta para conseguir engenharia reversa. 

[Marcelo Alves]

Sobre HTTPS : http://jaanus.com/blog/2012/02/12/debugging-http-on-an-android-phone-or-tablet-with-charles-proxy-for-fun-and-profit/​ (bem mais simples do que parece)

Basicamente não tem meio de se defender. Você pode desestimular a pessoa de fazer isso, mas com um pouco de tempo, sempre é possível. Vide APIs "não oficiais" de WhatsApp, Instagram, etc.

[Jonas Alves]

Você pode desenvolver mil empecilhos pra dificultar o acesso a um webservice, mas impedir é impossível. Qualquer coisa que seu app faça, outro software ou pessoa pode imitar.

A única forma de realmente impedir o acesso de terceiros que me veio em mente foi usar o GCM Cloud Connection Server como intermediário entre o app e seu servidor. O GCM usa a assinatura digital do seu app pra garantir que só ele pode se comunicar com o servidor.

Em contrapartida, a comunicação é totalmente diferente da de um webservice, o que exigiria reescrever algumas camadas do seu app e também do servidor caso estes já estejam prontos.

[Eduardo Baião]

Jonas, mas se o hacker consegue descompilar o apk, ele não iria simplesmente remover as chamadas ao GCM e gerar um novo build da aplicação?

[Alex Baule]

Sugestão, https com troca de tokens q vc pode "inventar", porém a parte no seu apk, da geração do token e busca no webserver em C. Pra dificultar mais descompilacao do apk.

[Marcelo Alves]

Vale a pena tanto trabalho assim?

[Alex Baule]

Vc q deve avaliar heheheheh

[Jonas Alves]

Eduardo,

Não, pois a assinatura digital desse build adulterado seria diferente.

[Diego Rocha]

Marcelo,

Não conhecia o CharlesProxy, vai me facilitar e muito a vida em alguns debugs!

Jonas e Alex, realmente possível sempre é, a questão é conseguir um equilíbrio entre a casa toda destrancada e morar na área 51.

Atenciosamente,

Diego Rocha

[Carlos H. F. M. Rodrigues]

Muito obrigado pessoal, pela resposta de todos, achei bem legal os posts e discussão. 

Estou lendo com calma cada uma delas e tentando mapear o cenário mais dificil de ser quebrado.

Vou dar uma testada no ProGuard e ler/estudar sobre o GCM Cloud Connection pois pelo que entendi o GCM garante a legalidade de acesso no canal entre a App assinada (que seria somente a minha app) e o WebService, assim resolveria e muito o risco, a assinatura estará relaciona a minha app e nenhuma outra irá utilizar.

Esse meu App não é tão critico mas achei interessante saber como funciona Apps nesse cenário e como que se resolve nesse caso.

Se for só limitar por Login e senha, o HTTPS já ajudaria muito.

O que é intrigante em relação a aplicativos que qualquer um que teja vontade e tempo vai conseguir acessar os fontes diferente de uma Aplicação Web.

valew pessoal, obrigado!

----------------------------------------------------------------

Favor confirmar o recebimento deste e-mail,

Carlos H. Rodrigues

analista...@gmail.com

--
You received this message because you are subscribed to a topic in the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/androidbrasil-dev/nKZdWOk1zeA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to androidbrasil-...@googlegroups.com.

[Rogerio Esteves]

Se vc realmente esta com receio de alguém descompilar seu apk pq vc não criptografa as urls de seus web services. Seria uma saída?

[Thiago M. de França]

Vale uma lida nesse paper: https://www.virusbtn.com/pdf/magazine/2014/vb201407-Android-obfuscation.pdf

não é exatamente o que tá sendo posto em questão, mas se alguém se interessa pela area de segurança em android vale a pena ler.

On Tue, Mar 17, 2015 at 9:53 PM, Rogerio Esteves <rol...@gmail.com> wrote:

Se vc realmente esta com receio de alguém descompilar seu apk pq vc não criptografa as urls de seus web services. Seria uma saída?

--

You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

All it takes is one bad day to reduce the sanest man alive to lunacy.
That's how far the world is from where i am.
Just one bad day!