CSRF(Cross-site request forgery,跨域请求伪造)
文章目录
前言
CSRF是一种安全问题:攻击者盗用你的身份(客户端获取的cookie)想第三方网站发送请求,进行非法操作。
一、CSRF的过程
以访问银行网站为例:
- 用户User访问银行网站,登录成功后,客户端生成相应cookie。
- 在User未登出的情况下访问了危险网站B,在网站B中触发了一个请求,如点击图片,该图片src向银行发起转账请求。由于User未登出,在网站B向银行发送请求时,会携带cookie。
- 银行后台响应请求,完成非法操作。
二、如何防御CSRF攻击
1.验证 HTTP Referer
字段
HTTP Referer
字段它记录了该 HTTP 请求的来源地址。服务器端可以验证请求的来源,若同源则响应。但是,HTTP Referer
字段可以被修改,因此并不安全。
2.使用验证码
在客户端使用验证码可以有效防止CSRF攻击。
3.使用token验证
这个Token的值必须是随机的。由于Token的存在,攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。
三、cookie和token的区别
cookie
- cookie是有状态的,服务器端保存的sessionID与cookie中的sessionID做对比,相同则认证成功。
- 当浏览器发送http请求时会自动将cookie携带上,这就造成了CSRF风险。
- 由于服务器端要保存sessionID,因此分布式的服务器不能共享sessionID。
token
token是用来认证(用户)和授权(APP)的;是令牌,访问资源接口(API
)时所需要的资源凭证。
token
是无状态的,客户端发送请求,服务器端生成token返回给客户端。- 客户端可以将
Token
保存在cookie
中也可以保存在localStorage
中。客户端下次请求时可以把token放在在Header
中的Authorization
字段发送给服务器。 - 服务器端不需要保存
sessionID
,只需要通过对token
使用秘钥进行解密获取用户信息,若得到的签名有效则可以进行下一步逻辑处理。 - 因为不会像
cookie
一样自动随请求发送给服务端,因此可以避免CSRF
攻击。 - 可以在分布式服务器中共享一个
token
,还可以应用在移动端APP中。
token的生成原理
四、设置cookie的samesite属性
Chrome51开始,浏览器设置了一个新的samesite
属性用来防止CSRF攻击。
samesite
samesite
用来限制第三方cookie,可以设置三个值:
- Strict
- Lax
- None
Strict最严格,只有当站点URL与请求站点相同时才会携带cookie
Lax是默认值,大多数情况也是不发送第三方 Cookie,但是导航到目标网址的 Get 请求除外。
参考博文:
[1]: http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html
[2]: http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html