WebGoat学习——跨站请求伪造(Cross Site Request Forgery (CSRF))
跨站请求伪造(Cross Site Request Forgery (CSRF))
跨站请求伪造(Cross Site Request Forgery (CSRF))也被称为:one click attack/session riding,缩写为:CSRF/XSRF,是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。攻击人员通过一些手段让终端用户点击存在攻击的链接或者页面,例如攻击人员通过xss漏洞在终端用户的页面中执行<img src="http://www.mybank.com/sendFunds.do?acctId=123456", width=”0” height=”0”/>,或者将这个代码放在一个具有诱惑性的页面中,亦或者将链接直接放在论坛帖子中。
CSRF攻击原理
1. 用户登录可信任的网站A(存在缺陷的交易网站);
2. 网站A返回登录session信息并将session存储在本地cookie;
3. 用户访问其他网站B(论坛、好友发送页面),网站B中包含执行网站A相关操作的请求操作(转账URL、退款URL)并且能够直接执行;
4. 网站B页面加载过程中携带网站A的cookie将请求发送到网站A的服务器;
5. 网站A服务器根据请求校验用户信息后执行具体操作(资金损失),从而达到了模拟用户在网站A的相关操作使用户或者网站A遭受伤害或损失。
下图为一具体的流程:
图1 CSRF原理示例
用户被攻击的两个条件是:
1. 登录了网站A并在本地保存了cookie;
2. 在未退出网站A或者清除cookie的情况下访问了网站B,并且在网站B帮助用户向网站A提交了请求。
具体示例
用户A登录某交易网站下单,生成订单号:123456789,支付金额:100.00,卖家:用户B,改价URL:
http://www.xxxxx.com/changeprice?orderId=123456789&fromprice=100.00&toPrice=0.01
用户A在自己的各网站(或者空间)中放入带下面一段代码:
<img src="http://www.xxxxx.com/changeprice?orderId=123456789&fromPrice=100.00&toPrice=0.01", width=”0” height=”0”/>
然后用户A将自己的网站给到用户B,并欺骗B说里面有同样的商品等等。用户B想点开看看也没关系,于是页面被打开了,上面的代码就被执行了,用户B在无感知的情况下想服务器发送改价申请。
实际情况下注入的代码可能会更为复杂,例如服务器不接受get请求,用户A可以在自己网站注入下面代码:
<html> <head> <script type="text/javascript"> function changeprice() { iframe = document.frames["changeprice"]; iframe.document.Submit("test"); } </script> </head> <body onload="changeprice()"> <iframe name="changeprice" display="none"> <form method="POST" name="test" action="http://www.xxxxx.com/changeprice"> <input type="hidden" name="orderId" value="123456789"> <input type="hidden" name="fromPrice" value="100.00">
<input type="hidden" name="toPrice" value="0.01"> </form> </iframe> </body> </html>
服务器做了特殊处理,在收到请求后需要用户发送确认操作才行,即需要第二个确认请求服务器才会执行用户请求,对于这种情况用户A只需在个人网站上继续添加一些javascript代码即可隐藏的调用改价请求和确认改价请求,作者限于html和js技术不做具体案例实现。
CSRF防御
1. token校验
用户进行操作交互前先构造一个token值(随机数),后续每次操作请求必须带上token值,服务器校验token合法后才进行相关操作,这样黑客因为无法提前获知用户的token,就无法构造出正确的操作URL。加上token后操作URL必须带上一随机值,如下:
http://www.xxxxx.com/changeprice?orderId=123456789&fromprice=100.00&toPrice=0.01&t=rand()
按照之前的攻击执行结果如下:
坏人因为没有小白的token信息,因此伪造的URL是不能被服务器处理的,从而导致阴谋无法得逞。
这个方法已经可以杜绝99%的CSRF攻击,由于用户的Cookie很容易由于网站的XSS漏洞而被盗取,这就另外的1%。一般的攻击者看到有需要算token值,基本都会放弃了,某些除外,所以如果需要100%的杜绝,这个不是最好的方法。
(2).验证码
这个方案的思路是:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,这个方案可以完全解决CSRF,但在易用性方面似乎不是太好。