YII2框架学习 安全篇（三） csrf攻击和防范
2017-06-20 21:03
288 查看
继续讲web安全，这次讲到的是csrf攻击（跨站请求伪造）。看到一篇博客这么介绍csrf：你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。
发个例子说明一下，例子转载自http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html，他写得很全面了。
示例1：
银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危险网站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的Cookie发出Get请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......
示例2：
为了杜绝上面的问题，银行决定改用POST请求完成转账操作。
银行网站A的WEB表单如下：
<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']);
}
?>
危险网站B，仍然只是包含那句HTML代码：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。
示例3：
经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：
<?php
session_start();
if (isset($_POST['toBankId'] && isset($_POST['money']))
{
buy_stocks($_POST['toBankId'], $_POST['money']);
}
?>
然而，危险网站B与时俱进，它改了一下代码：
<html>
<head>
<script type="text/javascript">
function steal()
{
iframe = document.frames["steal"];//伪造form表单
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请求到银行!
总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个<img>就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。
理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！
看到这，我感觉我之前用的自己公司框架写的web好像在某些情况下分分钟就被攻陷了。赶紧看看防范压压惊。主要有三种方式
一，可以通过验证码的方式，不过每次都要写，很麻烦。二，通过referer头来判断指令的来源，但是有的时候请求不会带上referer头。三，传输过程增加防伪码，相对比较有效。
下面来看看YII框架到底是如何防范csrf攻击的。
浏览器登陆时，通过 \YII::$app->request->csrfToken 生成_csrf，给到浏览器。浏览器再次提交表单的时候带上_csrf。服务器进行校验。但是，访问量很大的时候，产生的_csrf可能很多，存session里面可能不太好。这个时候的处理方式是，在给到浏览器_csrf时，加密一份给到表单里面的隐藏元素，然后给一份给cookie，提交的时候解密验证一下就行了。
发个例子说明一下，例子转载自http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html，他写得很全面了。
示例1：
银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危险网站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的Cookie发出Get请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......
示例2：
为了杜绝上面的问题，银行决定改用POST请求完成转账操作。
银行网站A的WEB表单如下：
<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']);
}
?>
危险网站B，仍然只是包含那句HTML代码：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。
示例3：
经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：
<?php
session_start();
if (isset($_POST['toBankId'] && isset($_POST['money']))
{
buy_stocks($_POST['toBankId'], $_POST['money']);
}
?>
然而，危险网站B与时俱进，它改了一下代码：
<html>
<head>
<script type="text/javascript">
function steal()
{
iframe = document.frames["steal"];//伪造form表单
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请求到银行!
总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个<img>就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。
理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！
看到这，我感觉我之前用的自己公司框架写的web好像在某些情况下分分钟就被攻陷了。赶紧看看防范压压惊。主要有三种方式
一，可以通过验证码的方式，不过每次都要写，很麻烦。二，通过referer头来判断指令的来源，但是有的时候请求不会带上referer头。三，传输过程增加防伪码，相对比较有效。
下面来看看YII框架到底是如何防范csrf攻击的。
浏览器登陆时，通过 \YII::$app->request->csrfToken 生成_csrf，给到浏览器。浏览器再次提交表单的时候带上_csrf。服务器进行校验。但是，访问量很大的时候，产生的_csrf可能很多，存session里面可能不太好。这个时候的处理方式是，在给到浏览器_csrf时，加密一份给到表单里面的隐藏元素，然后给一份给cookie，提交的时候解密验证一下就行了。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- YII2框架学习 安全篇（四） sql注入攻击和防范
- YII2框架学习 安全篇（二） XSS攻击和防范（下）
- php web开发安全之csrf攻击的简单演示和防范（一）
- 【安全牛学习笔记】存储型XSS和BEEF浏览器攻击框架
- 来了解并防范一下CSRF攻击提高网站安全
- yii2框架-yii2的防御csrf攻击机制(十六)
- YII2框架学习 安全篇（五） 文件上传漏洞
- 【安全牛学习笔记】CSRF跨站请求伪造攻击漏洞的原理及解决办法
- ci框架如何手动进行csrf攻击防范
- web安全之跨站请求伪造攻击(CSRF)与防范方法
- 交换网络安全防范系列三之ARP欺骗攻击防范
- 【转】建立全局的安全体系 防范“拒绝服务(DoS)”攻击
- 安全札记之SYN 攻击原理及防范技术
- IIS服务器防范攻击安全设置技巧
- 防范混合攻击 把网络作为安全第一道防线
- IIS 服务器 防范攻击3条安全设置技巧
- 安全框架Apache Shiro学习心得
- 网络安全：攻防技术 ——网页脚本攻击防范全攻略
- 基于Cookie的攻击和防范学习总结
- Cisco 安全技术系列之一：2层攻击防范技术