回顾CSRF (Cross Site Request Forgery)

以前项目中遇到了SameSite的使用, SameSite主要解决CSRF (Cross Site Request Forgery)问题，顺便也回顾下CSRF吧。

1、原理

利用被攻击网站服务器对用户网页浏览器的信任。

1. 用户对合法网站的认证cookie(登陆态等）会保存在浏览器端；
2. 跨站请求时浏览器会携带相关cookie的；

当用户浏览恶意网页时，攻击者经过一些技术手段欺骗用户的浏览器去访问一个用户曾经认证过的网站并运行一些操做（如发邮件，发消息，甚至财产操做如转帐和购买商品）。由于请求也是携带认证cookie信息的，服务端没有合适的防护措施的话就很难识别请求是用户正常请求仍是CSRF请求。

1.1 特色：

结合原理和CSRF命名能够看出CSRF的特色：

1. Cross Site： 攻击方在第三方站点；
2. Request Forgery： 当用户浏览恶意站点时向被攻击的服务器发送操做请求。

攻击者不要获取用户的信息（cookie等），直接欺骗用户的浏览器，让其以用户的名义运行操。

2、攻击手段

直接引入前端安全系列之二：如何防止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执行了本身定义的操做。

3、防护

针对CSRF的攻击原理，制定防护策略：

1. 攻击来自第三方站点：

   • sameSite cookie：告诉浏览器禁止跨站请求携带cookie；
   • 同源检测（验证HTTP Referer字段）：服务器加强校验。
2. 伪造请求
   生成没法伪造的数据，服务器加强校验，识别伪造请求。

3.1 验证HTTP Referer字段

方案

[[科普]跨站请求伪造-CSRF防御方法](https://www.freebuf.com/artic...

缺点

1. 虽然在CSRF攻击中，Referer是没法伪造的，可是维护比较困难；
2. Referer配置不许确的话，很容易阻断正常请求；
3. 后期维护困难，随着url的变化需不断修改Referer；

总之不推荐使用

3.2 在请求地址中添加token并验证

方案

[[科普]跨站请求伪造-CSRF防御方法](https://www.freebuf.com/artic...
利用token标记合法请求。

CSRF token的生成，下发，上送，校验

1. 生成

1. 由服务端生成随机惟一的字符串（GUID, UUID等），并保存到服务端的session或者其余服务端缓存（如Redis）;

   • token的缓存最好有过时时间；
2. 若是但愿提升token的安全性能够对生成的token进行对称加密。

2. 下发

下发是服务端如何把生成的CSRF token传给客户端，方式不少了，看客户端怎么方便提取并传给后端。

1. 千万别，千万别，千万别经过Set-Cookie下发；
2. 喷到页面里做为约定的全局变量；
3. 最好和后端一块儿肯定一个标准的下发和上送方式。

3. 上送

上送：是客户端调用接口时提取CSRF token并传给服务。看请求接口类型也后不少上送方式。

1. 针对GET请求能够放入queryString里；
2. Form POST请求能够添加隐藏域；
3. AJAX, fetch请求还能够采用放入request header里；
4. 最好和后端一块儿肯定一个标准的上送方式。

4. 校验

1. 服务端从请求里获取客户端上送的token；
2. 解密（若是以前有加密的话）；
3. 再跟缓存（Session/Redis）的值对比。

4、哪些场景须要考虑CSFR

重要的场景都须要而且建议采用token方案，一些常见的case有：

1. 支付类场景（支付，转帐，充值）；
2. 取消/关注好友，转发，删除（日志，帖子等），发邮件等操做；
3. 信息更改类（更改手机号，邮箱等）。

参考：

整理自GitHub笔记：CSRF