Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 CSRF 攻击和用户追踪。
CSRF 跨站请求伪造
CSRF(Cross-site request forgery)，也被称为one-click attack 或者session riding ，利用网站对用户网页浏览器的信任，挟制用户在当前已登录的Web应用程序上执行非本意的操作。
例如：
如果一个银行用以转账的url如：http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
那么就可以使用以下代码，对网站进行恶意攻击，在用户不知情的情况下使用用户未过期的登录信息进行转账操作
<img src="http://www.examplebank.com/withdraw？account=Alice&amount=1000&for=Badman">
为了防止某些恶意网站使用第三方cookie对相应网站进行恶意攻击所以目前很多网站会使用cookie的SameSite属性，对网站安全性进行相应控制并且可以同时用于用户追踪。
SameSite属性
- Cookie往往用来储存用户的身份信息，他的可配置属性有我们常用的name，value，demain，path，expires/Max-Age，secure等等，而我们今天要谈到的则是在chrome5.1开始，cookie新增的属性SameSite。
- 在Cookie的使用中我们通常使用secure来限制是否只能使用https请求进行访问，而我们在使用SameSite时通常用来限制第三方Cookie，从而减少安全风险
- 他分别有三个相关属性值
Set-Cookie: SameSite = Strict / Lax / None;
1. Strict
strict在我们现在的代码开发中，其实应该是众多开发者所再熟悉不过的了，就像我们的strict模式一样，在这里的属性值Strict也代表了最严格，完全禁止第三方Cookie，在跨站时任何情况都不会发送Cookie。换言之，只有在当前网页url与请求目标一致时才会在请求时携带cookie传输
Set-Cookie:
CookieName = CookieValue;
SameSite = Strict;
但是由于过于严格，虽然很好的保护了网站的信息安全，但是很大程度上抛弃了我们所追求的用户体验，当我们进行页面间的跳转时，就会经常出现页面处于未登录的状态
2. Lax
相比之下，Lax的范畴放宽了一些，虽然仍处于大多数情况不发送第三方Cookie，但是导航到目标网址的get请求除外
Set-Cookie:
CookieName = CookieValue;
SameSite = Lax;
导航到目标网址的GET请求包含以下几种情况（大体分为三种：链接，预加载以及GET表单请求）
| 请求类型 | 示例 | 正常情况 | Lax |
|---|---|---|---|
| 链接 | <a href /> | 发送Cookie | 发送Cookie |
| 预加载 | <link rel='prerender' href /> | 发送Cookie | 发送Cookie |
| GET 表单 | <form method='GET' action=''/> | 发送Cookie | 发送Cookie |
| POST 表单 | <form method='POST' action=''/> | 发送Cookie | 不发送 |
| iframe | <iframe src /> | 发送Cookie | 不发送 |
| AJAX | $.get() | 发送Cookie | 不发送 |
| Image | <img src /> | 发送Cookie | 不发送 |
这其中我们可以发现，如果我们使用的浏览器支持了SameSite属性的话，那么我们设置Strict或者是Lax就基本可以杜绝CSRF攻击，但是相应的这个属性也会引起一定的问题，这个我们后面会讲到。
3. None
Chrome计划将Lax变为默认设置，这时我们可以设置关闭SameSite属性即属性值设置为none，但是如果想要将SameSite设置为none，那么我们就需要配合Secure属性使用(Cookie只能通过HTTPS 协议发送)否则无效
无效
Set-Cookie: widget_session = abc123; SameSite = None;
有效
Set-Cookie: widget_session = abc123; SameSite = None; Secure;
常见问题/注意
我们在使用SameSite属性时，可以很大程度上减少CSRF攻击，但是同时我们也有需要注意的部分，或者说是我们通常情况下所说的坑
- 在我们使用属性值
None时，要注意与Secure属性的配合使用，Cookie只能在https协议中携带发送 - 在前后端配合使用时，如后端使用框架为spring web且为最新版本 那么要注意返回的cookie状态，默认为Lax且属性可能会出现不可更改的状态，如出现该问题，可以尝试以下办法：
服务端：
@Bean public CookieSerializer httpSessionIdResolver(){
DefaultCookieSerializer cookieSerializer = new DefaultCookieSerializer(); cookieSerializer.setCookieName("token");
cookieSerializer.setUseHttpOnlyCookie(false);
cookieSerializer.setSameSite(null);
return cookieSerializer;
}
//并且设置请求头
response.setHeader('Access-Control-Allow-Credentials','true')
客户端：
//在ajax请求时加上对应参数
xhrFields:{
withCredentials:true
}
目前了解到的问题就这两个，如有其它欢迎补充，谢谢
