一. CSRF攻击
CSRF（Cross-site request forgery），跨站请求伪造。
攻击者盗用用户身份，以用户身份发送恶意请求。
CSRF能够做的事情包括：以用户名义发送邮件，发消息，盗取账号，甚至于购买商品，虚拟货币转账......
造成的问题包括：个人隐私泄露以及财产安全。
产生CSRF攻击的前提步骤
- 登录受信任网站A，并在本地生成Cookie 。
- 在不退出A的情况下，访问危险网站B。
For example
1.
Dangerous website:
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
2.
Bank website :
<form action="Transfer.php" method="POST">
<p>ToBankId: <input type="text" name="toBankId" /></p>
<p>Money: <input type="text" name="money" /></p>
<p><input type="submit" value="Transfer" /></p>
</form>
Transfer.php
<?php
session_start();
if (isset($_REQUEST['toBankId'] && isset($_REQUEST['money']))
{
buy_stocks($_REQUEST['toBankId'], $_REQUEST['money']);
}/*$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，
这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据*/
?>
Dangerous website:
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
3.
Transfer.php
<?php
session_start();
if (isset($_POST['toBankId'] && isset($_POST['money']))
{
buy_stocks($_POST['toBankId'], $_POST['money']);
}
?>
Dangerous website:
<html>
<head>
<script type="text/javascript">
function steal()
{
iframe = document.frames["steal"];
iframe.document.Submit("transfer");
}
</script>
</head>
<body onload="steal()">
<iframe name="steal" display="none">
<form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php">
<input type="hidden" name="toBankId" value="11">
<input type="hidden" name="money" value="1000">
</form>
</iframe>
</body>
</html>
这三种方式都会造成CSRF攻击，使得银行用户自发转账，账号少了1000块钱。
第一，二种情况较为常见和容易发生，只需要用户进入危险网站发生图片加载，自动进入银行网站发生转账行为。
第三种情况利用hidden元素隐藏post请求，但是要使用JavaScript。
可以得出：CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！
二. CSRF防御
- anti-csrf-token方案
服务端在收到路由请求时，生成一个随机数，在渲染请求页面时把随机数埋入页面（一般埋入 form 表单内，<input type="hidden" name="_csrf_token" value="xxxx">）
服务端设置setCookie，把该随机数作为cookie或者session种入用户浏览器
当用户发送 GET 或者 POST 请求时带上_csrf_token参数（对于 Form 表单直接提交即可，因为会自动把当前表单内所有的 input 提交给后台，包括_csrf_token）
后台在接受到请求后解析请求的cookie获取_csrf_token的值，然后和用户请求提交的_csrf_token做个比较，如果相等表示请求是合法的。
这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。
注意：
Token 保存在 Session 中；
尽量少用 GET。
- Cookie-to-header令牌
在大多数操作中使用JavaScript的 Web应用程序可能使用依赖于同源策略的反CSRF技术：
-
在登录时，Web应用程序会设置一个包含随机标记的cookie，该标记在整个用户会话中保持不变
Set-Cookie：Csrf-token = i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; 到期=星期四，23-Jul-2015 10:25:33 GMT; 最大年龄= 31449600; 路径= /
-
在客户端操作的JavaScript读取它的值并将其复制到每个事务请求发送的自定义HTTP头中
X-Csrf-Token：i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
服务器验证令牌的存在和完整性
这种技术的安全性基于这样一种假设，即只有在相同来源内运行的JavaScript才能读取cookie的值。从恶意文件或电子邮件运行的JavaScript将无法读取并复制到自定义标题中。即使csrf-token cookie将自动与恶意请求一起发送，服务器仍将期待有效的X-Csrf-Token 标头。
CSRF令牌本身应该是唯一且不可预测的。它可以随机生成，也可以使用HMAC从会话令牌派生：
csrf_token = HMAC（session_token，application_secret）
CSRF标记Cookie不得有httpOnly标志，因为它旨在由JavaScript设计读取。
这项技术由许多现代框架实现，如Django和AngularJS。因为令牌在整个用户会话中保持不变，所以它在AJAX应用程序中运行良好，但不会在Web应用程序中强制执行事件序列。
- 客户端防御
诸如RequestPolicy（用于Mozilla Firefox）或uMatrix（用于Firefox和Google Chrome / Chromium）的浏览器扩展可以通过为跨站点请求提供默认拒绝策略来阻止CSRF。但是，这可能会显着干扰许多网站的正常运行。CsFire扩展（也适用于Firefox）可以通过从跨站点请求中删除身份验证信息来减轻CSRF的影响，同时减少对正常浏览的影响。
