segredo do cliente em OAuth 2.0


95

Para usar a API do Google Drive, eu tenho que brincar com a autenticação usando OAuth2.0. E eu tenho algumas perguntas sobre isso.

  1. O ID e o segredo do cliente são usados ​​para identificar o que é meu aplicativo. Mas eles devem ser codificados se for um aplicativo cliente. Portanto, todos podem descompilar meu aplicativo e extraí-los do código-fonte. Isso significa que um aplicativo ruim pode fingir ser um bom aplicativo usando o ID de cliente e o segredo do aplicativo bom? Então, o usuário mostraria uma tela pedindo permissão para um aplicativo bom, embora na verdade seja solicitada por um aplicativo ruim? Se sim, o que devo fazer? Ou na verdade eu não deveria me preocupar com isso?

  2. No aplicativo móvel, podemos embutir uma visualização da web em nosso aplicativo. E é fácil extrair o campo de senha no webview porque o aplicativo que está pedindo permissão é na verdade um "navegador". Portanto, o OAuth no aplicativo móvel não tem o benefício de o aplicativo cliente não ter acesso à credencial do usuário do provedor de serviços?


2
Além disso, acho que as pessoas geralmente suspeitam quando o aplicativo pede suas credenciais do Facebook, Twitter, Dropbox ou outras. Duvido que muitas pessoas comuns leiam as especificações do OAuth e digam "Agora estou seguro", mas, em vez disso, usam o bom senso e geralmente não usam aplicativos nos quais não confiam.
Igor Čordaš

Realmente, uma ótima pergunta definitivamente deveria ter mais pontos
Shravan

você poderia apenas baixar o ClientId e o segredo do seu servidor e salvá-lo em um keychain no primeiro login bem-sucedido e é isso
Shravan

@ Sharvan Posso estar errado, mas acho que as chaves são vulneráveis ​​em telefones com acesso root, então o segredo do seu cliente pode ser tornado público.
chichilatte

Respostas:


16

Comecei a escrever um comentário sobre sua pergunta, mas descobri que há muito a dizer, então aqui estão minhas visões sobre o assunto na resposta.

  1. Sim, há uma possibilidade real para isso e houve alguns exploits baseados nisso. A sugestão é não manter o segredo do aplicativo em seu aplicativo, há até uma parte na especificação de que aplicativos distribuídos não devem usar esse token. Agora você pode perguntar, mas XYZ requer isso para funcionar. Nesse caso, eles não estão implementando a especificação corretamente e você deve A não usar esse serviço (provavelmente) ou B tentar proteger o token usando alguns métodos ofuscantes para tornar mais difícil encontrar ou usar seu servidor como proxy.

    Por exemplo, havia alguns bugs na biblioteca do Facebook para Android em que estava vazando tokens para Logs. Você pode descobrir mais sobre isso aqui http://attack-secure.com/all-your-facebook-access-tokens-are-belong -para nós e aqui https://www.youtube.com/watch?v=twyL7Uxe6sk . Em suma, seja extremamente cauteloso com o uso de bibliotecas de terceiros (bom senso, na verdade, mas se o sequestro de tokens for sua grande preocupação, adicione outro fator para cautela).

  2. Eu venho reclamando sobre o ponto 2 há algum tempo. Eu até fiz algumas soluções alternativas em meus aplicativos para modificar as páginas de consentimento (por exemplo, alterar o zoom e o design para caber no aplicativo), mas nada me impedia de ler os valores dos campos dentro da visualização da web com nome de usuário e senha. Portanto, eu concordo totalmente com seu segundo ponto e considero um grande "bug" nas especificações do OAuth. O fato de que "o aplicativo não tem acesso às credenciais dos usuários" na especificação é apenas um sonho e dá aos usuários uma falsa sensação de segurança ... Também acho que as pessoas geralmente suspeitam quando o aplicativo pede suas credenciais do Facebook, Twitter, Dropbox ou outras. Duvido que muitas pessoas comuns leiam as especificações do OAuth e digam "Agora estou seguro", mas, em vez disso, usam o bom senso e geralmente não usam aplicativos nos quais não confiam.


3
Seu ID de cliente e segredo do cliente não estarão seguros apenas porque você os publica em um túnel SSL. Sim, eles estão mais protegidos contra ataques do tipo man in the middle. Se um usuário fizer proxy de sua chamada HTTPs, ele poderá aceitar o certificado inválido e ver tudo que você postar. A propósito, esta é a maneira mais fácil de roubar o segredo do cliente de alguém em dispositivos móveis.
EpicThreeDev

