PHP代码审计实战思路浅析

qzmjef

战略性的思考而非战术

针对面向过程写法的程序来讲，最快的审计办法可能时直接丢seay审计系统里，但针对基于mvc模式的程序来讲，你直接丢seay审计系统的话，那不是给自己找麻烦吗？

像面向过程写法的程序，能够找下它的公共函数文件有啥能够利用的不，而后便是丢seay审计系统。

而针对基于mvc写法的程序来讲，跟读他的入口文件，认识全部程序的运行流程跟目录结构，之后再深入去认识它的核心类库，倘若核心类库存在漏洞的话，那在这套程序中找出个漏洞的期盼那不是通常的大啊！认识了全部框架运行流程后，亦没从核心类库中发掘什么可利用的点的话，此时就能够从功能点入手了(此时能够把源码丢进seay源代码审计系统了)。

一套组合拳打下了后还是没找到漏洞咋办？没事，换套程序继续。倘若换了n套程序都找不出来，那就换个人吧……

实战环节

目的：某开源cms(icms) 环境：win+phpstudy+sublime

大概目录结构长这般

├── app       应用 ├── cache     缓存 ├── core      icms程序入口 ├── iPHP      iphp框架文件 ├── public    公共资源 ├── res       用户资源 └── template  模板

打开index.php

发掘载入了一个icms.php，而后调用了iCMS::run()办法(倘若你第1反应是以为iCMS.php是个类文件，那你后面的审计估计有点难受。)

跟进iCMS.php

该处载入了配置跟框架文件，继续跟进iPHP.php

载入几个框架文件，而后调用iPHP::bootstrap()办法，这回差不多了，继续跟进iPHP::bootstrap()

该处做了些环境配置，而后便是调用核心的iWAF、iSecurity类来一下全局过滤(iWAF这些先跟)，看到这可有有的小伙伴又有疑惑了，iWAF什么时候加载进来了啊？

看到48行的splautoloadregister函数了没，再详细点，看到56行那个autoload了没

这亦没看到哪有include、require之类的啊，怎么加载进来的？别急，继续跟进57行的self::auto_require

没错便是这了，不外代码太长了就不贴了，大概便是判断传来的类名中是不是有Admincp或App，倘若无就加载app/xx/xx.class.php，倘若有Admincp则加载app/xx/xx.Admincp.php，倘若有App则加载app/xx/xx.app.php，倘若有Func则加载app/xx/xx.func.php，倘若以上都不满足则去iPHP/core/下找

iPHP::bootstrap()大概晓得它干了什么了，再回头去瞧瞧iCMS::init()

大概便是初始化配置信息，继续往回看，跟进iCMS::run()

继续跟进iPHP::run

(代码有点长)大概便是从post或get获取应用名，加载类跟实例化类，调用办法等

划重点了(后面会用到)，这儿的文件名格式是xx.app.php，类名是xxApp，其实整套程序并不止index.php这一个入口文件，还有admincp.php、user.php等，其中加载的文件名格式跟类名都是不同样的，例如：拜访index.php加载的是xx.app.php的xxApp类，拜访admincp.php加载的xx.admincp.php的xxAdmincp类

跟完入口文件后，对全部框架是怎么运行的，都有了个大概的认识，接下来能够去深入认识了

我跟啊跟，发掘核心类中的iHttp类的remote办法有点意思，在iPHP/core/iHttp.class.php 130行

remote办法封装了curl，用来获取远程页面内容，全部办法并无对url进行任何限制或过滤，倘若调用这个办法前亦没用对url进行限制的话，那ssrf就跑不了了

全局搜索下看哪调用了这个办法，而remote是个静态办法，调用格式为iHttp::remote，因此直接搜这个就能够了

我想找前台的漏洞，so，直接看哪个的文件名格式类似xx.app.php就好啦

找啊找，仅发掘前台仅有一处调用了该办法

找到之后，跟进去瞧瞧

把$avatar传了进去，继续往上翻翻，看有无啥过滤

始终往上翻，只看到这句

会不会在iSecurity::escapeStr这做了限制呢？继续跟进去瞧瞧

貌似无对url做限制！！！

再往上翻翻，瞧瞧是哪个办法

这回稳了，手动构造数据包

解释下个字段：

secode为验证码，可从http://127.0.0.1/icms/public/api.php?app=public&do=seccode得到，验证码信息存在cookie里，只要cookie不变，验证码就可始终用。

username跟nickname每次请求都要改变，avatar为传入的url，这个漏洞还有两处有点蛋疼的地区，第1，username跟nickname每次都要改变，况且这些值都是会存进数据库的；第二，这儿的ssrf是没有回显。

运用dict来举个例子，拜访一个未开启端口时如下

拜访一个开启的端口时如下

倘若以上说的都做完还没发掘漏洞，那能够尝试丢到seay源代码审计系统，或按照功能点进行审计，找找规律漏洞

倘若做完以上操作后再用软件来辅助，会容易的多，例如，seay源代码审计系统扫出来如下

拿第二条距离，漏洞描述是referer伪造会导致sql，点击瞅瞅

看到referer先进入了iSecurity::escapeStr，而后再进入iDB::insert，经过前面的审计我晓得iSecurity::escapeStr对单引号等做了过滤，因此普通的sql注入是没期盼了，只能瞧瞧还有无其他方式能结合利用（我记得这是有注入的……）

倘若我是一上来就用软件的话，那我此刻可能还在循序渐进的追一个函数，这般会增多不少功夫

本文到这就结束了，emmm！

*本文原创作者：wnltc0，本文属FreeBuf原创奖励计划，未经许可禁止转载

1fy07h

认真阅读了楼主的帖子，非常有益。

nykek5i

楼主发的这篇帖子，我觉得非常有道理。