Pikachu对于CSRF的解释：
CSRF(跨站请求伪造)概述
Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为”one click”攻击。 很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
这里列举一个场景解释一下，希望能够帮助你理解。
场景需求：
小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。
先看下大白是如何修改自己的密码的：
登录—-修改会员信息，提交请求—-修改成功。
所以小黑想要修改大白的信息，他需要拥有：1，登录权限 2，修改个人信息的请求。
但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？
于是他自己跑到www.xx.com上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是：
【http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change】
于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点：
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
—-因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上;
—-如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。
—-因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。
当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做： 欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。
—-所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
因此，网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
—对敏感信息的操作增加安全的token；
—对敏感信息的操作增加安全的验证码；
—对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。
我的理解：
所谓CSRF，就是一个网站的一些敏感操作可以被伪造（就是登陆后访问某个链接就可以完成敏感操作）。然后再这个用户登录A网站的时候，诱惑他点一下某个链接，然后这个链接其实是伪造的一个操作请求，比如修改密码，或者转账。然后它点了后，就不知不觉做了这些操作，所以CSRF叫跨站请求伪造，XSS叫跨站脚本攻击，XSS是盗你权限干坏事，CSRF是借你自己的权限干坏事。总感觉CSRF条件有点苛刻啊，一是要你登录，二是伪造请求，三是诱惑你点，多不容易啊。
CSRF成功前提：1 目标登录，2 伪造请求，3 诱惑目标点击链接
- CSRF（get）：
这个东西其实我是有点微微迷糊的，我就对sql注入和xss熟悉一点点，所以我先看看CSDN博客再说。
先登录
点击修改个人信息
直接就改了。靠，看样子要用burp抓包，burp 启动！
/pikachu/vul/csrf/csrfget/csrfget_edit.php?sex=%E5%A5%B3&phonenum=12345678910&add=%E9%83%BD%E6%B1%9F%E5%A0%B0&email=123%40qq.com&submit=submit
修改一下
http://39.99.148.85/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=女&phonenum=12345678910&add=都江堰&email=123@qq.com&submit=submit
意思就是说，我点了submit按钮，页面就会对上面这个链接发起get请求，从而完成信息的修改。那么我把其中的信息改成我想改的，然后再让vince用户点一下，从而产生一次CSRF攻击。
那我自己写个html，再弄个a标签，href属性就弄这个链接，应该就可以实现CSRF攻击了，如图
本来应该使用img src来悄无声息的更改信息，但是img的请求不带cookie，成功不了，搞不明白，功夫不行，放着以后再说吧。
下一关
记录一下，由于我不甘心，想尝试自己写个页面，访问后就会自动提交get表单到修改信息的网址，已经成功了，只是会多弹出一个页面而已。但是依然想不通为什么img的src属性不能悄无声息的完成CSRF攻击，CSRF攻击本来就不容易了，需要天时地利人和，难道还要让它不能悄无声息的攻击吗，如果不能悄无声息的话，那受害者又不是傻子，肯定会察觉啊。
于是突发奇想，img标签不成功会不会和chrome谷歌浏览器有关系，一搜果然，见这篇博客：[传送阵](https://blog.csdn.net/connection/article/details/121897816)，大致意思说chrome从51版本就自动给cookie加了个Samesite属性，专门用来防止不同源的请求携带cookie，专门用来防范CSRF的，可把我们折磨惨了，靠，原来不是我们的问题，经过兄弟测试，搜狗浏览器的img就可以成功，所以浏览器的不同，也会影响CSRF。
今天是2022年5月20号，有感而发，纪念一下，在实验过程中又学到不少东西，比如：document.表单name.submit()可以自动提交表单，但是form标签里面不能再有name=’submit’的input，还有表单点击提交后会自动触发一个叫onsubmit()的方法，还有前面的submit()会导致onsubmit不再触发，还可以通过：document.表单name.提交按钮name.click()来自动点击按钮，搭配哪些on事件使用，比如：onclick 当你点击 onload 当你加载 onmouseover 当你鼠标经过
小总结：其实这道题没那么复杂，出题者本意和博客的意思就是说：”那个请求修改信息的链接，你把它复制修改，修改其中的几个信息，然后再访问，当作是点的不知情的链接，就可以了。“
对了，我在存储型XSS留言板哪里插入了一个XSS，只要访问那个界面，也可以悄无声息的修改信息。Payload为： 我是一条很正常的留言
这也是我老师口中的XSS和CSRF的组合拳吧，就是条件太苛刻了。
- CSRF(post)：
顾名思义，看到post，我就猜到要自己写一个页面，有表单有按钮，然后再诱惑访问。刚好上一关写了一个get的，把form里面的method值换成post，再把action的值改成post的链接应该就行。
注意：作者写的判断条件是如果submit有值，才会往下继续判断，所以JavaScript中的submit()不可用，可以使用onmouseover=”document.formname.submitname.click()”来实现悄无声息提交。如图
附上样式，美女图片自找
只要我鼠标经过图片的任意地方，就可以实现post的CSRF攻击，如图
成功，下一关
- CSRF Token：
token主要是拿来代替session的和减轻服务器压力，当然用来防CSRF也相当不错。如此说来，这关有可能很难过，甚至过不了，先试试看吧。
post请求携带了token，看看前端有没有线索
找到了，有点像token防密码爆破啊，刷新看看。
刷新就不一样了，这可是专门来防止CSRF的，破不了，至少博客都是那么说的，至此Pikachu的CSRF全部结束。
小总结一下：任何漏洞利用成功都是要有前提的，CSRF成功的前提有点多啊。
- 目标已登录
- 坏人伪造请求
- 诱惑目标点击链接或访问页面
- 没用Google等外国浏览器
修复建议，所有敏感请求都加随机token，再多来几个验证，这样就可以让敏感请求不能伪造了。
还有，通过Google浏览器让我明白，这些经典漏洞很可能也会逐渐消失吧，特别是CSRF这个需要天时地利人和的漏洞，它还是和XSS打配合吧。
若有收获，就点个赞吧
0 人点赞
