CSRF(cross-site request forgery),中文名称:跨站请求伪造
,也被称为:one click attack/session riding
(很形象), 缩写为 CSRF/XSRF
;javascript
你能够这么理解CSRF
:攻击者盗用了你的身份,以你的名义发送恶意请求
。CSRF
可以作的事情包括:php
以你的名义发送邮件html
发消息java
盗取你的帐号浏览器
购买商品安全
虚拟货币转帐服务器
最后致使你的我的隐私泄露以及财产安全。cookie
从图中咱们能够看到,要完成一次CSRF
攻击,受害者必须一次完成两个步骤session
1.登录受信任网站A,并在本地生成cookie
2.在不退出A的状况下,访问了危险网站B
函数
到这里,你也许会说:若是我不知足以上条件的中的任何一个,就不会受到攻击
。是的,就是这样,可是你不能保证一下条件不会发生:
1.你不能保证你登录了一个网站后,再也不打开一个tab 页面并访问另外的网站。
2.你不能保证你关闭浏览器后,你本地的cookie 立刻过时,你上次的会话已经结束
3.上图中所谓的攻击网站,多是一个存在其余漏洞的可信任的常常被人访问的网站。
银行网站A,它以GET请求来完成银行转帐的操做,如:http://www.mybank.com/Transfe...
危险网站B,它里面有一段HTML的代码以下:
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
首先,你登陆了银行网站A,而后访问危险网站B,噢,这时你会发现你的银行帐户少了1000块。。。
为何会这样呢?
缘由是银行网站A违反了
HTTP
规范,使用GET
请求更新资源。在访问危险网站B的以前,你已经登陆了银行网站A,而B中的<img>以GET的方式请求第三方资源(这里的第三方就是指A网站了,本来这是一个合法的请求,但这里被不法分子利用了),因此你的浏览器会带上你的银行网站A的Cookie
发出GET
请求,去获取资源http://www.mybank.com/Transfer.php?toBankId=11&money=1000
,结果银行网站服务器收到请求后,认为这是一个更新资源操做(转帐操做),因此就马上进行转帐操做......
为了杜绝上面的问题,银行决定改用POST请求完成转帐操做。可是钓鱼网站也意识到银行应该不会那么傻逼,也与时俱进,钓鱼网站B的WEB表单以下:
<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>
若是用户还是继续上面的操做,很不幸,结果将会是再次不见1000块......由于这里危险网站B暗地里发送了POST请求到银行!
咱们看出来,CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然能够保证一个请求是来自于某个用户的浏览器,但却没法保证该请求是用户批准发送的!
分分钟钱就没了,是否是想死
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=”hash” value=”<?=$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.One-Time Tokens(不一样的表单包含一个不一样的伪随机值)
:>在实现One-Time Tokens时,须要注意一点:就是“并行会话的兼容”。若是用户在一个站点上同时打开了两个不一样的表单,CSRF保护措施不该该影响到他对任何表单的提交。考虑一下若是每次表单被装入时站点生成一个伪随机值来覆盖之前的伪随机值将会发生什么状况:用户只能成功地提交他最后打开的表单,由于全部其余的表单都含有非法的伪随机值。必须当心操做以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。
1.先是令牌生成函数(gen_token()):
<?php function gen_token() { //这里我是贪方便,实际上单使用Rand()得出的随机数做为令牌,也是不安全的。 $token = md5(uniqid(rand(), true)); return $token; }
2.而后是Session令牌生成函数(gen_stoken()):
<?php function gen_stoken() { $pToken = ""; if($_SESSION[STOKEN_NAME] == $pToken){ //没有值,赋新值 $_SESSION[STOKEN_NAME] = gen_token(); } else{ //继续使用旧的值 } } ?>
3.WEB表单生成隐藏输入域的函数
<?php function gen_input() { gen_stoken(); echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\” value=\”" . $_SESSION[STOKEN_NAME] . “\”> “; } ?>
4.WEB表单结构:
<?php session_start(); include(”functions.php”); ?> <form method=”POST” action=”transfer.php”> <input type=”text” name=”toBankId”> <input type=”text” name=”money”> <? gen_input(); ?> <input type=”submit” name=”submit” value=”Submit”> </FORM>
5.服务端核对令牌:
此处省略100字。。。。懒
就这么多,真特么麻烦,好累?