
CSRF ( Cross Site Request Forgery ,跨站请求伪造)是一种 Web 应用攻击方式,该攻击可以
在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点,从而在并未授权的情况下执行在权限保护之下的操作,具有很大危害性。
CSRF 关键点:
-
攻击目标: web 应用的用户,不仅限于普通用户;中
-
必要条件:伪造的请求是用户在存在漏洞的服务器经过身份认证之后发起;
-
跨站:用扁访问政击者服务器,导致浏览器被控制向目标服务器发起操作谓求,用扁光法感知
-
伪造:在攻击者预先设定的页面中,包含执行特定操作行为所需要传递的参数。
-
身份认证之后:跨域的请求中会带上目标网站的 cookie ,在身份认证前目标用户并股有执行权限,需要在身份认证之后攻击才能成功。
注 CSRFTOKEN 参数既可能在报文头,也可能在报文参数中。
CSRF 攻击步骤总结
1、寻找可能存在 CSRF 漏洞的请求
这类请求的特点如下:
-
没有设置 CSRF token ;
-
该请求执行特权/关键操作(如增删改,用户修改密码功能的表单,更新个人信息功能的表单,用户账号邮箱或手机绑定表单,支付,转账等);
-
应用程序仅依靠 HTTP cookie 来追踪会,请求中所有的参数均可以予预测;
-
攻击者可以确定执行操作。
2、POST 转 GET (可有可无)
表单通常使用 GET 和 POST 方式提交,但是 web 应用程序并不一定会分开处理 GET
请求和 POST 请求,将 POST 请求转变为 GET 请求更加的方便构造 Payload 与同时也更加容易隐蔽。
3、构造 payload
根据 Web 应用程序是否支持 GET 或者 POST ,构造特定的 Payload 。
Payload 的构造方法有2种:
GET 型 payload :
<img src=”http://pay.SC.weibo.com/aj/service/folowed?uid=你自己的& ispage =1& t =0″>
POST 型 payload (通过 js 脚本执行表单提交):
<form id =” demo ´ name = demo actlon =”http://pay.sC.welbo.com/al/service/followed” method =” POST “>
<input type =”text ” name =´”uid” value =”3975359730″/>
<input type = “text” name =”isoage” value =”1″/>
<input type=”text” name =”_T” value =”0″/>
<input type = “submit ” value =”submit” />
小技:使用 burpsuite 拦截请求,将请求发送到 repeater 之后,右键,选择“ Generate CSRF Po 即可快速生成 POSТ型 Payload
4、测试 POC .
将构造的 Payload ,编写为一个完整的 HTML 页面,然后利用浏览器打开,查看请求和响应数据包。
要测试 CSRF ,首先需要予预先登录 Web 应用程序,与服务端建立会话,然后在新的标签页中打开 Payload ,如果返回修改成功则存在 CSRF ,如果返回 Error 则可能不存在 CSRF ,或者应用程序可能使用了 CSRF 防御措施。
5、绕过防御
有时发现应用系统表面上加了令牌机制用于防犯跨站伪造请求,然而有些时候总会出现一些形同虚设的情况。
-
去掉请求中的 token 参数, Web 应用程序依然正常执行。
-
使用可预测的 CSRF token 值,攻击者能有效的子页测 token 值。
例如校验了请求中的 referer , Web 应用程序通过判断 referer 是否是属于可信来源,决定是否处理客户端请求。这种情况下,需要对 cSRF 防御措施进行分析,查看是否能够绕过。
-
绕过 referer 检测:
可以通过抓取正常访问的请求包,确定 Web 应用程序所接收的 referer 。
服务端的 referer 检测一般是采用正则匹配的方式来判断是否为可信来源。+
通过 Fuzzing 的方法测试能通过正则表达式校验的可控制 referer ( referer 的验证策略决定测试的复杂度),检测能否绕过 referer 校验。
一、攻击场景
1、无令牌机制保护
-
描述:
许多应用系统都有一些重要的操作,如添加用户、角色;转账、修改密码等等。这些操作没有添加相应的令牌机制(用于识别是否授权人员本人操作),则非授权人员有可能通过伪造请求利用已授权人员的身份执行非自愿的操作。
-
测试方法
首先登录应用系统,寻找网站的关键性操作(视具体的业务系统而定),这里只以通用的增加用户操作为例。由于目前的表单大多以 Post 方法提交为主,因此这里以 Post 方法为例。配置代理工具后,打开添加用户的页面,点击网页上添加用户的按钮提交请求,代理工具将会拦截请求,请求中包合提交的字段以及提交的目标 URL。
假设提交的请求中包括用户名( testUserName )和密码( testPassWord )两个字段,提交的目标 URL 为http://xXx.XXx.xxx.Xxx/xxx/test.action,编写测试页面,代码如下:

最后将此测试页面放入浏览器中运行(运行测试页面时必须保持会话状态,即保持登录状态)查看用户管理,如果应用系统中已经成功添加用户名test n,则证明该应用系统存在跨站伪造请求的漏洞,
2、无效的令牌机制
-
描述
有时发现应用系统表面上加了令牌机制用于防犯跨站伪造请求,然而有些时候总会出现一些形同虚设的情况。
去掉请求中的 token 参数, Web 应用程序依然正常执行。使用可预测的 CSRF token 值,攻击者能有效的页测 token 值。
-
测试方法
绕过请求头 X – CSRF – TOKEN 的校验
通过拦截应用系统中的请求,发现在请求头存在这样一个字段 X – CSRF – TOKEN ,从字面上看该请求头似平是为防 CSRF 而定的,通过任意修改该请求头的值或者删除该请求头,再对请求进行重放,发现请求还是正常执行了,因此判断该令牌机制无效
绕过 referer 校验
新浪活动幸运对对碰,可以通过转发分享获得抽奖机会。
通过对转发接ロ分析,该处使用了 referer 校验请求源是否可信,通过分析 referer 规则,发现可以绕过 referer 检测,从而导致 CSRF 漏洞。
绕过方式:http://wanwan.sina.com.cn.XX.XX/a.php-
构造攻击者的城名为:http://wanwan.sina.com.cn.lunull.tk/sina csrf . php + Payload 页面为:

将存在payload的网站发给用户,诱使用户点击,用户在不知情的情况下,发送一条消息,CSRF攻击成功。
二、影响
可能导致攻击者利用合法用户的身份执行非授权的操作。
三、典型案例
CSRF 结合 PHP 一句话木马获取 webshel –
后台新建模板功能可创建 php 后缀文件,利用 PHP 一句话木马和 CSRF 相结合,获取 webshell -在知道创建文件的请求后,新建一个 payload 页面,内容如下:
针对以上缺陷构造 Payload ,诱使登录的管理员访问 Payload 页面。即利用管理员身份执行后台功能,获取网站 webshell

由于被测系统存在 CSRF 漏洞,诱使管理员访问 payload 页面后, POST 请求被提交,成功的在后台创建了一个名为 test 的文件,文件内容是一句话木马。然后利用中国菜刀,即可 get webshell 。
评论0