前端能力模型CSRF漏洞

CSRF&＃xff08;Cross-Site Request Forgery&＃xff09;&＃xff1a;中文名称&＃xff1a;跨站请求伪造&＃xff0c;也被称为&＃xff1a;one click attack/ session riding&＃xff0c;缩写为CSRF/XSRF。

XSS是实现CSRF的诸多途径中的一条&＃xff0c;但绝对不是唯一的一条。一般习惯上把通过XSS来实现的CSRF称为XSRF。

CSRF是伪造请求&＃xff0c;&＃xff0c;冒充用户在站点正常操作。我们知道&＃xff0c;绝大多数网站是通过COOKIE等方式辨识用户身份&＃xff08;包括使用服务器端Session的网站&＃xff0c;因为Session ID也是大多保存在COOKIE里面的&＃xff09;&＃xff0c;再予以授权的。所以要伪造用户的正常操作&＃xff0c;最好的方法是通过XSS活链接欺骗等途径&＃xff0c;让用户在本机&＃xff08;即拥有身份COOKIE的浏览器端&＃xff09;发起用户所不知道的请求。

要完成一次CSRF攻击&＃xff0c;受害者必须依次完成两个步骤&＃xff1a;

1、登录受信任网站A&＃xff0c;并在本地生成COOKIE。

2、在不登出A的情况下&＃xff0c;访问危险网站B。

可以这么理解CSRF攻击&＃xff1a;攻击者盗用了你的身份&＃xff0c;以你的名义发送恶意请求。CSRF能够做的事情包括&＃xff1a;以你的名义发送恶意请求。

不能保证如下情况不会发生&＃xff1a;

1、登录一个网站&＃xff0c;不再打开新的一个tab页面访问另外网站&＃xff1b;

2、不能保证关闭浏览器&＃xff0c;本地的COOKIE就立刻过期&＃xff1b;

3、攻击的网站&＃xff0c;可能是一个存在漏洞的可信任的经常被人访问的网站。

示例流程图&＃xff1a;

示例1&＃xff1a;

银行网站A&＃xff0c;它以GET请求来完成银行转账的操作&＃xff0c;如&＃xff1a;

http://www.mybank.com/Transfer.php?toBankId&＃61;11&money&＃61;1000

危险网站B&＃xff0c;它里面有一段html代码如下&＃xff1a;

登录网站A&＃xff0c;未退出&＃xff0c;然后访问网站B&＃xff0c;银行帐号少了钞票

原因&＃xff1a;银行网站A违反http规范&＃xff0c;使用GET请求更新资源。在访问危险网站B之前&＃xff0c;你已经登录银行网站A&＃xff0c;而B中的以GET方式请求第三方资源&＃xff08;这里第三方是指银行网站&＃xff0c;被不法分子利用了&＃xff09;&＃xff0c;所以你的浏览器会带上你的银行网站A的COOKIE发出get请求&＃xff0c;去获取资源"http://www.mybank.com/Transfer.php?toBankId&＃61;11&money&＃61;1000"&＃xff0c;结果银行网站服务器收到请求后&＃xff0c;认为这是一个更新资源操作&＃xff08;转账操作&＃xff09;&＃xff0c;所以就立刻进行转账操作

第二次改进版&＃xff1a;

为了杜绝上面的问题&＃xff0c;银行决定改用POST请求完成转账操作。

银行网站A的WEB表单如下&＃xff1a;

ToBankId:

     

Money:

后台处理页面Transfer.php如下&＃xff1a;

seesion_start();

if (isset($_REQUEST[&＃39;toBankId&＃39;]) && isset($_REQUEST[&＃39;money&＃39;])) {
          buy_stocks($_REQUEST[&＃39;toBankId&＃39;], $_REQUEST[&＃39;money&＃39;]);
     }

?>

危险网站B&＃xff0c;仍然只是包含那句话html代码

执行一次&＃xff0c;再次没了xx块人民币&＃xff0c;原因是$_REQUEST既能获取post请求数据&＃xff0c;也能获取get请求数据&＃xff0c;java获取请求数据request一样存在不能区分get和post数据问题。

第三次优化版&＃xff1a;

经过前面惨痛的教训&＃xff0c;银行决定把获取请求数据的方法改了&＃xff0c;改用$_POST&＃xff0c;只获取post请求数据&＃xff0c;后台处理页面Transfer.php代码如下&＃xff1a;

session_start();

if (isset($_POST[&＃39;toBankId&＃39;]) && isset($_POST[&＃39;money&＃39;])) {
          buy_stocks($_POST[&＃39;toBankId&＃39;], $_POST[&＃39;money&＃39;]);
     }

?>

危险网站B与时俱进&＃xff0c;将img换成post方法

用户继续操作危险网站B&＃xff0c;再一次不见xx块。

理解上面3种攻击模式&＃xff0c;其实可以看出&＃xff0c;CSRF攻击是源于WEB的隐式身份验证机制&＃xff0c;WEB的身份验证机制虽然可以保证一个请求是来自于某个用户浏览器&＃xff0c;但却无法保证该请求是用户批准发送的。

CSRF防御可以从服务端和客户端两方面着手&＃xff0c;防御效果是从服务端着手效果比较好。

服务端的CSRF就是在客户端页面增加伪随机数。

a) COOKIE Hashing&＃xff08;所有表单都包含同一个伪随机值&＃xff09;&＃xff1a;

// 构造加密的COOKIE信息

$value &＃61; "DefenseSCRF";

setCOOKIE("COOKIE", $value, time()&＃43;3600);

?>

在表单里增加hash值&＃xff0c;以认证这确实是用户发送的请求

$hash &＃61; md5($_COOKIE[&＃39;COOKIE&＃39;]);

?>

" />

然后在服务器端进行Hash值验证

if (isset($_POST[&＃39;check&＃39;])) {

$hash &＃61; md5($_COOKIE[&＃39;COOKIE&＃39;]);

if ($_POST[&＃39;check&＃39;] &＃61;&＃61; $hash) {

doJob();

} else {

//...

}

} else {

// ...

}

?>

这个方法基本可以杜绝大部分csrf攻击&＃xff0c;少量由于用户的COOKIE很容易由于网站XSS漏洞而被盗取。一般攻击者看到有需要算Hash值&＃xff0c;基本都放弃

这个方案的思路是&＃xff1a;每次的用户提交都需要用户在表单中填写一个图片上的随机字符串&＃xff0c;这个方案貌似可以完全解决CSRF。易用性稍微差一些

在实现One-Time Tokens时&＃xff0c;需要注意一点&＃xff1a;就是“并行会话的兼容”。如果用户在一个站点同时打开两个不同的表单&＃xff0c;CSRF保护措施不应该影响它对任何表单的提交。

function gen_token() {

$token &＃61; md5(uniqid(rand(), true));

return $token;
     }

?>

function gen_stoken() {

$pToken &＃61; "";

if ($_SESSION[STOKEN_NAME] &＃61;&＃61; $pToken) {

// 没有值&＃xff0c;赋新值

$_SESSION[STOKEN_NAME] &＃61; gen_token();

} else {

// 继续使用旧的值

}

}

?>

function gen_input() {

gen_stoken();

echo " ";

}

?>

session_start();

include("functions.php");

?>

gen_stoken();

if ($_POST[&＃39;FTOKEN_NAME&＃39;] &＃61;&＃61; $_SESSION[STOKEN_NAME]) {

doJob();

} else {

//...

}

?>

转载地址&＃xff1a;http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html