你好,游客 登录
背景:
阅读新闻

浅谈开源web程序后台的安全性

[日期:2014-03-11] 来源:51CTO  作者: [字体: ]

  一、前言

  不知怎的最近甚是思念校园生活,思念食堂的炒饭。那时会去各种安全bbs上刷刷帖子,喜欢看别人写的一些关于安全技巧或经验的总结;那时BBS上很多文章标题都是:成功渗透XXX,成功拿下XXX。这里便以一篇入侵菲律宾某大学的文章引出文章的主题,我们先简要看一下过程。大学网站使用了名为joomla的开源web程序,(1)青年使用一个joomla已经公开的漏洞进入web后台(2)青年使用joomla后台上传限制不严的缺陷上传了一个webshell(3)控制主机赠送我国国旗。

  原来入侵一台主机如此容易,管理员果断给web程序打上安全补丁。管理员的工作是结束了,作为安全从业人员再一想是不是joomla后台这里可以上传webshell是不是有问题呢,如果joomla后台不能上传webshell,是不是可以减少入侵的可能和损失。下面进入本文的主题:web后台程序的安全性。

  二、简介

  国内很多站点都是基于开源论坛、cms搭建的,比如discuz、phpwind、dedecms等。这些程序都是国内开源web程序中的佼佼者,也比较注重安全性。平时大家关注比较多的是sql注入、xss这些可以直接窃取用户数据的漏洞。网上因为弱口令被入侵的案例数不胜数,此外用户数据泄漏事件时而发生,单纯靠密码防护的后台被突破,被社工的可能性越来越大。获取一个管理后台密码后,再结合后台程序的任意代码执行、文件包含或命令注入等漏洞得到一个shell,窃取用户资料不是什么难事。此时后台程序的安全性成为一个短板。

  Discuz是一款流行的论坛程序,笔者这里就以它的后台程序为例简单分析一下其安全性,下面直接看一些漏洞案例(Discuz最新版本已打补丁,请用户及时升级到最新版-Discuz! X3.1 R20140101)。

  三、案例分析

  Tips:下文提到的$settingnew是discuz后台存储表单数据的变量,后台用户可控。

  案例一:用户输入数据过滤逻辑不当

  漏洞文件:X3\source\admincp\admincp_setting.php

  分析:

  案例二:二次注入

  简单介绍一下二次注入,恶意用户alice在A处传入恶意数据并被存储到数据库,在A处不直接导致安全问题;B处引用到A处存储的数据,从而触发安全问题。

  漏洞文件:X3\source\admincp\admincp_setting.php

  分析:

  案例三:程序升级新增逻辑导致的漏洞

  漏洞文件:X3\source\admincp\admincp_adv.php

  案例四:漏洞修补不完善

  漏洞文件:X3\api\uc.php

  分析:

  这个问题早在2010年外部已经公开,官方已及时发出补丁

  详情请参考:http://www.oldjun.com/blog/index.php/archives/76/

  四、总结

  上面这些例子主要是笔者实践经验的一些总结,不一定全面,希望能给大家拓展一些思路;比如上述提到的二次注入,$settingnew['seccodedata']['type']这个变量没过滤,$settingnew的其他数组也可能没过滤,也确实存在多处类似的问题,大家可以自行去尝试一下。关于代码审计的方法主要有两个大方向:(1)危险函数向上追踪输入;(2)追踪用户输入是否进入危险函数;这里的危险函数关于危险函数主要包括代码执行相关:eval、assert,文件包含:include、require等,命令执行:system、exec等,写文件:fwrite、file_put_contents等;

  代码审计的方法这里推荐两篇文章:

  https://code.google.com/p/pasc2at/wiki/SimplifiedChinese

  http://wenku.baidu.com/view/c85be95a3b3567ec102d8a12.html

  五、反思

  1、一切输入都是有害的;

  后台程序的用户输入相比前台主要增加了后台表单的数据,此外有些后台支持上传文件(如dz1.5的自定义sql),上传文件的内容也属于输入;这些输入都属于用户范围。一定要做严格的控制和过滤。

  2、安全意识;

  其实很多漏洞的产生并不是技术问题导致的,而是我们缺乏安全意识,不重视安全而酿成的惨剧。尤其是第三个和第四个,完全不应该发生;需要对开发人员做安全宣导和基本的安全培训。

  3、漏洞Review;

  (1)开发人员收到漏洞后要对漏洞产生的原因做总结,并Review代码中是否有类似的问题。有些时候开发人员仅仅是修补了安全人员或白帽子提供的漏洞点,另外一处代码有类似的问题没修补继续爆出漏洞,无穷无尽。这样做还会带来更大的隐患,黑客是非常乐意并擅长总结反思的,每一个补丁其实也是给黑客拓展了思路,如果修补不完全后果很严重。

  (2)开发人员修补完成后安全人员需要进行测试确认,上述的案例四就是鲜明的例子。有条件的情况下安全人员应该整理一些常见漏洞修复指引,这样也可以提高工作效率。





收藏 推荐 打印 | 录入: | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款