5
Agradeço seu comentário, mas não consigo vinculá-lo à minha resposta de forma alguma ... Você poderia explicar por que comentou minha resposta, porque declarei explicitamente que o segredo do cliente não deve ser usado em aplicativos distribuídos e o outro ponto é que existem soluções alternativas para obter as credenciais do usuário nos aplicativos, mesmo usando OAuth, de modo que os usuários devem confiar no provedor do aplicativo e não no OAuth.
Igor Čordaš

Além disso, não entendo o que você quer dizer com "Se um usuário faz proxy da sua chamada HTTPs", sim, os usuários obtêm acesso aos dados que enviaram usando HTTPs e estão livres para fazer chamadas proxy como quiserem. Pelo que entendi, você está sugerindo isso como uma boa alternativa para desmontar o apk para obter o segredo, mas, novamente, você não deve enviar o segredo do aplicativo em primeiro lugar.
Igor Čordaš

Portanto, para o ponto 1) o aplicativo defeituoso precisa ter acesso ao mesmo sistema e recuperar o token de acesso / atualização do mesmo dispositivo?
gauteh

Não está claro o que você considera "mesmo sistema" neste contexto. O aplicativo cria uma visualização da web na qual a página de confirmação é mostrada e pode acessar todos os dados dessa visualização (incluindo cookies ou parâmetros de url que hospedam o token de acesso). O acesso cruzado a aplicativos também é possível em alguns casos, por exemplo, se um aplicativo pode acessar outros logs de aplicativo, ele pode encontrar o token lá conforme mencionado com o bug fb lib.
Igor Čordaš

15

Eu tive a mesma pergunta que a pergunta 1 aqui, e fiz algumas pesquisas recentemente, e minha conclusão é que não há problema em manter o "segredo do cliente" em segredo. O tipo de cliente que não mantém a confidencialidade do segredo do cliente é chamado de "cliente público" na especificação OAuth2. A possibilidade de alguém mal-intencionado conseguir obter o código de autorização e, em seguida, o token de acesso é evitada pelos seguintes fatos.

1. O cliente precisa obter o código de autorização diretamente do usuário, não do serviço

Mesmo que o usuário indique o serviço em que confia no cliente, o cliente não pode obter o código de autorização do serviço apenas mostrando o ID do cliente e o segredo do cliente. Em vez disso, o cliente deve obter o código de autorização diretamente do usuário. (Isso geralmente é feito por redirecionamento de URL, sobre o qual falarei mais tarde.) Portanto, para o cliente malicioso, não é suficiente saber o ID / segredo do cliente em que o usuário confia. Ele precisa envolver ou falsificar o usuário para fornecer o código de autorização, o que deve ser mais difícil do que apenas saber o ID / segredo do cliente.

2. O URL de redirecionamento está registrado com o ID / segredo do cliente

Vamos supor que o cliente malicioso de alguma forma conseguiu envolver o usuário e fazê-lo clicar no botão "Autorizar este aplicativo" na página do serviço. Isso acionará a resposta de redirecionamento de URL do serviço para o navegador do usuário com o código de autorização com ele. Em seguida, o código de autorização será enviado do navegador do usuário para a URL de redirecionamento, e o cliente deve estar ouvindo na URL de redirecionamento para receber o código de autorização. (O URL de redirecionamento também pode ser localhost, e percebi que essa é uma maneira típica de um "cliente público" receber o código de autorização.) Como esse URL de redirecionamento está registrado no serviço com o ID / segredo do cliente, o cliente malicioso não têm uma maneira de controlar para onde o código de autorização é fornecido.


3
Isso é promissor, você tem alguma referência para isso? Seria reconfortante saber.
gauteh

1
Eu vi nos documentos do Drive que nos aplicativos instalados o segredo do cliente não é realmente um segredo, mas eles não explicaram por que não há problema em armazená-lo lá. Sua explicação ajudou muito!
Martin Spasov

1

Respondendo à segunda pergunta: as APIs do Google por motivo de segurança determinam que a autenticação / login não pode ser feito dentro do próprio aplicativo (como as visualizações na web não são permitidas) e precisa ser feito fora do aplicativo usando o navegador para melhor segurança, que é explicado mais detalhadamente abaixo: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html


pelo menos está "consertado" 3 anos depois de eu ter perguntado :)
Bear
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.