2 月份的 1.2 亿条用户地址信息泄露再次给各大公司敲响了警钟,数据安全的重要性愈加凸显,这也更加坚定了我们推行安全测试常态化的决心。随着测试组安全测试常态化的推进,有更多的同事对逻辑漏洞产生了兴趣,本系列文章旨在揭秘逻辑漏洞的范围、原理及预防措施,逐步提升大家的安全意识。第二篇选取了广为熟知的 CSRF 漏洞进行介绍。
1、CSRF 漏洞的定义
跨站请求伪造(Cross-site request forgery,简称 CSRF),攻击者利用受害者身份发起了 HTTP 请求,导致受害者在不知情的情况下进行了业务操作,如修改资料、提交订单、发布留言或评论等
2、CSRF 主要攻击形式
① GET 类型的 CSRF
这类攻击非常简单,只需要一个 HTTP 请求:
② POST 类型的 CSRF
这种类型的 CSRF 利用起来通常使用的是一个自动提交的表单,访问问该页面后,表单会自动提交,相当于模拟用户完成了一次 POST 操作。可见这种类型的 CSRF 与第一种一样,都是模拟请求,所以后端接口也不能将安全寄托在仅允许 POST 请求上。
③ 链接类型的 CSRF
链接类型的 CSRF 并不常见,比起其他两种用户打开页面就中招的情况,这种类型需要用户点击链接才会触发,但本质上与前两种一样。这种类型通常是在论坛发布的图片中嵌入恶意链接,或者以广告的形式诱导用户中招,攻击者通常会以比较夸张的词语诱骗用户点击,例如: 由于之前用户登录了信任的网站 A,并且保存登录状态,只要用户主动访问这个页面,则表示攻击成功。
3、CSRF 漏洞危害
CSRF 漏洞可能导致在用户不知情的情况下进行业务操作:
① 修改资料
② 提交订单
③ 发布留言或评论(关键操作、增删改)等
1、GET 类型的 CSRF
2、POST 类型的 CSRF
构造 form 表单类型的 poc,请求 addOrEdit 接口新增字典成功。
1、验证请求的 Referer 值
如果 Referer 是以⾃⼰的⽹站开头的域名,则说明该请求来⾃⽹站⾃⼰,是合法的。如果 Referer 是其他⽹站域名或空⽩,就有可能是 CSRF 攻击,那么服务器应拒绝该请求,但是此⽅法存在被绕过的可能。
2、请求中添加 token 并验证
CSRF 攻击之所以能够成功,是因为攻击者可以伪造⽤户的请求,由此,抵御 CSRF 攻击的关键在于:在请求中放⼊攻击者不能伪造的信息。例如可以在 HTTP 请求中以参数的形式加⼊⼀个随机产⽣的 token,并在服务器端验证 token,如果请求中没有 token 或者 token 的内容不正确,则认为该请求可能是 CSRF 攻击从⽽拒绝该请求。
1、GET 类型:
2、POST 类型的 CSRF
表单类型 POC 构造:
JSON 类型 POC 构造:
作者:京东物流 范文君
来源:京东云开发者社区 自猿其说 Tech 转载请注明来源