为什么苹果要完全屏蔽第三方 Cookie？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

爱意满满的作品展示区。

这是一个创建于 1705 天前的主题，其中的信息可能已经有所发展或是发生改变。

今天看到一个消息，说是苹果要完全屏蔽第三方 Cookie，看到之后感触良多，于是我写了一篇文章解释了下苹果为什么要这么做，在这里分享一下：

https://github.com/lmk123/blog/issues/76

欢迎大家提出自己的观点

第 1 条附言 · 2020-03-26 19:18:59 +08:00

贴一下原文给打不开 GitHub 的朋友 😂

最近在面试候选人的时候，我一定会问一个问题：a.com 里的 JavaScript 发起了一次获取数据的请求到 b.com 的接口，那么这次请求浏览器携带的是 a.com 的 Cookie 还是 b.com 的 Cookie？大部分人都回答了 a.com，但这是错误的——浏览器携带的永远是请求接收方的 Cookie，不然的话 b.com 岂不是获取了 a.com 所有的 Cookie 数据？

无独有偶，今天刚好关注到一个消息，苹果 WebKit 博客发表了一篇题为《Full Third-Party Cookie Blocking and More》的文章，正式宣布将在 iOS、iPad OS 13.4 和 macOS 上的 Safari 13.1 里默认完全屏蔽第三方 Cookie。

文章里提到了这样做有这些好处：

使跨站点泄露用户信息（例如登录指纹）不再可行
禁用通过第三方请求对网站的跨站点伪造攻击
删除使用辅助第三方域标识用户的功能。否则，即使用户删除第一方的网站数据，此类设置也可能保留 ID

本文不打算评价这种做法的对错，只是想从技术的角度解释为什么禁用第三方 cookie 会有文章里提到的这些好处。

什么是第三方 Cookie？

在这之前，我们先简单解释一下什么是第三方 Cookie。

HTTP 协议是无状态的，但如果要保存用户的登陆状态，网站肯定需要将用户的唯一标识存储在浏览器里，于是有了 Cookie。当用户访问一个网站，并输入用户密码登陆之后，网站会在浏览器里存储一个唯一标识，下次用户再打开这个网站时，这个唯一标识会被浏览器发送到网站的服务器，这样网站就知道，这个用户之前已经登陆过了，不需要再输入用户名和密码了。

但是，文章里说到的第三方 Cookie 是什么？

举个例子，我打开了网站 a.com，这个网站在我的浏览器里写入了一些 Cookie 用于记录我的登陆状态，但同时，a.com 的 HTML 里引用了第三方网站的资源，比如 b.com 下的一张图片、c.com 下的一个脚本文件，这些第三方服务器在返回资源的同时，也可以给浏览器设置它们域下的 Cookie，最终导致的结果就是，虽然我只访问了 a.com，但我的浏览器里现在有了 a.com、b.com 和 c.com 三个域的 Cookie。

在这三个域的 Cookie 中，a.com 属于第一方 Cookie，因为我访问的就是 a.com，但 b.com 和 c.com 的 Cookie 就属于第三方 Cookie 了。

了解了什么是第三方 Cookie 之后，我们再来逐条解释一下文章里说的好处分别说的什么意思。

第 2 条附言 · 2020-03-26 19:20:06 +08:00

## 什么是“跨站点泄露用户信息”？

一般网站的登陆流程是这么设计的：假设我的网站是 a.com ，在首页点击登陆之后，浏览器会跳到另一个地址 `a.com/login.html?redirect=https%3A%2F%2Fa.com`，当我们登陆成功之后，浏览器会跳转回 a.com ，也就是 URL 中 redirect 指定的地址；如果用户已经登陆过 a.com ，再次打开 `a.com/login.html?redirect=https%3A%2F%2Fa.com` 时，就会自动跳转到首页。

这是目前网站登陆中很常见的一个操作，但也成为了第三方网站检测你是否登陆过 a.com 的方式。

假设我们有一个网站 evil.com ，然后我们在 HTML 里引入这样一个 img：

```html
<img src="a.com/login.html?redirect=a.com%2Ffavicon.ico" onload="alert('登陆过')" onerror="alert('没有登陆')>
```

想象一下会发生什么？

如果用户登陆过 a.com ，那么浏览器在请求 `a.com/login.html` 这个资源时，会把 a.com 的 Cookie 带过去，a.com 发现用户登陆过，就会跳转到 `a.com/favicon.ico`，最终浏览器成功加载了这个 ico 图片，于是 `onload` 执行了。

如果用户没有登陆过 a.com ，那么 `a.com/login.html` 会返回一段 HTML，但浏览器需要的是图片，于是 `onerror` 执行了。

也就是说，通过这种方式，任何一个网站都知道我们有没有登陆过 a.com 。注重安全的网站会针对这种情况，屏蔽第三方网站对自家资源的请求，但并不是所有网站都会意识到这个问题。

如果默认屏蔽了第三方 Cookie，那么访问第三方网站时，浏览器不会带上 Cookie，所以从第三方网站访问 a.com/login.html 只会返回 HTML，这样就能从根本上阻止这种窃取隐私的行为了，不需要网站站长们自己去解决这个问题。

