从原理到实操：CSRF跨站伪造防护保姆级避坑实用指南

各位前后端的兄弟姊妹们，说出来你们可能不信，我上个月刚因为没做CSRF跨站伪造防护踩了个大坑：公司刚上线的新人优惠券活动，被黑产用CSRF漏洞薅了三万多的无门槛券，老板追着我在公司园区骂了半圈，最后扣了我两个月绩效才完事。这不刚把漏洞补完，今天掏心窝子给你们唠唠CSRF跨站伪造防护那点事，全是我实打实踩坑试出来的干货，没有半句虚的。

先唠明白：CSRF到底是个啥损色？

我给你们整个魔性比喻，一听就懂：你把用户已登录的业务网站当成你家小区，用户登录成功后网站下发的Cookie就是小区门禁卡，浏览器自动存着就相当于你把卡揣兜里，每次进小区刷一下（访问网站接口），保安一看卡有效就直接放行。

那CSRF就是专门钻这个空子的骗子：他搞个“点击领10斤鸡蛋”的野鸡链接，诱导你点进去，这个野鸡页面啥都不显示，偷偷在后台发起一个“给骗子账户转1000块”“把我的收货地址改成骗子家”的请求，浏览器会自动把你存的小区门禁卡（Cookie）带过去，保安一看有有效门禁卡，直接就把请求给过了，你啥都没干钱没了/优惠券被领了，哭都找不到地方。

说回专业定义其实就一句话：CSRF是攻击者利用用户已登录的身份凭证，诱导用户在不知情的情况下发起非本意操作的攻击手段。我之前就是觉得小网站没人盯着，嫌CSRF跨站伪造防护做起来麻烦，结果真被人盯上了才知道疼，真的奉劝各位，只要你的网站有用户登录功能，CSRF跨站伪造防护必须提前安排上，别等出事了再补。

CSRF跨站伪造防护3招，全是我踩坑试出来的好用招

我当时补漏洞的时候查了一堆资料，踩了好几个没用的坑，最后筛选出来3招，搭配着用基本能防住99.9%的CSRF攻击，亲测半年多没再出过问题。

第一招：给请求加专属验证码，就像进小区刷脸+刷卡双验证

这招就是咱们常说的CSRF Token机制，原理很简单：你给小区加个规则，凡是要提交改地址、转钱这种敏感操作的，除了要刷门禁卡，还要拿一个物业当天给你发的专属验证码，这个验证码只有你在小区官网里才能拿到，骗子的野鸡网站跨站根本拿不到，就算偷了你的门禁卡也没用。

具体操作也不复杂，我把我在用的代码放这，你们直接抄就行：

``` // 后端Node.js生成CSRF Token示例（存到用户session或Redis里） const crypto = require('crypto'); const csrfToken = crypto.randomBytes(32).toString('hex'); req.session.csrfToken = csrfToken; // 前端每次发起非GET请求时，把Token放在请求头里携带 axios.defaults.headers.common['X-CSRF-Token'] = window.csrfToken; // 后端接收请求时先校验Token是否匹配，不匹配直接返回403 if(req.headers['x-csrf-token'] !== req.session.csrfToken) { return res.status(403).send('非法请求'); } ```

这招我亲测是真好用，相当于给你的敏感接口上了双保险，我当时刚加上这一层，当天就拦了几百条非法请求。说白了CSRF跨站伪造防护核心就是要多一层只有你和网站知道的凭证，骗子拿不到自然就攻不进来，稳得一批。

第二招：给Cookie穿防弹衣，设置SameSite属性断了骗子的路

这招属于从根源上堵漏洞，相当于你给你的门禁卡加了个GPS定位，只有你在小区范围内（本站点页面）用的时候才生效，你在外面野鸡网站点链接的时候，这个门禁卡自动失效，骗子根本用不了。

操作也特别简单，就是给你的业务Cookie加SameSite属性，我一般都设成Lax，兼顾安全和用户体验：

``` // 后端设置Cookie的响应头示例 Set-Cookie: sessionId=abc123456; SameSite=Lax; HttpOnly; Secure; Path=/ ```

给你们解释下这几个参数的意思：SameSite=Lax就是只有本站点的请求或者顶级导航的GET请求才会携带Cookie，野鸡网站的POST请求/嵌入的img/iframe请求都带不上；HttpOnly是防止XSS漏洞偷Cookie，Secure是要求必须在HTTPS环境下才传输Cookie，三个搭配着用效果拉满。

我之前就是没给Cookie加SameSite属性，骗子随便整个嵌入请求就能带用户的Cookie，加了之后当天就把90%的CSRF攻击都拦在外面了，CSRF跨站伪造防护这招属于成本极低效果极好的，5分钟就能配完，真的建议所有人都去加上。

第三招：查户口式校验请求来源，Referer/Origin头全给安排上

这招就相当于小区保安多问一句“你从哪来的”，后端每次接收请求的时候，都校验下请求头里的Origin或者Referer值，要是来源不是咱们自己的域名，直接就给拦下来。

当然这招有个小注意点：部分场景下Referer可能为空，比如用户从书签访问、或者浏览器开启了隐私模式，这种情况可以单独加个白名单，别直接一刀切把正常用户给拦了。我一般是把这招当成补充防护，和前面两招搭配着用，相当于多上了一层保险。

我现在就是三个招一起用，三重CSRF跨站伪造防护叠buff，上次有个搞黑产的试了800多次都没攻进来，老板特意给我发了两千块奖金，算是把之前扣的绩效赚回来一半。

别踩我踩过的坑，CSRF跨站伪造防护的几个注意事项

• 别觉得只有POST请求需要防护：我之前有个同事图省事把改密码的接口做成了GET请求，结果人家把请求地址放到img标签里，用户只要点开页面就自动发起改密码请求，当天就有十几个用户账号被盗，真的别偷懒，所有敏感操作都要用POST，所有请求都要做校验。
• 别把CSRF Token存在LocalStorage里就万事大吉：要是你的网站有XSS漏洞，LocalStorage里的内容会被直接偷走，一定要配合HttpOnly的Cookie一起用，同时做好XSS防护，别左边加了防护右边漏了窟窿。
• 别觉得小网站没人攻就不做防护：我之前就是这种心态，觉得我们公司那个小电商平台没人看得上，结果黑产根本不管你大小，只要有漏洞就薅，真等损失了钱扣了绩效，哭都来不及。

说真的，咱们做开发的，别总觉得安全是运维的事，CSRF跨站伪造防护这种花个半天就能全做好的事，提前安排上真的省得后面背锅。我这三招都是亲测好使的，你照着装上去，CSRF跨站伪造防护的事基本就稳了，今年年底绩效拿A了别忘了来给我报喜啊！