CSRF从0到1：我是怎么一步步搞懂这个“借刀杀人”的漏洞的
说实话,第一次听到“CSRF”这四个字母的时候，我整个人是懵的，那会儿刚学安全没多久，SQL注入还没整明白呢，又冒出来个新词儿，我当时心里就想：这又是什么鬼？能不能让人喘口气啊！
结果你猜怎么着？等我真正把CSRF从0到1这条线捋下来之后，发现它其实没那么吓人，甚至还有点“优雅”——是那种让开发者头疼、让攻击者偷笑的优雅，今天我就把自己踩过的坑、绕过的弯，完完整整地跟你唠一遍，保证你听完之后，也能从“啥玩意儿”变成“哦——原来是这么回事”。
先说个场景，你秒懂CSRF是啥
你登录了某银行的网站,cookie还在有效期对吧？然后你手贱，点开了某个“美女在线发牌”的链接（别问我为什么举这个例子，问就是见过），这个页面里藏了一个看不见的表单，你一打开，它就自动往银行接口发了一个转账请求，浏览器一看：哎？这是往银行发请求啊，cookie带上！钱就这么没了。
你可能会说：“啊？我又没输密码，怎么就转账成功了？”嘿，这就是CSRF最骚的地方——它压根不需要你的密码，它利用的是浏览器“自动携带凭证”的这个机制，再加上网站“过于信任已登录用户”的这个毛病，借你的手，干了坏事，用武侠小说里的话说，这叫“借刀杀人”；用程序员的话说，这叫“跨站请求伪造”，英文全称 Cross-Site Request Forgery，缩写就是 CSRF。
我第一次搞明白这个逻辑的时候,后背是真的发凉，你想啊，我啥也没干，就点了个链接，钱就没了？这也太不讲道理了吧！
从0开始：我是怎么一步步理解它的
要说CSRF从0到1这个过程，我得坦白，我走了不少弯路，一开始我以为它跟XSS是一回事，都是往页面里塞脚本，后来才发现，完全不是，XSS是“往你家墙上涂鸦”，CSRF是“冒充你去邻居家敲门”，两码事，但经常被拿来一起说，因为防御手段有时候会交叉。
我当时的理解路径大概是这样：
第0步：知道有这么个词，但不知道啥意思，看文章说“攻击者诱导用户点击链接”，我心里想：诱导？我又不傻，我怎么会点？——结果后来发现，诱导的方式五花八门，邮件、论坛、甚至一个img标签的src，都能成为攻击入口，防不胜防啊！
第1步：搞懂了“浏览器会自动带cookie”这个前提，这一步特别关键，如果你用的是无cookie的认证方式，比如Authorization头，那CSRF基本就废了一半，但现实是，大部分网站还是靠cookie，所以这个漏洞才有生存空间。
第1.5步：我亲手搭了个靶场试了一下，不试不知道，一试吓一跳，我写了个简单的HTML页面，里面放了个自动提交的表单，指向本地一个“转账接口”，打开页面的瞬间，请求就发出去了，cookie也带上了，接口还真就执行了，那一刻我盯着屏幕，心里就一个想法：就这？就这么简单？这也太离谱了吧！
第2步：开始琢磨怎么防，这才是我真正理解CSRF的开始，因为你要防它，就得知道它的“命门”在哪儿。
防御这事儿，说起来简单做起来坑
我见过太多文章一上来就说“加CSRF Token就行了”，但实际做起来，坑多到你怀疑人生。
第一个坑：Token放哪儿？ 放URL里？不行，会泄露在日志里，放隐藏表单字段里？可以，但只对表单提交有效，AJAX请求得手动带，放自定义请求头里？也行，但跨域的时候得配置CORS，我当时为了这个事儿纠结了一下午，最后发现：没有银弹，得看你的业务场景。
第二个坑：SameSite Cookie到底靠不靠谱？ 这玩意儿确实好用，设置成Lax或者Strict，能挡掉大部分CSRF，但是！老浏览器不支持啊，而且Strict模式下，从外站点过来的正常链接也会丢cookie，用户体验直接裂开，所以我现在一般建议：SameSite当第一道防线，Token当第二道，双保险才踏实。
第三个坑：验证Referer就万事大吉了？ 天真！Referer可以被篡改，可以被隐私设置屏蔽，甚至有些浏览器直接就不发，你要是指望它，早晚出事。
说真的,每次我跟人聊CSRF从0到1的防御，我都得强调一遍：别偷懒，别只做一层，攻击者比你想象的有耐心。
最后唠两句掏心窝子的
其实写这篇文章,不是想吓唬谁，我是觉得，CSRF这个漏洞吧，它不像SQL注入那么“暴力”，也不像XSS那么“显眼”，它安安静静的，甚至有点“礼貌”——它只是替你发了个请求而已，但恰恰是这种安静，才最危险。
如果你是个开发者,拜托了，花十分钟检查一下你的表单有没有Token，你的cookie有没有SameSite，如果你是个安全爱好者，那CSRF从0到1这条路，值得你走一遍，真的，走完你就再也不会忘了。
好了,今天就唠到这儿，有啥问题评论区见，我看到就回，咱们下篇见！