这是我参与「第四届青训营 」笔记创作活动的第4天
cxrf攻击
跨站点请求伪造(Cross—Site Request Forgery)
- 盗用用户身份登录其他网站 进行操作
流程:
- 受害者登录a.com,并保留了登录凭证(Cookie)
- 攻击者引诱受害者访问了b.com
- b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会默认携带a.com的Cookie
- a.com接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求
- a.com以受害者的名义执行了act=xx
- 攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让a.com执行了自己定义的操作
预防:
-
阻止不明外域的访问
-
同源检测
-
Origin Header
- 无法用前端进行修改
- IE11不会在跨站请求添加Origin Header
- 302的重定向请求也不会添加Origin Header
-
Referer Header
-
由浏览器提供,有五种策略
-
设置方法
- 在CSP设置
- 页面头部增加meta标签
- a标签增加referrerpolicy属性
-
HTTPS页面跳转到HTTP页面,所有浏览器Referer都丢失。
-
-
-
Samesite Cookie
-
Samesite=Strict(严格模式)
表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie
-
Samesite=Lax(宽松模式)
假如这个请求是这种请求(改变了当前页面或者打开了新页面)且同时是个GET请求,则这个Cookie可以作为第三方Cookie。
Set-Cookie: foo=1; Samesite=Strict Set-Cookie: bar=2; Samesite=Lax Set-Cookie: baz=3
我们在 a.com 下发起对 b.com 的任意请求,foo 这个 Cookie 都不会被包含在 Cookie 请求头中,但 bar 会。
但假如这个请求是从 a.com 发起的对 b.com 的异步请求,或者页面跳转是通过表单的 post 提交触发的,则bar也不会发送。
举个实际的例子就是,假如淘宝网站用来识别用户登录与否的 Cookie 被设置成了 Samesite=Strict,那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后,淘宝都不会是登录状态,因为淘宝的服务器不会接受到那个 Cookie,其它网站发起的对淘宝的任意请求都不会带上那个 Cookie。
-
缺点:
- Samesite兼容性一般
- 不支持子域
-
-
-
提交时要求附加本域才能获取的信息
-
CSRF Token(可以使用分布式校验 token是一次计算的结果
- 将CSRF Token输出到页面中(token存在session中
- 页面提交的请求携带这个Token
- 服务器验证Token是否正确
-
双重Cookie验证
-
使用过程
- 在用户访问网站页面时,向请求域名注入一个Cookie,内容为随机字符串(例如csrfcookie=v8g9e4ksfhw)。
- 在前端向后端发起请求时,取出Cookie,并添加到URL的参数中(接上例POST www.a.com/comment?csr…)。
- 后端接口验证Cookie中的字段与URL参数中的字段是否一致,不一致则拒绝。
-
缺点:
- cookie中增加了额外的字段
- 如果有其他漏洞(例如XSS),攻击者可以注入Cookie,那么该防御方式失效。
- 难以做到子域名的隔离
- 为了确保Cookie传输安全,采用这种防御方式的最好确保用整站HTTPS的方式
-
-
-
保证页面的幂等性,后端接口不要在GET页面中做用户操作。