Facebook即时个性化如何运作?

时间:2013-06-26 18:54:48

标签: facebook cross-domain security xss

我刚刚访问过http://www.tripadvisor.co.uk/而没有填写任何登录表单,它知道我的身份,因为我登录了facebook。

我发现Trip Advisor是Facebook正在运行的名为“即时个性化”的计划的一部分。

我的问题是:这是如何运作的?幕后发生了什么?我的浏览器发送了什么,通过什么方法(例如HTTP POST,iFrame,Ajax等),以及谁?

特别是,我以前认为浏览器的跨域脚本安全规则使这种事情变得不可能。我认为浏览器永远不会让exampleone.com上的脚本与exampletwo.com进行通信。

那么tripadvisor.com如何才能获取我最初发送给facebook.com的信息?他们如何绕过跨域脚本规则?

PS - 请不要告诉我我可以禁用Facebook即时个性化。我已经知道我可以选择退出(在此页https://www.facebook.com/settings?tab=applications)。这是一个关于使Instant Personalization成为可能的技术的问题。

编辑 -

有些人已经评论说,我们会向Facebook发送请求以获取我的详细信息。我同意必须如此。但我要问的是, 这个请求是如何发送到Facebook的?如果我访问tripadvisor.com,那么我会主动告诉我的浏览器向tripadvisor.com提出请求。不是facebook.com。我认为我的浏览器会阻止在tripadvisor.com上运行的脚本与facebook.com进行通信。

我发现这非常令人不安。据推测,如果tripadvisor知道我的身份,那么他们的服务器可以通知facebook服务器我查看的页面。在tripadvistor和facebook的特定情况下,我对此并不感到困扰。我怀疑这些数据只会用于更好地定位他们向我展示的广告类型。无害......

但是,如果我的在线身份可以在我不知情的情况下在这样的域之间传递,我以前认为这是不可能的,那么这意味着可能有其他网站将这种技术用于恶意目的。所以我想了解最新情况,并了解我究竟接触到了什么。

3 个答案:

答案 0 :(得分:2)

好的,感谢你对这个@BassemDy的帮助 - 你给了我90%的答案,我刚刚想出了我失踪的其他10%。

我可以看到tripadvisor可以让我的浏览器向Facebook发送请求而不会破坏任何跨域规则。正如BassemDy指出的那样,当你从外部域加载图像,或者从谷歌地图等外部域加载共享脚本时,这种情况一直在发生......

我看不到的是,tripadvisor如何让我的浏览器向facebook发送请求,然后可以识别我。

然后答案打了我。当然tripadvisor的脚本不能直接读取我的facebook cookie ...但是当我的浏览器向Facebook发出跨域请求时,我的浏览器会将我的facebook cookie发送到facebook 。那是我失踪的部分。

然后facebook可以以某种方式回应tripadvisor的脚本可以读取的内容,因此tripadvisor的脚本可以确定我的身份。

使用OAuth和令牌进行的所有业务只是使上述过程安全的一种方式。最重要的是,tripadvisor可以让我将我的facebook cookie发送到Facebook。

作为概念验证,我在我控制的两个不同域上运行以下测试脚本:

在domainone.com上 - login.php

<?php setcookie('yourname','Daniel Howard',0,'/');
exit;

在domainone.com上 - responder.php

<?php header('Content-type: text/javascript'); ?>
window.cookieFromDomainone = <?= json_encode($_COOKIE) ?>;
window.updateMe();

然后在domaintwo.com上 - test.php

<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
<p id="identityFromDomainone"></p>
<script type="text/javascript">
    window.updateMe = function() {
        document.getElementById('identityFromDomainone').innerHTML = window.cookieFromDomainone.yourname;
    };
</script>
<script src="http://domainone.com/responder.php" ></script>
</body>
</html>

首先,我访问domainone.com/login.php,它会在其中设置一个带有我名字的cookie。当你登录facebook时会发生类似的事情。

然后我访问domaintwo.com/test.php

无法读取我的domainone.com cookie。但它使我的浏览器向domainone.com发送请求,并且我的浏览器将根据我的domainone.com cookie 发送请求。然后,在domainone.com/responder中,cookie值被输入到一些返回的javascript中,并在domaintwo.com上执行。

执行的javascript使我的身份在domaintwo.com上可用。当我的名字出现在p元素中时就会说明这一点。

我非常震惊的是,编写基本上会将用户身份泄露给任何有意提出要求的网站的代码是多么容易。我想知道有多少写得不好的单点登录尝试在野外等待被利用....希望Facebook和他们的伙伴使用的这个OAuth系统是安全的。

答案 1 :(得分:1)

以下是关于幕后发生的事情的简要技术说明:

当tripadvisor加载页面时,它会在下面突出显示对Facebook的请求:

Facebook Connect request from TripAdvisor

请求包含来自tripadvisor的特定ID以及一些定义要返回的参数。 Facebook验证请求并将似乎是访问令牌的内容返回给只能访问您的公共信息的应用程序。此令牌仅提供给他们的合作伙伴。

始终允许您的客户端向外部域发出HTTP请求!这就是CDN的工作方式以及其他多种Web实现。当您从服务器上包含的外部源中检索图像时,您正在浏览当前正在浏览的页面内容,这是一个不违反跨域策略的外部请求。

Facebook的回应包含在:

xd_arbiter.php?version=25

这是在客户端执行的javascript代码,我认为这允许tripadvisor检索您的公共信息。

Tripadvisor实际上不必访问您的cookie或违反跨域安全措施,一切都发生在服务器端在Facebook前面。一旦Facebook验证了请求的来源(即确保域名属于其中一个计划合作伙伴),它就会根据所需数据提供请求。

如果您尝试访问tripadvisor范围之外的URL,您将获得以下内容:

Facebook request problem

进一步阅读:

1.3.2来自OAuth规范文档的隐式授权流程:

  

隐式授权是优化的简化授权代码流      对于使用脚本语言在浏览器中实现的客户端      作为JavaScript。在隐式流程中,而不是发布客户端      授权代码,直接向客户端发出访问令牌      (作为资源所有者授权的结果)。授权类型      隐含为没有中间凭证(例如授权)      发布(以后用于获取访问令牌)。

https://tools.ietf.org/html/draft-ietf-oauth-v2-28#page-8

答案 2 :(得分:0)

我预感这与OAuth密切相关 - 也许它会自动检查当前登录的令牌,然后启动OAuth登录。