Tecnologia do Blogger.
RSS

Re: [androidbrasil-dev] Garantir que somente a minha App acesse meu webservice

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?

Em 17 de março de 2015 16:59, Jonas Alves <jonasfa@gmail.com> escreveu:
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.

On Tue, Mar 17, 2015 at 4:12 PM Cleber - Android Developer <clebaori@gmail.com> wrote:
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. 

Em 17 de março de 2015 15:35, Diego Rocha <diego@diegorocha.com.br> escreveu:

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

2015-03-17 15:27 GMT-03:00 Neto Lobo <desilio@gmail.com>:

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/


2015-03-17 15:16 GMT-03:00 Eduardo Baião <eduardobaiao@gmail.com>:

Hehehe.

Eu estava falando da descompilação.

O ProGuard resolve 100%?

Em 17 de março de 2015 15:13, Diego Rocha <diego@diegorocha.com.br> escreveu:

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

2015-03-17 15:01 GMT-03:00 Eduardo Baião <eduardobaiao@gmail.com>:

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.


Em 17 de março de 2015 14:53, Diego Rocha <diego@diegorocha.com.br> escreveu:

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 <eduardobaiao@gmail.com>:
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?

Em 17 de março de 2015 14:25, Jhosef Marks <jhosef@gmail.com> escreveu:

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
skype: jhosef.marks
Twitter: @jhosefmarks

Em 17 de março de 2015 13:44, Diego Rocha <diego@diegorocha.com.br> escreveu:
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

2015-03-17 13:32 GMT-03:00 Carlos H. F. M. Rodrigues <analista.carlosh@gmail.com>:

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.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

0 comentários:

Postar um comentário