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

问题描述

根据 Facebook 开发人员手册 (https://developers.facebook.com/docs/facebook-login/security) 您不必使用来自某种 Facebook SDK 客户端的 access_token，而无需确保它是专门为您的 Facebook 应用程序生成的.

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.

我想知道这里存在什么样的漏洞.如果我可以使用它进行 API 调用并通过它获取用户数据，为什么我应该关心哪个应用收到了令牌?

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?

令牌劫持

要了解这是如何发生的，请想象一个原生 iOS 应用想要进行 API 调用，但不是直接执行此操作，而是与同一应用拥有的服务器进行通信，并向该服务器传递使用 iOS SDK 生成的令牌.然后服务器将使用令牌进行 API 调用.

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:

假设您将 Facebook 身份验证用作 SSO 机制，并创建了一个应用程序向经过身份验证的用户返回一些私人信息的 Web 服务.此网络服务称为 /secretdocuments/download，它以访问令牌作为参数.

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.

如果网络服务只检查它收到的访问令牌是否是针对它在数据库中拥有的用户(通过调用/me 然后进行数据库查找)，那么恶意人员可能会:

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. 创建一些其他诱饵"应用.
2. 将指向该应用的链接发送给您的一位用户，并鼓励他们安装.
3. 该用户使用诱饵应用程序进行身份验证，并且访问令牌是生成.诱饵应用将此访问令牌发送给恶意用户.
4. 恶意用户获取该访问令牌并使用它调用您的 /secretdocuments/download 网络服务.
5. 您的网络服务仅检查访问令牌是否适用于用户它在数据库中并将私人信息返回给恶意用户.

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

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

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