Cookie SameSite学习记录

一次Cookie SameSite的学习和使用

背景描述

毕业了，四年时光真的太快，不过感叹归感叹还是得乖乖搬砖。最近在参加一个公司的对内web项目，其登录模块的流程是前端从公司内部的sso那取得access token，通过请求头把token穿给后台，后台再调用sso的api来验证token，通过则设置session，并将cookie返还给前端。公司最近在向azure平台进行迁移，前后台的域名类似为

client.azurewebsites.net
api.azurewebsites.net

同时我们前端和后端也设置了

// 前端
withCredentials = true

// 后端
Access-Control-Allow-Origin = https://client.azurewebsites.net(因为要发送跨域cookie，这里不能使用通配符*)
Access-Control-Allow-Credentials = true

但在实施的过程中，我们发现cookie并没有在后续请求中传递。

学习和使用过程

一开始我们认为要做跨子域请求，希望前端每次发送请求时都会携带我们设置的cookie，我们先是设置了子域cookie

Domain = .auzrewebsites.net

但是依然不生效，在后续的请求中没有见到对应的cookie。

经过一番google，发现了azurewebsites.net属于公共后缀 ，对于这种情况，像chrome，firefox会拒绝后台发来的cookie，因此实际上现在发生的情况确切来说是跨站，所以我们的api call会失败。
stackoverflow参考：https://stackoverflow.com/questions/24873526/cross-domain-cookies-in-azure-development-with-acs-authentication
可以在https://publicsuffix.org/list/effective_tld_names.dat中列出的清单中发现azurewebsites.net被标注。

因为项目暂时还在开发中，在不考虑安全性的情况下，我们尝试设置Cookie SameSite来暂时解决这个问题，待业务开发压力不那么大的时候再回来重构掉这部分。(事实上，后来在veracode扫描的时候被抓了出来。。。)

根据MDN上的记载 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
SameSite可以简单的认为是一种对于cookie的发送条件限制的属性。
其分为以下三种情况:

• strict
• lax
• none

strict是最严格的条件，请求只有在第一方的时候才会携带cookie。

lax则限制稍小一些，在第三方站点做请求的时候依然无法携带cookie，但是当用户在第三方站点上导航到cookie发送站点时会携带cookie发送请求。

none则是完全没有限制，任何情况下都会发送设置cookie，但需要注意的是，设置SameSite=None时必须同时设置Secure，这意味着该cookie必须通过https进行设置，不然会被浏览器拒绝。

另一个值得留意的是，对于chrome，自从chrome80以后，不设置SameSite的cookie会被默认设置为lax用于防止csrf攻击，在一些其他现代的浏览器中该规则同样适用。

我们决定暂时在项目里设置了SameSite=none和secure来暂时避免这个问题，同时当需要清理cookie的时候也需要携带这些设置参数，不然会被浏览器认为是不同的cookie。

后记

web开发还有许多内容需要掌握，看来在成为一名独当一面的web开发人员我有很长很长的路要走😵。。。