本文主要是介绍学前端网络安全这块还不懂？细说CSRF，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
什么是CSRF？
举个栗子，比如我们需要在某个博客上删除一个文章，攻击者首先在自己的域构造一个页面，使用了一个img标签，其地址指向了删除博客的链接。攻击者诱使目标用户，也就是博客主访问这个页面，该用户看到了一张无法显示的一张图片，这时候在回头看看该博客的这篇文章，发现文章已经被删除了，原来刚才的图片链接香博客服务器发送了一个get请求，而这次请求，导致了博客上的一边文章被删除了。在整个攻击过成功，攻击者仅仅诱使用户访问了一个页面，就以该用户身份的第三方站点里执行了一次操作。这个删除博客文章的请求都是攻击者所伪造的，所以这种攻击就叫做“跨站点请求伪造”。
浏览器cookie策略
攻击者伪造的请求之所以能够被服务器验证通过，是因为用户的浏览器发送了cookie的缘故。浏览器所持有的cookie分为两种：一种是‘Session Cookie’,又称“临时Cookie”：另一种是“Third-party Cookie”,也称为“本地Cookie”。两者的区别在于，后者是服务器在Set-Cookie时制定了Expire实践，只有到了Expire时间后Cookie才会失效，所以这种Cookie才会失效，所以这种Cookie会保存在本地：而Session Cookie则没有制定Expire时间，所以浏览器关闭后，Session Cookie就失效了。
在浏览网站过成功如果一个网站设置了Session Cookie,那么在浏览器进程的生命周期内，即使浏览器新打开了Tab页， Session Cookie也都是有效的。Session Cookie保存在浏览器进程的内存空间中；而Third-party Cookie则保存在本地。
在当前的主流浏览器中，默认会拦截Third=party Cookie的有：IE6、IE7、IE8、safari；不会拦截的有火狐2、火狐3、oprea、Google Chrome、Android等。
但若CSRF攻击的目标并不需要使用Cookie，则也不必顾虑浏览器的Cookie策略了。
P3P头的副作用
尽管有些CSRF攻击实施起来不需要验证，不需要发送Cookie，但是不可否认的是，大部分敏感或重要的操作是躲藏认证之后的。因此浏览器第三方Cookie的发送，在某些程度上来说是降低了CSRF攻击的威力。可是这一情况在P3P头介入后变得复杂起来。P3P header是w3c制定的一项关于隐私的标准，如果网站返回浏览器的Http的头中包含有P3P头，则在某种程度上来说，将允许浏览器发送第三方Cookie。
举个栗子，前端通过iframe去加载一段后端代码，后端代码尝试设置set-Cookie，浏览器会受到一个cookie，如果setcookie成功，再次请求该页面时，浏览器会发送刚才收到的Cookie。可是由于跨域显示，set-cookie是不会成功的，所以无法发送刚才收到Cookie。这里无论时临时Cookie还是本地Cookie都一样。第二次发包，只是再次接收到Cookie，上次set-COOKIE的值并不曾发送，说明没有Set-Cookie成功。但是这种情况在加入P3P头后会有所改变，P3P头允许跨域访问隐私数据，从而可以跨域Set-Cookie成功。
P3P头的介入改变了隐私策略，从而使得iframe，script等标签在IE中不在拦截第三方Cookie的发送。P3P头只需要由网站设置一次即可，之后每次请求都会遵循此策略，而不需要再重复设置。
P3P头目前是网站的应用中被广泛应用，因此CSRF的防御中不能依赖于浏览器对第三方Cookie的拦截策略。
请求方式
在CSRF攻击流行之初，曾经认为只能由Get请求发起的，因此很多开发把一些重要操作改成了post请求，但是这种观点是错误的，主要原因是因为大多数的CSRF的攻击发起都是通过标签属性，这类标签只能够发起一次get请求，而不能发起post请求。
可行的CSRF的防御
1. 验证码
验证码是被认为对抗CSRF攻击最简洁有效的防御方法。强制用户必须与应用进行交互，才能完成最终请求。因此，验证码能够很好的遏制CSRF。但是非万能的，不可能在用户的所有操作上加上验证码，只能当做辅助的一种手段，而不能作为最重要的解决方案。
2. Referer Check
这种方法可以被用于检查请求是否来自合法的“源”。 常见的互联网应用，页面与页面之间都具有一定的逻辑关系，这就是使得每个正常请求的Referer具有一定的规律。缺陷在于，服务器并非什么时候都能拿到Referer。很多用户处于隐私保护考虑，限制了Referer的发送。在某些情况 下，浏览器也不会发送Referer，比如从Https跳转到Http，出于安全考虑，浏览器也不会发送Referer。所以该方法也不能作为主要手段。
Token
CSRF的本质：重要操作的所有参数都可以被攻击者猜测到。攻击者只有预测出URL的所有参数与参数值，才能成功地构造出一个伪造的请求；反之，攻击者无法攻击成功。因此我们需要一个更加通用的解决方案帮助解决这个问题，这个方案就是使用token。
token是随机的，也是不可预测的。token需要足够随机，必须使用足够安全的随机数生成算法，或者采用真随机数生成器。token应该相当于一个‘秘密’，为用户与服务器所共同拥有的，不能被第三者知晓。在实际应用中，token可以放在用户的Session，cookie，localstorage中，由于token存在，攻击者无法在构造出一个完成的url实施CSRF攻击。 token需要同时放在表单和Session中，在提交请求时，服务器只需验证表单中Token与用户Session中的Token是否一致，如果一致，则认为是合法请求；如果不一致，或者有一个为空，则认为请求不合法，可能发生了CSRF。
防御CSRF的token，是根据 “不可预测性原则”的设计方案，所以token生成一定要足够随机，需要使用安全的随机数生成器生成token。token目的不是为了防止重复提交。所以为了使用方便，可以允许在一个用户有效生命周期内，在token消耗掉前都使用同一个token。但是如果用户已经提交表单，则这个token已经消耗掉，应该再次重新生成一个新的token。
使用token时应该注意token的保密性，token如果出现在某个页面的url中，则可能会通过Referer的方式泄露。使用token时，应该尽量吧token放在表单中，把get变为post，避免token泄露。
CSRF的token仅仅用于对抗CSRF攻击，当网站还同时存在XSS漏洞时，这个方案就会变得无效，因为Xss可以模拟客户浏览器执行任意操作。在XSS攻击下，攻击者完全可以请求页面后，读出页面内容的token值，然后在构造出一个合法的请求。这个过程称为XSRF，这里不做详细阐述。
各位大佬，献丑了！！
网络安全学习路线 （2024最新整理）
如图片过大被平台压缩导致看不清的话，评论区点赞和评论区留言扣1或者关注我我后台会主动发给你！
第一阶段：安全基础
网络安全行业与法规
Linux操作系统
计算机网络
HTML PHP Mysql Python基础到实战掌握
第二阶段：信息收集
IP信息收集
域名信息收集
服务器信息收集
Web网站信息收集
Google hacking
Fofa网络安全测绘
第三阶段：Web安全
SQL注入漏洞
XSS
CSRF漏洞
文件上传漏洞
文件包含漏洞
SSRF漏洞
XXE漏洞
远程代码执行漏洞
密码暴力破解与防御
中间件解析漏洞
反序列化漏洞
第四阶段：渗透工具
MSF
Cobalt strike
Burp suite
Nessus Appscea AWVS
Goby XRay
Sqlmap
Nmap
Kali
第五阶段：实战挖洞
漏洞挖掘技巧
Src
Cnvd
众测项目
热门CVE漏洞复现
靶场实战
学习资料的推荐
学习框架已经整理完毕，现在就差资料资源了，我这里整理了所有知识点对应的资料资源文档，大家不想一个一个去找的话，可以参考一下这些资料！
1.视频教程
2.SRC技术文档&PDF书籍
3.大厂面试题
特别声明：
此教程为纯技术分享！本教程的目的决不是为那些怀有不良动机的人提供及技术支持！也不承担因为技术被滥用所产生的连带责任！本教程的目的在于最大限度地唤醒大家对网络安全的重视，并采取相应的安全措施，从而减少由网络安全而带来的经济损失。
这篇关于学前端网络安全这块还不懂？细说CSRF的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
