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 转载请注明来源
