之前我的项目中遇到了 SameSite 的应用, SameSite次要解决 CSRF (Cross Site Request Forgery) 问题，顺便也回顾下 CSRF 吧。
一、原理
利用 被攻打网站服务器 对用户网页浏览器 的信赖。
- 用户对非法网站的认证 cookie(登录态等）会保留在浏览器端；
- 跨站申请时浏览器会携带相干 cookie 的；
当用户浏览歹意网页时，攻击者通过一些技术手段坑骗用户的浏览器去拜访一个用户已经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。因为申请也是携带认证 cookie 信息的，服务端没有适合的进攻措施的话就很难辨认申请是用户失常申请还是 CSRF 申请。
1.1 特点：
联合原理和 CSRF 命名能够看出 CSRF 的特点：
- Cross Site： 攻打方在第三方站点；
- Request Forgery： 当用户浏览歹意站点时向被攻打的服务器发送操作申请。
攻击者不要获取用户的信息（cookie 等），间接坑骗用户的浏览器，让其以用户的名义运行操。
二、攻打伎俩
间接引入前端平安系列之二：如何避免 CSRF 攻打？的 DEMO：
受害者登录 a.com，并保留了登录凭证（Cookie）。
攻击者诱惑受害者拜访了 b.com。
b.com 向 a.com 发送了一个申请：a.com/act=xx。浏览器会默认携带 a.com 的 Cookie。
a.com 接管到申请后，对申请进行验证，并确认是受害者的凭证，误以为是受害者本人发送的申请。
a.com 以受害者的名义执行了 act=xx。
攻打实现，攻击者在受害者不知情的状况下，假冒受害者，让 a.com 执行了本人定义的操作。
三、进攻
针对 CSRF 的攻打原理，制订进攻策略：
-
攻打来自第三方站点：
- sameSite cookie：通知浏览器禁止跨站申请携带 cookie；
- 同源检测（验证 HTTP Referer 字段）：服务器加强校验。
- 伪造申请
生成无奈伪造的数据，服务器加强校验，辨认伪造申请。
3.1 验证 HTTP Referer字段
计划
[[科普]跨站申请伪造 -CSRF 防护办法](https://www.freebuf.com/artic…
毛病
- 尽管在
CSRF攻打中，Referer是无奈伪造的，然而保护比拟艰难； Referer配置不精确的话，很容易阻断失常申请；- 前期保护艰难，随着 url 的变动需一直批改
Referer；
总之不举荐应用
3.2 在申请地址中增加 token 并验证
计划
[[科普]跨站申请伪造 -CSRF 防护办法](https://www.freebuf.com/artic…
利用 token 标记非法申请。
CSRF token的生成，下发，上送，校验
1. 生成
-
由服务端生成随机惟一的字符串（GUID, UUID 等），并保留到服务端的
session或者其余服务端缓存（如 Redis）;token的缓存最好有过期工夫；
- 如果心愿进步
token的安全性能够对生成的token进行对称加密。
2. 下发
下发是服务端如何把生成的 CSRF token 传给客户端，形式很多了，看客户端怎么不便提取并传给后端。
- 千万别 ， 千万别 ， 千万别 通过
Set-Cookie下发； - 喷到页面里作为约定的全局变量；
- 最好和后端一起确定一个规范的下发和上送形式。
3. 上送
上送：是客户端调用接口时提取 CSRF token 并传给服务。看申请接口类型也后很多上送形式。
- 针对
GET申请能够放入 queryString 里； Form POST申请能够增加暗藏域；AJAX,fetch申请还能够采纳放入 request header 里；- 最好和后端一起确定一个规范的上送形式。
4. 校验
- 服务端从申请里获取客户端上送的
token； - 解密（如果之前有加密的话）；
- 再跟缓存（Session/Redis）的值比照。
四、哪些场景须要思考CSFR
重要的场景都须要并且倡议采纳 token 计划，一些常见的 case 有：
- 领取类场景（领取，转账，充值）；
- 勾销 / 关注好友，转发，删除（日志，帖子等），发邮件等操作；
- 信息更改类（更改手机号，邮箱等）。
参考：
整顿自 GitHub 笔记：CSRF