CSRF:跨站请求伪造（Cross-site request forgery）CSRF是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。当用户访问含有恶意代码的网页时,会向指定正常网站发送非本人意愿的数据请求包（如转账给hack,向hack发送API等）如果此时用户恰好登录了该正常网站（也就是身份验证是正常的）就会执行该恶意代码的请求，从而造成CSRF。
与在XSS章节中提到的在博客里写入获取cookie的代码，在管理员登录后台查看时就会窃取其cookie有异曲同工之妙跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任
pikachu靶场试验CSRF模块里登录进去抓个包看看"修改个人信息"的请求包 理论上来说 如果攻击者在自己的页面伪造了含有这个请求包的代码，一旦用户上钩点进恶意网站且pikachu属于登录状态就会触发CSRF漏洞
1）win10：pikachu靶场（模拟正常登录网站）【IP：192.168.168.1】
抓包查看请求数据包
这里是以GET方式请求 并将需要修改的数据传给服务器
ps：这里出现了Cookie，如果利用XSS漏洞在页面上插入并将Cookie发送给攻击者，那么攻击者会有机会直接登录用户的账号
2）win7：攻击者的恶意网站 【IP：192.168.168.128】
index.html
3）用户访问攻击者恶意网站且pikachu是登录状态
可以看到 用户如果没有查看将会无感的向攻击者指定的网站发送非本人的请求
且会发现该请求带上了正确的Cookie（对网站来说视为其本人发起了一个请求且通过了Cookie验证）
小Tips：
如果遇到了POST型，则需要构造一个表单提交按钮欺骗用户点击PS：超星尔雅学习通同样存在这样的CSRF，手法与该靶场演示手法类似，在校期间和同学进行实验点击链接后就可以更改其性别手机号等（当时戏称一键泰国变性XD）提交后对方以未对敏感数据造成影响打回了目前尚未修复，感兴趣的小伙伴可以自行尝试，手法及其相同，这里就不赘述了。
#防御方案1）当用户发送重要的请求时需要输入原始密码这样限制攻击者无法在完全无感的情况下执行CSRF，用户也会因此警觉2）设置随机 TokenToken：给用户第一次登录时设定的唯一值（且足够随机），在作出请求的时候必须携带这个Token才会生效，一方面减少了重复请求量，一方面也避免了大部分CSRF攻击3）同源策略，检验 referer 来源，请求时判断请求链接是否为当前管理员正在使用的页面（管理员在编辑文章，黑客发来恶意的修改密码链接，因为修改密码页面管理员并没有在操作，所以攻击失败）4）设置验证码5）限制请求方式只能为 POST