Facebook 使用redirect_uri 的客户端身份验证流程是否已中断？
如果我理解正确的话，要从我的桌面应用程序进行 API 调用（让我们从现在开始，在 OAuth2 标准中的“客户端”上调用它），我需要获取一个 access_token，它是一个结合了应用程序 ID 和用户 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 步骤组成：
- 用户身份验证，如果资源所有者未登录 Facebook，将显示一个对话框，要求提供 Facebook 凭据。如果资源所有者已登录，则将使用 Facebook 服务器上的 cookie 对会话进行身份验证。安全 - 检查 V！
- 应用程序授权，如果资源所有者尚未授予应用程序权限，则权限对话框将要求资源所有者向应用程序授予权限，如果资源所有者之前授予了所有所需权限，则不会显示权限对话框。安全 - 检查 V！
- 应用程序身份验证 - 现在，这就是它变得棘手的地方。该指南说：“应用程序身份验证是通过验证redirect_uri是否与开发人员应用程序中配置的站点URL位于同一域中来处理的”。安全性 - 在我看来 - 失败！
为什么我认为最后一步是安全失败？首先，app id和redirect_uri都是公开信息，任何人都可以获取。其次，redirect_uri 可以是 h**p://www.facebook.com/connect/login_success.html。
让我们看看下面的场景。桌面应用程序 EVE 向用户显示一个 Web 控件，用户可以在其中登录 Facebook 并授予 EVE 一些基本权限。资源所有者没有理由怀疑任何事情。接下来，EVE 隐藏 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 会话，甚至用户名和密码，它可以使用用户帐户执行任何操作。
（更新） 对于在网络浏览器中运行的 JavaScript 应用程序，redirect_uri 确实有效！ （参见 hnrt 的回答和评论）。
当前问题： 唯一剩下的谜团是客户端身份验证如何在 iPhone 和 Android 应用程序上工作？整体安全性是否与使用桌面应用程序时的安全性类似？越狱的 iPhone 和 root 的 Android 手机有什么区别吗？
干杯!
If I understand correctly, to make API calls from my desktop application (let's call it from now and on 'client' as in the OAuth2 standard) I need to obtain an access_token which is an identifier that combines both the application id and the user's, who's data I want to access, id ('resource owner').
Following client flow on the authentication guide (developers.facebook.com/docs/authentication/) I understand that I need to send request to h**ps://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=http://example.com&response_type=token. In result, the page will be redirected to h**p://example.com/#access_token=XXX. If the client is a pure desktop app, then redirect_uri can be h**p://www.facebook.com/connect/login_success.html. Since the client owns the web control the access_token can be easily extracted from the redirected address.
The client side flow consists of 3 OAuth steps:
- User authentication, if resource owner is not logged in to Facebook, a dialog, asking for Facebook credentials, will be shown. If the resource owner is logged in, the session will be authenticated using the cookie on Facebook's servers. Security - CHECK V !
- App authorization, if resource owner didn't give permission for the app yet, the permission dialog will ask from the resource owner to grant permissions to the app, if the resource owner previously grated all needed permission, the permissions dialog will not be shown. Security - CHECK V!
- App authentication - Now, here is where it gets sticky. The guide says: "App authentication is handled by verifying that the redirect_uri is in the same domain as the Site URL configured in the Developer App". Security - In my opinion - FAIL!
Why do I think that the last step is a security fail? First of all, both app id and redirect_uri are public information that anyone can obtain. Second of all, redirect_uri can be h**p://www.facebook.com/connect/login_success.html.
Let's look at the following scenario. A desktop app, EVE, shows to the user a web control where the user logs in to facebook and grants EVE some basic permissions. Resource owner has no reason to suspect anything. Next, EVE hides the the web control, and tries to load on it 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. The app can try and load this url with the most popular facebook apps application ids. The app will get the Success message if the user previously authorized the OTHER_APP, since both login dialog and permissions dialog will not be shown. This will give EVE an access_token to access all resources of the resource owner that the resource owner granted to OTHER_APP and not to EVE.
So, is this a security hole? Did I miss something in the follow?
(UPDATE)
Clearly in a case of a desktop app, the security issues are irrelevant since the app has already the username and the facebook session and even the username and password, it can do anything with the users account.
(UPDATE)
For JavaScript apps that run in a web browser redirect_uri actually works! (See answer and comments by hnrt).
CURRENT QUESTION:
The only remaining mystery is how the client authentication works on iPhone and Android apps? Is the security whole is similar to the one when using a desktop application? Is there some difference in jailbreaked iPhones or rooted Androids?
Cheers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我理解正确的话，您的场景将要求用户已经使用 EVE 可以用来与 Facebook 对话的相同 Web 控件对其他应用程序进行了身份验证。如果是这种情况，那么已经存在更大的安全问题了:) EVE 可以劫持整个会话及其所有身份验证令牌。
[更新] 关于 Javascript 应用程序，同源策略 阻止 EVE 访问
的回复/dialog/oauth?client_id=OTHER_APP请求。访问数据的唯一方法是在redirect_uri处等待并解析重定向的请求。这里“站点 url”保护开始起作用。我不确定 iPhone 和 Android 应用程序中的工作原理，但如果它们的 Web 控件允许访问其他应用程序的身份验证数据（=cookie），我会感到非常惊讶。
If I understood correctly, your scenario would require that the user has already authenticated himself for the other apps using the same web control that EVE can use to talk to Facebook. If that is the case, then there are already much bigger security problems :) EVE could just hijack the whole session and all its authentication tokens.
[UPDATE] Regarding Javascript applications, same origin policy prevents EVE from accessing the reply of the
/dialog/oauth?client_id=OTHER_APPrequest. The only way to access the data is to wait atredirect_uriand parse the redirected request. Here the "site url"-protection kicks in.I am not sure how things work in iPhone and Android applications, but I would be really surprised if their web controls allowed access to the authentication data (=cookies) of other applications.