网页的隐式跨多域 Cookies 的方法探讨，在 Safari 上面似乎路径都已经被堵死

V2EX = way to explore

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

现在注册

已注册用户请登录

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

对于以下场景：有 API 服务器 a.com ，同一个用户在 b.com 和 c.com 调用 a.com 的 API 的时候，a.com 可以识别到这是同一个用户。

或者说，在 b.com 登录 a.com 之后，c.com 访问 a.com 的 API 也是登录状态。

如果浏览器没有开启第三方 Cookies 保护，有以下这些隐式的方法：

CORS, withCredentials
Iframe 设置 Cookies
Iframe 使用 postMessage
古老的 P3P 头，已经被淘汰

如果浏览器开启了禁止第三方 Cookies，对于一些浏览器，上述的第三个仍然可以使用，但是 Safari 均不行。而且 Safari 默认禁止第三方 Cookies，如果需要用户开启，这也看作是显式的方法。

在禁止第三方 Cookies 的情况下，Facebook 以前使用了一种浏览器指纹的技术进行隐式追踪，来识别用户，这对于大多数浏览器仍然可行，但是苹果今年在开发者大会上面说，“我们只提供了一个简化的系统配置，因此，你的 Mac 看起来更像其他所有人的 Mac 电脑，而数据公司要想识别你的设备并追踪你，将会变得更加困难”，说明，这个路径也被堵死了。

另外，还有一些是可行的跨多域方法，但是都是显式的，我列出来，以免大家回复的时候误会

b.com 和 c.com 都跳转到 a.com 设置 cookies，再跳转回来
使用小弹窗的方式设置 Cookies
Storage Access API，在 Safari 上会弹出一个用户授权框，需要用户显式授权
让用户修改浏览器设置，允许第三方 Cookies

当然，为了防止还是有人出来杠我，我再提一下 jsonp, 普通 CORS, localstorage 和 document.cookie，这些虽然是隐式的，也可以做所谓的跨域，但是不能跨多域，在 b.com 获取到的 token/cookies，c.com 不知道，在 c.com 仍然需要重新获取 token

第 1 条附言 · 2018-12-25 15:03:40 +08:00

Safari 的策略好像更严格，一般做法好像是先显式设置 a.com 上面的 cookie，然后 b.com 或者 c.com 再用 iframe postMessage 的方法拿到 a.com 上面的 cookies 信息。

隐式

显式

API

22 条回复 • 2018-12-26 11:45:14 +08:00

martyartrt1

2018-12-25 11:52:41 +08:00

我有看到用 chrome 插件和服务器进行同步 cookie 的

gonghao

2018-12-25 13:02:04 +08:00

现在使用 b.com 跳 a.com 设置 Set-Cookie 可以顺利吧 a.com 的 Cookie 设置上，然后回到 b.com 。这时候如果在 b.com 用 CORS withCredentials 请求 a.com 的资源，其他浏览器下都是 OK，唯独 Safari 无解，除非去关闭 Prevent cross-site tracking。现在想到的唯一办法就是单独用 X-Auth 头来解决，但一直不愿意把 token 暴露到 JS 端，更不愿用 localStorage 或者 sessionStorage 去存储，所以现在就非常的纠结。

lhx2008

2018-12-25 13:14:56 +08:00

@gonghao 这样也不行吗，我其实没有苹果的机器，主要是看网上的文章说，只要是显式 set 都可以隐式读取。

explon

2018-12-25 13:20:25 +08:00

除了 script 标签调用文件通过 header 来种 cookie，其他方式应该都不行了

lhx2008

2018-12-25 13:27:52 +08:00 via Android

@gonghao 你这种情况好像还可以挂一个 iframe 用 postMessage，不知道行不行

lhx2008

2018-12-25 13:28:51 +08:00 via Android

@explon 但是种了也很难读到，像 2 楼说的

lhx2008

2018-12-25 13:29:50 +08:00 via Android

@explon safari 的策略太严格了

Chingim

