2

我刚刚访问了http://www.tripadvisor.co.uk/并且没有我填写任何登录表格，它知道我的身份，因为我登录了 Facebook。

我发现旅行顾问是 Facebook 正在运行的名为“即时个性化”的程序的一部分。

我的问题是：这是如何工作的？幕后发生了什么？我的浏览器正在发送什么，通过什么方法（例如 HTTP POST、iFrame、Ajax 等）以及发送给谁？

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

那么，tripadvisor.com 怎么可能访问我最初发送到 facebook.com 的信息呢？他们如何绕过跨域脚本规则？

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

编辑 -

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

我觉得这非常令人不安。大概如果tripadvisor知道我的身份，那么他们的服务器可以通知facebook服务器我查看的页面。在 triadvistor 和 facebook 的具体情况下，我对此并不太在意。我怀疑这些数据只会用于更好地定位他们向我展示的广告类型。够无害的......

但是，如果我的在线身份可以在我不知道的情况下在这样的域之间传递，以我以前认为不可能的方式，那么这意味着可能有其他网站正在将此技术用于恶意目的。所以我想了解发生了什么，并了解我到底接触到了什么。

4

3 回答 3

2

好的，感谢您对 @BassemDy 的帮助 - 您给了我 90% 的答案，而我刚刚发现了另外 10% 的问题。

我可以看到，tripadvisor 可以让我的浏览器在不违反任何跨域规则的情况下向 facebook 发送请求。正如 BassemDy 指出的那样，当您从外部域加载图像或从某些外部域（如谷歌地图等）加载共享脚本时，这种情况一直发生。

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

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

然后facebook可以以tripadvisor的脚本可以读取的某种方式做出响应，因此tripadvisor的脚本可以确定我的身份。

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

作为概念验证，我在我控制的 2 个不同域上运行了以下测试脚本：

在 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 系统是安全的。

于 2013-06-27T02:12:23.010 回答
1

Here's a brief technical explanation about what happens behind the scenes:

When tripadvisor loads the page, it makes a request to Facebook highlighted below:

Facebook Connect request from TripAdvisor

The request contains a specific ID from tripadvisor and some parameters defining what to return. Facebook validates the request and returns what seems to be an access token to an application that only has access to your public information. This token is only given to their partners.

Your client is always allowed to make HTTP requests to external domains! It's how CDNs work and multiple other web implementations. When you retrieve an image from an external source which is not contained on the server that is serving you the page content you are currently browsing, this is an external request which does not violate cross domain policies.

The response from Facebook is contained in:

xd_arbiter.php?version=25

It's javascript code that is executed on the client side which I presume allows tripadvisor to retrieve your public information.

Tripadvisor doesn't really have to access your cookies or violate cross domain security measures, everything happens on the server side on the Facebook front. Once Facebook validates the origin of the request (i.e. making sure the domain belongs to one of its program partners), it serves the request with the needed data.

If you try to access the URL outside tripadvisor's scope you get the following:

Facebook request problem

Further Readings:

1.3.2 Implicit Grant Flow from OAuth specification docs:

The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly (as the result of the resource owner authorization). The grant type is implicit as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token).

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

于 2013-06-27T00:02:48.047 回答
0

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

于 2013-06-26T19:05:19.243 回答