javascript - 单一登录安全威胁! FACEBOOK access_token公开/清除广播

Question

2011年2月20日:

Facebook今天证实，确实有一个电话公开播放access_token。 。 。它只是碰巧一次，我用来确保USER在保存到我的应用程序数据库之前仍然登录。他们的建议是使用上个月为canvase和facebook整体提供的SSL选项。在大多数情况下，Auth和Auth是安全的。

发现:

在我发帖之后，有评论说这不是一个问题，但我认为我确实提出了一个问题。因此，这里没有含糊之处是带头问题:

由于在Canvas加载过程中没有从Facebook发送的数据在某个时候没有泄露，包括access_token， session 和其他可以唯一标识用户的数据，除了添加一层以上之外，任何人都不会看到其他任何方式，例如，通过HTTPS与access_toekn一起通过有线方式发送的密码，将确保用户不受安全性影响的唯一性？

使用Wireshark，我在加载Canvas Application页面时捕获了本地广播。看到access_token广播是开放的，任何人都可以看到，我感到非常惊讶。该access_token附加到对Facebook OpenGraph API的任何https调用。

现在使用Facebook作为单击登录已经引起了我的极大关注。它存储在内存中的 session 对象中，并且在应用程序终止和查看FB之后会清除cookie.init调用中我看到了很多HTTPS调用，因此我假设access_token始终是加密的。

但是昨晚我在状态栏中看到了一个来自简单的http调用的 call ，其中包括应用程序ID，所以我觉得我应该嗅探Application Canvas的加载顺序。

今天，我确实进行了广播嗅探，在所附的图像中，您可以看到有http调用，其中access_token正在公开广播，并且所有人都可以访问。

我是否正在错过某些东西，这是我所看到的，我的解释确实正确。如果有人可以嗅探并获取access_token，则从理论上讲它们可以通过https调用Graph API，即使该回调仍需要是Facebook应用程序设置中建立的站点。

但是真正的安全威胁是任何使用access_token访问自己站点的人。如果唯一被确定为安全的东西是access_token，那么我看不到通过Facebook进行单一登录的值(value)-因为我可以清楚地看到它是不安全的。永不过期的访问 token 不会更改。每个用户的Access_tokens都不相同，仅对单个用户而言，访问另一个站点的权限可能会受到限制，但是即使损害单个用户的数据也是无法接受的。

http://www.creatingstory.com/images/InTheOpen.png

回去并对此进行了更多研究:

发现:

返回并重新运行canvas应用程序以验证不是我的任何代码都没有广播。

在此调用中:HTTP GET /connect.php/en_US/js/CacheData HTTP / 1.1

用户ID在cookie中清晰可见。因此，USER_ID是完全可见的，但它们已经存在。任何人都可以进入几乎任何一个页面并将鼠标悬停在图像上，并查看USER ID。因此没有太大的威胁。 APP_ID也很容易获得-但是。 。 。

http://www.creatingstory.com/images/InTheOpen2.png

上面的文件通过Facebook发起的 call 在OPEN中清楚地显示了FULL ACCESS TOKEN。

我错了吗。告诉我我错了，因为我想对此做错。

此后，我已重置了我的应用程序密码，因此我正在显示正在加载的 Canvas 页面的真实嗅探。

附加数据02/20/2011:

@ifaour-感谢您花时间来整理您的回复。

我对OAuth流程非常熟悉，并且对signed_request的拆包和access_token的使用有很好的了解。我在服务器上执行了大量处理，并且我的Facebook服务器端流都完整且正常运行，没有任何我知道的缺陷。应用程序密钥是安全的，永远不会传递给前端应用程序，并且还会定期更改。我一直对安全性非常狂热，因为我知道还有很多我不知道的安全隐患会折磨我。

两个巨大的access_token问题:

这些问题与来自用户代理(浏览器)的access_token的可能利用有关。在Facebook JavaScript SDK的FB.INIT()过程中，将创建一个cookie以及一个称为 session 对象的内存对象。该对象以及cookie包含access_token， session ， secret ，uid和连接状态。 session 对象的结构使其既支持新的OAuth又支持旧式流。使用OAuth，access_token和status几乎可以在 session 对象中使用。

第一个问题是access_token用于对GRAPH API进行HTTPS调用。如果您具有access_token，则可以从任何浏览器执行此操作:

https://graph.facebook.com/220439?access_token= ...

它将返回大量有关用户的信息。因此，具有访问 token 的任何人都可以访问Facebook帐户。您还可以对用户已授予对与access_token绑定(bind)的应用程序的访问权限的任何信息进行附加调用。最初，我认为对GRAPH的调用必须具有对在应用设置中建立的URL的回调，但是我如下所述对它进行了测试，它将使信息直接返回浏览器。我认为，添加该回调功能将是一个好主意，这会使事情变得更紧。

