跨站请求伪造（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，但在易用性方面似乎不是太好。

标签: WebGoat, Web前端, Web安全, Cross Site Request Forgery, CSRF