跨站请求伪造--CSRF

什么是CSRF?

CSRF跨站请求伪造:也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本攻击(XSS),但他与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自手信任用户的请求来利用受信任的的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。具体如图所示:

成因

由于网站的cookie在浏览器中不会过期只要不关闭浏览器或者退出登录,那以后只要是访问这个网站,都会默认你已经登录的状态。而在这个期间,攻击者发送了构造好的csrf版本或包含csrf脚本的链接。可能会执行一些用户不想做的功能(比如是添加账号等)

危害

攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你的名义发送邮件、发消息,盗取你的账号,甚至于购买商品、虚拟货币转账……造成的问题包括:个人隐私泄露以及财产安全

怎么快速生成CSRF,Burpsuite可以快速生成CSRF poc

Burpsuite可以快速生成CSRF poc

如何预防CSRF

验证HTTP Referer字段

根据HTTP协议,在HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。在通常情况下,访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成,用户必须先登录bank.test,然后通过点击页面上的按钮来触发转账事件。当用户提交请求时,该转账请求的Referer值就会是转账按钮所在页面的URL(本例中,通常是以bank. test域名开头的地址)。而如果攻击者要对银行网站实施CSRF攻击,他只能在自己的网站构造请求,当用户通过攻击者的网站发送请求到银行时,该请求的Referer是指向攻击者的网站。因此,要防御CSRF攻击,银行网站只需要对于每一个转账请求验证其Referer值,如果是以bank. test开头的域名,则说明该请求是来自银行网站自己的请求,是合法的。如果Referer是其他网站的话,就有可能是CSRF攻击,则拒绝该请求。

在请求地址中添加token并验证

CSRF攻击之所以能够成功,是因为攻击者可以伪造用户的请求,该请求中所有的用户验证信息都存在于Cookie中,因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知,抵御CSRF攻击的关键在于:在请求中放入攻击者所不能伪造的信息,并且该信息不存在于Cookie之中。鉴于此,系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务器端建立一个拦截器来验证这个token,如果请求中没有token或者token内容不正确,则认为可能是CSRF攻击而拒绝该请求。

XSS与CSRF的区别

XSS核心目标在于操作目标网站的HTML代码,以窃取cookie

CSRF核心是在非目标网站的HTML代码中做手脚让浏览器偷偷地去访问目标网站

实例分析

下面看一个没有CSRF防护的dedecms网站(可以本地搭建一个)

 这是该网站的后台,点击左侧的“文件式管理器”,可以尝试新建一些不正常的文件,比如新建一个1.php

 再尝试写一个一句话木马

 并保存。之后传参

 

 说明已经连接上数据库,之后可以再上菜刀

 但是其实当你当登录到后台时,就说明已经获得管理员权限了。当你不知道后台密码时,就可以考虑利用该网站潜在的CSRF漏洞从而getshell

一样地,在那里新建文件,在保存时进行抓包,通过burp自带的功能
右键选择engagement tools -> create csrf poc ,得到一个html代码

7.注销登录管理员界面,打开刚刚那个网页,点击按钮,会访问管理员界面并且保存

8.通过访问那个文件,与前面方法一样,可以getshell

9.之后连菜刀,找到flag.php,访问,得到flag

 

猜你喜欢

转载自www.cnblogs.com/pyh123456/p/12376975.html