## “通过第三方请求对网站的跨站点伪造攻击”是指什么？

假设你登陆了一个银行网站 bank.com ，这个网站有一个接口，可以让你把你的钱转给其他账号，例如当你在浏览器里打开 `bank.com/transfer?amount=10&user=mica` 这个地址后，银行就会把 10 块钱转账给 mica 这个用户，当然，前提是你已经登陆过你的账号。

现在，有一个恶意网站 evil.com ，它在 HTML 中用 iframe 引入了银行网站的这个转账接口：

```html
<iframe src="bank.com/transfer?amount=10000&user=evil" />
```

于是你每访问一次 evil.com ，都会在你毫不知情的情况下给某个人转账 10000 块钱。

evil.com 当然没有你的用户名和密码，但由于你已经登陆过 bank.com ，所以浏览器里有你在 bank.com 的登陆标识 Cookie，而即使是第三方网站在访问 bank.com ，浏览器也会带上你的登陆标识，所以 bank.com 会认为这是你发出的指令，于是就产生了这种不需要账号就能造成损失的攻击方式。

这种攻击方式有一个专业上的术语叫 CRSF （ Cross-site request forgery ），跨站请求伪造。同样的，注重安全的公司会阻止第三方网站调用自己的接口，但并不是所有网站都会这么做。

如果默认禁用了第三方 Cookie，在上面的场景中，从 evil.com 里发起的对 bank.com 的请求就不会带上你的登陆标识 Cookie，自然 bank.com 也就不会执行转账的操作了。

第 3 条附言 · 2020-03-26 19:21:02 +08:00

“删除使用辅助第三方域标识用户的功能”是指什么？

场景一：共享登陆状态

现在大家可能都喜欢在淘宝和天猫上购物，不知道有没有注意到，我在天猫 https://tmall.com 登陆之后，再打开淘宝 https://taobao.com 的时候不需要重新登陆，淘宝已经知道我是谁了。

我们都知道，不同域名的网站相互之间是不能读取对方的 Cookies 的，那天猫和淘宝是怎么做到共享登陆状态的？其实就是利用了第三方 Cookie 的特点。

天猫的登陆界面 https://login.tmall.com 其实是用 iframe 引用了淘宝的登陆界面 https://login.taobao.com ，登陆成功之后，淘宝在浏览器里写入了 .taobao.com 域的 Cookie，所以用户打开淘宝的时候，浏览器里已经有了淘宝的登陆标识，淘宝当然就知道我们是谁了。

这就是“使用辅助第三方域标识用户的功能”了——等等，后面那句“即使用户删除第一方的网站数据，此类设置也可能保留 ID”是指什么？

假设现在我想清除我在天猫的所有数据，包括 Cookies。在 macOS 的 Safari 浏览器中，你可以打开偏好设置，切换到「隐私」这个标签页，点击「管理网站数据...」按钮，然后在弹出的窗口中搜索 tmall.com，选中之后，点击左下角的「移除」，这样天猫的所有数据都被清除了。

按照预期，我再打开天猫应该是未登陆的状态——但实际上并不是，我打开之后，天猫仍然知道我是谁，我的登陆状态仍然没有被清除。

原因就是，我清除了天猫的数据，但没有清除淘宝的数据，而我的登陆状态是保存在淘宝里的——但这显然不符合用户的预期。

在苹果默认禁用第三方 Cookie 之后，这样的登陆状态共享就做不到了，因为在天猫登陆的时候，浏览器会阻止淘宝把 Cookie 写入浏览器里。

场景二：广告追踪

站长们为了利用网站的流量变现，一般会选择给网站加点广告，自己找广告主很麻烦，所以站长一般会直接接入广告联盟，广告联盟会提供一个脚本文件给站长，只要引入了这个脚本，那么就能自动推荐合适的广告给用户。

这听起来简单方便，合情合理，但如果有很多网站都引用了广告联盟的脚本文件呢？

假设有一个广告联盟 ad.com，它提供了一个脚本文件 ad.com/get_ad.js，现在有两个网站 a.com、b.com 都引用了这个脚本，那么会发生什么？

用户第一次访问 a.com 的时候，ad.com 会通过 ad.com/get_ad.js 给用户设置一个 Cookie 到浏览器里，用于唯一标识这个用户；然后这个用户访问 b.com 的时候，浏览器加载 ad.com/get_ad.js 的脚本时会携带上刚才设置的 Cookie，这样广告联盟就能把这两次访问记录关联起来：我有一个用户 xxx，他先是访问了 a.com，然后访问了 b.com。

那如果有成千上万个网站都加入了 ad.com 这个广告联盟呢？恭喜，你在互联网的访问记录，ad.com 都知道的一清二楚了，而在技术如此发达的现在，将 Cookie 关联到你的个人信息一点也不难。

如果禁用了第三方 Cookie，广告联盟就再也不能拿到我们的访问记录了，但与此同时，广告联盟也不能根据用户的访问记录向我们推荐合适的广告了，这对站长和广告联盟行业都是一个沉重的打击。