战略性的考虑而非战术

关于面向进程写法的程序来说，最快的审计办法或许时直接丢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()办法(假如你榜首反响是认为iCMS.php是个类文件，那你后边的审计估量有点难过。)

跟进iCMS.php

该处载入了装备跟结构文件，持续跟进iPHP.php

载入几个结构文件，然后调用iPHP::bootstrap()办法，这回差不多了，持续跟进iPHP::bootstrap()

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

看到48行的spl_autoload_register函数了没，再详细点，看到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，这个缝隙还有两处有点蛋疼的当地，榜首，username跟nickname每次都要改动，并且这些值都是会存进数据库的；第二，这儿的ssrf是没有回显。

运用dict来举个比方，拜访一个未敞开端口时如下

拜访一个敞开的端口时如下
假如上述说的都做完还没发现缝隙，那能够测验丢到seay源代码审计体系，或许依据功用点进行审计，找找逻辑缝隙
假如做完上述操作后再用软件来辅佐，会轻松的多，比方，seay源代码审计体系扫出来如下
拿第二条间隔，缝隙描述是referer假造会引起sql，点击瞅瞅
看到referer先进入了iSecurity::escapeStr，然后再进入iDB::insert，经过前面的审计我知道iSecurity::escapeStr对单引号等做了过滤，所以一般的sql注入是没期望了，只能看看还有没有其他 *** 能结合运用（我记住这是有注入的……）
假如我是一上来就用软件的话，那我现在或许还在一步一步的追一个函数，这样会添加不少功夫
本文到这就完毕了，emmm！