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