什么是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.大厂面试题
特别声明:
此教程为纯技术分享!本教程的目的决不是为那些怀有不良动机的人提供及技术支持!也不承担因为技术被滥用所产生的连带责任!本教程的目的在于最大限度地唤醒大家对网络安全的重视,并采取相应的安全措施,从而减少由网络安全而带来的经济损失。