第二个问题是利用一些唯一的私有(private)安全数据，这些数据将用户标识为第三方数据库，例如，就像我这样，我将使用此唯一的安全数据项使用单点登录将用户信息填充到我的数据库中(即access_token，其中包含APP ID，USER ID和带有 secret 序列的哈希值)。在服务器端，这都不是问题。您将获得一个signed_request，并使用 secret 将其解压缩，进行HTTPS调用，并返回HTTPS响应。当用户通过USER AGENT(浏览器)输入的信息必须通过POST存储时，该唯一的安全数据元素将通过HTTPS发送，以便在插入数据库之前对其进行验证。

但是，如果没有通过单点登录过程提供的安全的唯一数据，则无法保证未经授权的访问。 access_token是Facebook用来对GRAPH API进行HTTPS调用的一条数据。就用户和应用程序而言，它都是唯一的，并且最初通过signed_request包装是安全的。但是，如果随后将其以明文方式发送，并且如果我可以嗅探电线并获得access_token，那么我可以假装成为该应用程序并获得他们授权该应用程序查看的信息。我从Safari和IE浏览器尝试了上面的示例，它在浏览器中将我的所有信息返回给我。

总之，access_token是signed_request的一部分，这就是应用程序最初获取它的方式。经过OAuth身份验证和授权后，即USER登录到Facebook，然后运行您的应用，access_token的存储如上所述，我已经对其进行嗅探，以至于我看到它存储在通过网络传输的Cookie中，没有唯一可识别的可识别信息可用于支持与数据库的交互，换句话说，除非将与access_token一起发送的另一条安全数据(即密码)发送给我，否则我会无法识别这是否是合法通话。幸运的是，我通过POST使用了安全的AJAX，并且 call 必须来自同一域，但是我敢肯定有一种劫持方式。

除了通过此单点登录过程添加另一层(密码)，或者是否有人愿意与我分享我错误地读取和分析了我的数据外，我完全愿意就如何唯一标识我的用户这一主题发表意见。 access_token始终通过网络安全。

提前Mahalo nui loa。

Answer 1

我对Facebook的身份验证/授权方法并不十分熟悉，但我确实相信它们为委派，分布式授权和“单点登录”实现了oauth(或类似的方法)。

OAuth is described by RFC-5849
编辑:Facebook使用的OAuth 2.0仍在工作草案中。

在OAuth和类似系统中，“access_token”仅是图片的一部分。通常还存在一个 secret 密钥，只有服务提供商(facebook)和客户端应用程序(您的应用程序)才知道。 secret 密钥是唯一希望保持 secret 的部分-该部分绝不会通过网络发送(在首次发行后)。

就Facebook而言，我认为当您注册应用程序以使用其API时， secret 密钥便已分配给您，并且只要用户同意允许您的应用程序访问其给定用户，“access_token”就会返回给您。信息。

消息以明文形式发送，包括用户名和相关的“access_token”；但是，每个消息还必须包含有效的签名，以便服务器可以接受。签名是加密计算的字符串，使用称为HMAC的技术创建。

计算HMAC签名需要 token 和密钥，还包括消息的其他关键部分。对于给定的消息内容，每个签名都是唯一的；并且每个消息都使用nonce来确保没有两个消息可以完全相同。

服务器收到签名消息后，首先提取access_token(纯文本)，然后确定为该 token 颁发了哪个应用程序。然后，它从其自己的本地数据库中检索匹配的 secret (该 secret 不包含在消息中)。最后，服务器使用明文消息，明文access_token和密钥来计算消息的预期HMAC签名。如果计算出的签名与接收到的消息上的签名匹配，则该消息必须已经由知道相同 secret 的人(即您的应用程序)发送。

请查看Section 3.1 of RFC-5849作为OAuth特定示例，并进一步详细说明。

顺便提一句，Amazon使用相同的方法来控制对S3和EC2的访问，以及大多数其他提供具有长期授权的API访问的服务提供商。只需说一下-这种方法是安全的。刚开始时可能有点反常理，但是一旦您仔细考虑，它就会变得有意义。

从Facebook文档中添加一些链接和报价:

Facebook确实在使用HMAC-SHA256算法。 注册文档(PHP Example reading signed_request部分)。

始终验证signed_request:

If you are unable to validate the signed_request because you can't embed your application secret (e.g. in javascript or a desktop application) then you MUST only use one piece of information from the payload, the oauth_token.

Authentication Document包含许多有用的信息，这些信息可用于验证用户的不同流程。另请阅读页面底部的Security Considerations部分:

Cross site request forgery is an attack in which an trusted (authenticated and authorized) user unknowingly performs an action on website. To prevent this attack, you should pass an identifier in the state parameter, and then validate the state parameter matches on the response. We strongly recommend that any app implementing Facebook user login implement CSRF protection using this mechanism.