漏洞与Facebook令牌劫持 [英] Vulnerability with Facebook token hijacking

问题描述

据Facebook的手册，开发者（ https://developers.facebook.com/docs / Facebook的登录/安全）你不必使用的access_token 从某种Facebook的SDK的客户，如果不能确保它是为您的Facebook应用程序专门生成

我想知道什么样的漏洞，有发生在这里。我为什么要关心它的应用程序接收到的标识，如果我可以用它通过它来进行API调用，并得到用户的数据？

  

令牌劫持

  
  

要了解发生这种情况，假设要进行API调用原生iOS应用，但不是直接做这件事，与相同的应用程序拥有的服务器进行通信，并通过该服务器采用了iOS SDK生成的令牌。然后，服务器将使用该令牌来进行API调用。

  
  

这是服务器用于接收令牌可能受到影响，其他人可以通过访问令牌完全不同的应用程序，以它的终点。这将是明显不安全的，但要避免这种情况的一种方式 - 访问令牌不应该被认为是从使用他们的应用程序，相反，他们应该使用调试端点进行检查

解决方案

这些类型的漏洞是针对特定应用 - 一个情景我能想到的是这样的：

想象一下，你正在使用Facebook的身份验证为 SSO 机制和已经创建了一个应用程序使用返回一些私人信息，以验证用户web服务。此WebService叫做 / secretdocuments /下载这需要一个访问令牌作为参数。

如果web服务仅检查它接收的接入令牌是在数据库中它有一个用户（通过调用/我，然后将DB查找），那么怀有恶意的人可能：

1. 创建一些其他的诱饵的应用程序。


2. 发送一个链接到应用的用户之一，并鼓励他们进行安装。


3. 该用户与诱饵应用验证和访问令牌
   产生的。诱饵应用程序发送这个访问令牌给恶意用户。


4. 恶意用户需要的访问令牌，并调用你的 / secretdocuments /下载 web服务。


5. 您的web服务仅检查访问令牌是用户
   这是在数据库，并返回私人信息的
   恶意用户。

在这种情况下，您的Web服务必须检查所提供的访问令牌是由您的应用程序生成。

According to Facebook manual for developers (https://developers.facebook.com/docs/facebook-login/security) you don't have to use access_token from some sort of Facebook SDK clients without ensuring that it was generated specifically for your Facebook application.

I'm wondering what kind of vulnerabilities has place here. Why I should care about which app received token if I can use it to make API calls and get user data through it?

Token Hijacking

To understand how this happens, imagine a native iOS app that wants to make API calls, but instead of doing it directly, communicates with a server owned by the same app and passes that server a token generated using the iOS SDK. The server would then use the token to make API calls.

The endpoint that the server uses to receive the token could be compromised and others could pass access tokens for completely different apps to it. This would be obviously insecure, but there is a way to protect against this - access tokens should never be assumed to be from the app that is using them, instead they should be checked using debugging endpoints.

解决方案

These types of vulnerability are application specific - one scenario I can think of is this:

Imagine you are using Facebook authentication as a SSO mechanism and have created an app with a webservice that returns some private information to authenticated users. This webservice is called /secretdocuments/download which takes an access token as a parameter.

If the webservice only checks that the access token it receives is for a user it has in the database (via a call to /me and then a DB lookup), then a malicious person could:

1. Create some other "bait" app.
2. Send a link to that app to one of your users and encourage them to install it.
3. That user authenticates with the bait app and an access token is generated. The bait app sends this access token to the malicious user.
4. The malicious user takes that access token and calls your /secretdocuments/download webservice with it.
5. Your webservice only checks that the access token is for a user which is in the database and returns the private information to the malicious user.

In this scenario, your webservice must check that the access token provided was generated by your application.

这篇关于漏洞与Facebook令牌劫持的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！