security - Facebook 使用 redirect_uri 的客户端身份验证流程是否已损坏？

Question

如果我理解正确，要从我的桌面应用程序进行 API 调用(让我们从现在开始在 OAuth2 标准中调用它)我需要获得一个 access_token，它是一个结合了应用程序 ID 和用户的，我想访问的数据，id('资源所有者')。

按照身份验证指南 ( developers.facebook.com/docs/authentication/ ) 上的客户端流程，我知道我需要将请求发送到 h**ps://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=http://example .com&response_type= token 。结果，页面将被重定向到 h**p://example.com/#access_token=XXX。如果客户端是纯桌面应用，那么redirect_uri可以是h**p://www.facebook.com/connect/login_success.html。由于客户端拥有 Web 控件，因此可以轻松地从重定向地址中提取 access_token。

客户端流程包含 3 个 OAuth 步骤:

1. 用户身份验证，如果资源所有者未登录 Facebook，将显示一个对话框，要求提供 Facebook 凭据。如果资源所有者已登录， session 将使用 Facebook 服务器上的 cookie 进行身份验证。安全 - 检查 V!
2. 应用程序授权，如果资源所有者尚未授予该应用程序权限，则权限对话框将要求资源所有者向该应用程序授予权限，如果资源所有者先前已授予所有需要的权限，则权限对话框不会被显示。安全 - 检查 V!
3. 应用程序身份验证 - 现在，它变得棘手了。该指南说:“应用程序身份验证是通过验证 redirect_uri 是否与开发人员应用程序中配置的站点 URL 位于同一域中来处理的”。安全性 - 在我看来 - 失败!

为什么我认为最后一步是安全失败？首先，app id和redirect_uri都是公开信息，任何人都可以获得。其次，redirect_uri 可以是 h**p://www.facebook.com/connect/login_success.html。

让我们看看下面的场景。桌面应用程序 EVE 向用户显示一个 Web 控件，用户可以在其中登录 facebook 并授予 EVE 一些基本权限。资源所有者没有理由怀疑任何事情。接下来，EVE Conceal 了 Web 控件，并尝试在其上加载 h**ps://www.facebook.com/dialog/oauth?client_id=OTHER_APP_ID&redirect_uri=http://www。 facebook.com/connect/login_success.html&response_type=token。该应用程序可以尝试使用最流行的 facebook 应用程序应用程序 ID 加载此 url。如果用户之前授权了 OTHER_APP，应用程序将收到成功消息，因为登录对话框和权限对话框都不会显示。这将为 EVE 提供 access_token 以访问资源所有者授予 OTHER_APP 而不是 EVE 的资源所有者的所有资源。

那么，这是一个安全漏洞吗？我错过了以下内容吗？

(更新)

显然，对于桌面应用程序，安全问题是无关紧要的，因为应用程序已经有了用户名和 facebook session ，甚至用户名和密码，它可以对用户帐户做任何事情。

(更新)对于在网络浏览器中运行的 JavaScript 应用程序，redirect_uri 确实有效! (请参阅 hnrt 的回答和评论)。

当前问题:唯一剩下的谜团是客户端身份验证如何在 iPhone 和 Android 应用程序上工作？安全整体与使用桌面应用程序时的安全整体相似吗？越狱的 iPhone 或 root 的 Android 有什么区别吗？

干杯!

Answer 1

如果我理解正确，您的场景将要求用户已经使用 EVE 可用于与 Facebook 交谈的相同 Web 控件对其他应用程序进行身份验证。如果真是这样，那么已经存在更大的安全问题 :) EVE 可以劫持整个 session 及其所有身份验证 token 。

[更新] 关于 Javascript 应用程序，same origin policy阻止 EVE 访问 /dialog/oauth?client_id=OTHER_APP 请求的回复。访问数据的唯一方法是在 redirect_uri 处等待并解析重定向的请求。这里“站点 url”保护开始了。

我不确定在 iPhone 和 Android 应用程序中是如何工作的，但如果他们的 Web 控件允许访问其他应用程序的身份验证数据 (=cookies)，我会感到非常惊讶。