知识点：
1.多窗口浏览器（firefox、chrome）便捷的同时也带来了一些问题，因为多窗口浏览器新开的窗口是具有当前所有会话的。
即我用IE登陆了我的Blog，然后我想看新闻了，又运行一个IE进程，这个时候两个IE窗口的会话是彼此独立的，从看新闻的IE发送请求到Blog不会有我登录的cookie；但是多窗口浏览器永远都只有一个进程，各窗口的会话是通用的，即看新闻的窗口发请求到Blog是会带上我在blog登录的cookie。
2.Get请求伪造
博客删除一般是采用get请求，后面加上文章id号，所以如果我们能构造一个连接带有删除的请求和id，同时用户已经在浏览器上登陆了博客，那么会利用自带cookie来实现跨站请求的伪装。
例如某篇文章的操作链接如下：
post.php?post=1391&action=trash&_wpnonce=2cf4aa198b //移至回收站 post.php?post=1391&action=untrash&_wpnonce=b783a7a116 //还原 post.php?post=1391&action=delete&_wpnonce=2f51a98293 //永久删除
注意到末尾的’_wpnonce=2cf4aa198b’的随机字符，这其实是程序已经做了防CSRF
CSRF攻击依赖下面的假定：
攻击者了解受害者所在的站点
攻击者的目标站点具有持久化授权cookie或者受害者具有当前会话cookie
目标站点没有对用户在网站行为的第二授权
CSRF的防御:
CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。
服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。
(1).Cookie Hashing(所有表单都包含同一个伪随机值)：
这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了:>
<?php //构造加密的Cookie信息 $value = “DefenseSCRF”; setcookie(”cookie”, $value, time()+3600); ?>
在表单里增加Hash值，以认证这确实是用户发送的请求。
<?php $hash = md5($_COOKIE['cookie']);?> <form method=”POST” action=”transfer.php”> <input type=”text” name=”toBankId”> <input type=”text” name=”money”> <input type=”hidden” name=”check” value=”<?php echo $hash;?>”> <input type=”submit” name=”submit” value=”Submit”> </form>
然后在服务器端进行Hash值验证
<?php
if(isset($_POST['check'])) {
$hash = md5($_COOKIE['cookie']);
if($_POST['check'] == $hash) {
doJob();
} else {
//...
}
} else {
//...
}
?>
这个方法个人觉得已经可以杜绝99%的CSRF攻击了，那还有1%呢….由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。
(2).验证码
这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，厄….这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。
(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)
在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。