2018-12-25 13:49:19 +08:00 via Android

小弹窗应该被浏览器 block 吧，选项 2 也可以去掉了

lhx2008

2018-12-25 14:01:45 +08:00 via Android

@Chingim 不会的，点击那个链接上面的弹窗事件不会被 block，比如分享到微博啥的，我博客 https://luan.ma 的评论也是弹窗登录的，没问题

FaiChou

2018-12-25 15:03:12 +08:00

赞呀 !

友情相关 : [t/520669]( https://www.v2ex.com/t/520669)

lhx2008

2018-12-25 15:28:36 +08:00 via Android

@livid 我好像只置顶了 10 分钟，但是好像状态有两个小时？

xiaochocking

2018-12-25 15:46:41 +08:00

@lhx2008 #6 很难读到的意思是？

yksoft1

2018-12-25 15:51:51 +08:00

WebSocket 可不可以连接到第三方？

lhx2008

2018-12-25 16:07:21 +08:00 via Android

@xiaochocking 如果关闭了第三方 cookies，即使你在 a.com 有 cookies，你在 b.com 用 cors 发请求到 a.com ，也不会把那个 cookies 带上

rayhy

2018-12-25 16:21:25 +08:00 via Android

想问类似 Google analysis 这种产品也做不到识别多个网站的相同用户吗？如果能，它是怎么做到的？

xiaochocking

2018-12-25 16:38:56 +08:00

@lhx2008 "在 b.com 获取到的 token/cookies，c.com 不知道，在 c.com 仍然需要重新获取 token"，有 b.com 获取到 token，c.com 不用重新取的可能吗？浏览器不可能允许 c.com 请求 a.com 时带上 [a.com 给 b.com 设置的 cookie]的吧，所以是不是最终都是得想方法各自获取 cookie 然后把他们关联起来(或者直接 cookie 值相等)？

chinvo

2018-12-25 16:39:24 +08:00 via iPhone

@rayhy #15 他本质上是用的 Google.com 域名下的 cookie，并没有跨域读写

lhx2008

2018-12-25 16:53:29 +08:00 via Android

@xiaochocking 允许第三方 cookies 的话，cookies 是存到 a.co 那里，只要 a.co 允许的域名，b.co c.co cors 到 a.co ，用的都是 a.co 的 cookies。b.co 和 c.co 不用存 cookies
如果不允许的话，只能把 a.co 的内容以 json 拉到 b.co 或者 c.co ，再存在 b.co 或者 c.co 的域下面，这样是肯定不互通的。

lhx2008

2018-12-25 16:55:33 +08:00 via Android

@rayhy GA 好像没有做跨站追踪。但是 Google 肯定有，而且 chrome 本身也不会把第三方 cookies 关闭，而且还给自己设置的 cookies 开后门不让你清除。

lhx2008

2018-12-25 16:59:47 +08:00 via Android

跨站追踪用那个 iframe 的方法就可以做，大网站因为你访问过，所以在非 iframe 显式设置的 cookies，在别的网站用 iframe 可以隐式读到（ postMessage ），比如在嵌入 GGAD 的网站，所以可以跟踪你的网络请求。所以我觉得这就是他们给大公司开的后门吧，哈哈
@rayhy

xiaochocking

2018-12-25 17:09:02 +08:00

@lhx2008 soga 我好像搞混了保存 cookie 的主体了，不是 a.co 给 b.co 设置的 cookie，应该是 a.co 给浏览器设置的 cookie

gonghao

2018-12-26 11:45:14 +08:00

@lhx2008 a.com 的 cookie 是设置成功的，在 a.com 上面的请求也是正常 OK 的。但是在 b.com 上跨域请求 a.com 就是失败，CORS 也是正确的，就唯独 Safari 下不行。但只要把 Prevent cross-site tracking 关闭就是可以了。挂一个 iframe 用 postMessage 这个方法还真没试过，成本要高不少，但是确实可以避免敏感信息泄露给 JS 的危险