什么是SameSite
SameSite
是Cookie
中的一个属性,它用来标明这个 cookie
是个“同站 cookie
”,“同站 cookie
” 只能作为第一方cookie
,不能作为第三方cookie
,因此可以限制第三方Cookie
,解决CSRF
的问题。不知道CSRF
的看着这个。早在Chrome 51中就引入了这一属性,但是不会默认设置,所以相安无事。
第三方Cookie:由当前
a.com
页面发起的请求的URL
不一定也是a.com
上的,可能有b.com
的,也可能有c.com
的。我们把发送给a.com
上的请求叫做第一方请求(first-party request
),发送给b.com
和c.com
等的请求叫做第三方请求(third-party request
),第三方请求和第一方请求一样,都会带上各自域名下的cookie
,所以就有了第一方cookie
(first-party cookie
)和第三方cookie
(third-party cookie
)的区别。上面提到的CSRF
攻击,就是利用了第三方cookie
可以携带发送的特点 。
“同站cookie
”不是根据同源策略判断,而是PSL(公共后缀列表),子域名可以访问父域名cookie
,但父域名无法访问子域名cookie
。
SameSite
总共有三个值:Strict
、Lax
、None
。以下内容引自阮一峰博客
Strict
Strict
最为严格,完全禁止第三方 Cookie
,跨站点时,任何情况下都不会发送 Cookie
。换言之,只有当前网页的 URL
与请求目标一致,才会带上 Cookie
。
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
- 1
这个规则过于严格,可能造成非常不好的用户体验。比如像本人当前遇到的现象,cookie
带不过,等于一直没有登录状态,就会回到登录页。
Lax
Lax
规则稍稍放宽,大多数情况也是不发送第三方 Cookie
,但是导航到目标网址的 Get
请求除外。Chrome 80之后默认设置为该值。
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
导航到目标网址的 GET
请求,只包括三种情况:链接,预加载请求,GET
表单。详见下表。
请求类型 | 示例 | 正常情况 | Lax |
---|---|---|---|
链接 | <a href="…"></a> | 发送 Cookie | 发送 Cookie |
预加载 | <link rel=“prerender” href="…"/> | 发送 Cookie | 发送 Cookie |
GET 表单 | <form method=“GET” action="…"> | 发送 Cookie | 发送 Cookie |
POST 表单 | <form method=“POST” action="…"> | 发送 Cookie | 不发送 |
iframe | <iframe src="…"></iframe> | 发送 Cookie | 不发送 |
AJAX | $.get("…") | 发送 Cookie | 不发送 |
Image | <img src="…"> | 发送 Cookie | 不发送 |
设置了Strict
或Lax
以后,基本就杜绝了CSRF
攻击。当然,前提是用户浏览器支持 SameSite
属性。
None
浏览器会在同站请求、跨站请求下继续发送cookies,不区分大小写。网站可以选择显式关闭 SameSite
属性,将其设为 None
,同时必须设置 Secure
属性(表示Cookie
只能通过 HTTPS
协议发送,HTTP
协议不会发送),否则无效。
下面为无效响应头:
Set-Cookie: widget_session=abc123; SameSite=None
- 下面为有效响应头:
Set-Cookie: widget_session=abc123; SameSite=None; Secure
解决办法
- 显示关闭
SameSite
属性,按照上述有效响应头设置登录接口的响应头即可
//...
response.setHeader(name: "Set-Cookie", value: "_u=xxxx; Path=/Login; SameSite=None; Secure")
//...
2. 浏览器显式关闭该功能。(不推荐,这个功能还是蛮有用的)
- 地址栏输入:
chrome://flags/
- 找到
SameSite by default cookies
和Cookies without SameSite must be secure
- 将上面两项设置为
Disable
3
、Apache解决方案
首先你需要在httpd.conf文件中开启mod_header模块
LoadModule headers_module modules/mod_headers.so
你打开它以后并不能生效,所以我们还要重写Set-Cookie的头信息,其他的方法我们已经尝试并不可行,目前只有这一种方法可行
-
Header always edit "Set-Cookie" "path=/" "path=/; Secure; SameSite=None" 对应windows下的apache
-
Header edit "Set-Cookie" "path=/" "path=/; Secure; SameSite=None" 对应linux下的apache
这里修改完有些人可能不生效,关键字就是always 如果你加了always不生效就去掉,反之则加上。我亚马逊服务器与自己的服务器虽然是相同的apache2.4但是出来的结果竟然不同,都是CentOS7.所以这里我也不太清楚到底是哪里影响了。具体自己测试吧!
4、Nginx解决方案
首先如果你的项目上使用了反向代理那么恭喜你,你只需要简单的参照转发的这个进行设置
https://blog.cat73.org/20170802/2017080201.nginx-cookie-sucure/
如果你的项目上没有配置反向代理那么你需要配置反向代理到你自己的项目上,在反向代理的服务器去配置这个如上面参考
才能生效,直接配置在自己的服务器上是无法生效的。
参考
-
http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html
-
https://www.ithome.com/0/471/735.htm
-
https://www.chromestatus.com/feature/5088147346030592