chrome session 变化_Chrome80版本带来的关于samesite的一些变化（2）

Chrome80版本带来的关于samesite的一些变化(1)上一篇我们提到了如何判断SameSite request，这篇我们继续讲讲SameSite的其他知识以及应用场景。

SameSite属性有哪些值

SameSite = Strict, 也就是严格要求浏览器(user agent)来限制具有此属性的cookie只能在SameSite的请求发生的时候才会随请求一起发送。如果是CrossSite的场景，那对不起不管你是什么类型的HTTP请求，目标网站已有的cookie都不会出现在这个请求里。

SameSite = Lax, 有人说Strict太严格了，不分青红皂白只要是CrossSite请求你就不让我带cookie过去，那假如我是WIKI网站，很多人通过我去连入其他网站，结果一跳转过去就发现其他网站不认识我，即使我之前刚刚登陆过这个网站，是不是会有点奇怪。那感觉是作为一种中间形态的存在，Lax被定义出来。
简单的讲，如果你的请求是CrossSite请求但是如果你满足下面两点，你依然可以在Cookie SameSite = Lax的情况下携带Cookie过去：

1. 1. 这个请求会导致浏览器地址栏有显性的跳转(光明正大的从a.com跳转到b.com),很多人称这种为同步请求
   2. 这个请求只能是一个”安全“的HTTP请求，比如GET(按照GET的语义，它只是定义读操作，但是见过有使用GET方法去做更改操作的用来减少CORS里面的pre-flight options用以提高有限的响应时间)。这样可以一定程度的减少CSRF导致的危害，最多是读信息，不至于帮你转账(写操作)。

SameSite = None，这个就是说这个cookie可以在任意的CrossSite请求中被携带。

拿些例子说说

我们用几个例子来说明，如果我访问一个网站abc.com,由于HTTP是一个无状态协议，abc.com通常会通过cookie来标记下我的状态，从而给我提供更好的用户体验，那么在我那到网页结果的同时，在浏览器中也同时留下了一段标记(截个访问baidu后得到的结果参照下，来自chrome浏览器。)有了这些cookie，你可能下次就不需要在输入你的信息了，网站abc.com也会知道你是谁，你之前做过啥(买过啥东西，浏览过啥产品等等)。

浏览器中的cookie

我们假设abc.com在我登陆后默认生成了三个cookie

Set-Cookie: w_session=12345; SameSite=Strict;Domain=abc.comSet-Cookie: ro_session=23456; SameSite=Lax;Domain=abc.comSet-Cookie: trackingID=34567;SameSite=None;Domain=abc.com

w_session是abc.com授权写操作的会话cookie。

ro_session是abc.com授权只读操作的会话cookie。

trackingID是用来做一些行为跟踪的cookie。

网站xyz.com是一个用来做导购的网站，它和abc.com有合作关系，会帮一定的用户群导入到abc.com进行购物。这种情况下用户会从xyz.com通过跳转的方式(浏览器的地址栏会有明确的变化)到达abc.com的指定产品，进行浏览甚至进行下一步购买的操作。注意跳转浏览这个是一个CrossSite的请求，然后下一步购买是一个SameSite的请求。不同的cookie会在这个转换中起到不同的作用。

1， 用户点击https://xyz.com/xxx页面上的某个连接跳转到https://abc.com/item?id=111,这里通过GET请求，表达我想去abc.com看看这个产品，Cookie ro_session会在这个过程中起到作用，买不买您之后自己再决定

2，用户到达https://abc.com/item?id=111,一看这东西真不错，买买买，然后进行一些列添加购物车，提交订单，等等操作，这些都是在abc.com自己的site里面进行的,必然是SameSite的请求，这时w_session会起到作用。

上面的场景里面ro_session和w_session都各尽其职，相应的没人在尝试做出格的事。

有一天有个evil.com上线了，它想做xyz.com类似的事情，来吸引客户，导流客户，但是同时那想让这些客户给自己在abc.com上的商品点个赞(看上去并不算什么，但是其实可以做更具有破坏的事情)。它想悄悄的在用户不知情的情况下，通过异步调用的方式进行一些POST请求到https://abc.com/item?id=222去达到点赞的效果。可是它发现即使用户之前成功登陆过abc.com，w_session也无法被送达到https://abc.com/item?id=222。这里就是Samesite=Strict达到的效果。因为w_session是不会在CrossSite的场景中传送的。

https://tools.ietf.org/html/draft-west-first-party-cookies-07里也有描述过这种读写cookie的场景。

其实上面举得例子在真正的网站上不会是怎么简单的。evil.com是不是能进行对abc.com的更新访问还有其他很多条条框框在约束着，比如CORS，等等。显示生活中，一个网站对自己cookie的定义是根据自己业务类似和场景以及自己会话管理机制等等因素综合考虑而设计的。

Chrome80版本带来的变化

现在SameSite的默认值是None，但是在新的版本更新后，如果cookie没有明确的声明SameSite属性，那么默认的SameSite值会被更改为Lax。

我想这下就可以简单理解了，80或76版本前，如果你的cookie没有设置SameSite，这个cookie是可以被用来做CrossSite请求的。但是80版本之后，这样的Cookie它会被默认为SameSite为Lax。以至于它本身能够被使用的场景被大大缩减。这一定程度上进一步的提高了Cookie的安全性。但是对于开发者而言，大家要看看自己的cookie会不会因为这个默认行为的变化导致用户行为非预期的发生变化。

关键字：SameSite,Lax，SameSite的使用场景。