这是对自己最近一段时间主要在做的事的一点总结，内容主要为php类cms的审计，后文将大概描述
开始之前
- 首先需要一个好的工具，好的工具在分析函数调用情况方面的帮助非常大，我个人使用的是PhpStorm+MAMP Pro，前者jetbrains家，质量不用多说，后者配备了各种php的环境，方便测试不同php版本下相同函数的效果。
- 查阅相关cms的历史漏洞，历史漏洞能帮助我很快熟悉这个cms，尤其是可能上一个补丁打的并不完整，甚至可能发生绕过补丁，进行二次攻击的情况。而对于准备挖掘漏洞的人来说，查阅历史漏洞也能更好的规避撞洞这种情况的出现。
- 熟悉PHP的语言特性，比如弱类型，PHP审计的很多方面依托于PHP本身的弱类型特点，我之前便挖到过一个弱类型导致的任意用户登录，还有ctf考烂了的md5的0e绕过等等。
- 熟悉常见Web漏洞在PHP下的代码实现。最好是对于相应的漏洞，自己都能写出代码来模拟。
- 做好笔记，对于出现的一些自己觉得有问题的地方随时记录下来，一个是强化记忆，另一个是可能会出现需要组合利用的情况，再一个是防止因一时疏忽导致的失误。我个人习惯是，每个cms都有单独的一个文件去存放相关问题，比如危险函数的利用链、数据库有注入等风险的函数等等。
- 再做个小推荐————p师傅代码审计的圈子，质量很高（我真不是打广告的。
明确目标
根据自己能力，先确定好是要挖前台的洞还是后台的洞，或者说只是增加一下审计的经验，这样可以将自己一开始的着重点放在需要的地方。
前台就着重关注全局系列的东西，包括函数、类、逻辑等等。
后台就着重关注后台部分的东西，但是前台也要过一遍（万一灵感来了呢。
如果只是为了增加审计经验的话，可以着重关注历史漏洞，有时间精力的话，可以一一复现。
判断是否使用框架
第一步便是判断cms是厂商自己编写还是使用了框架的，这一步我一般是放在最开始的，根据结果的不同，审计的思路也会产生差异。
如果使用了框架，我一般会选择和框架源码进行比对来判断cms是否有修改源码，其次，除非是对用到的框架有了审计的想法，正常情况下我都会尽量绕开框架。
如果cms是厂商自行开发的，那么需要审计的工作量就比较大了，需要阅读的源码包括各种类和函数以及整个运行逻辑等等。
观察入口文件
现在cms一般分为单入口模式和多入口模式，通常情况下，以单入口模式居多。
单入口模式的入口文件一般放在最外层，命名一般为index.php，其中的内容一般以定义全局变量，引用文件为主。有些时候，因为cms使用了框架或者自己编写了路由的原因，访问文件的方式和直接访问会产生差异。
多入口模式则是比较熟悉的一个文件对应一块功能,当然，目前使用这种模式的cms也不多了。
在单入口模式下，先弄清楚路由，这一步非常关键，在后面的测试中，能非常迅速的定位函数位置。
其次，从入口文件找到包含的全局文件，常见的全局文件包括全局功能，全局变量，或者是一些类等等，比如某些cms会写一个形如global.func.php的文件，里面存放的是全局函数。
而全局函数通常可以分为以下几类：
- 参数过滤函数
- 文件操作函数
- 字符转换
- 异常处理函数
虽然上面将全局函数非常粗暴的分成了几类，但是在实际情况中，一般是存在交叉情况的，文件操作函数可能会涉及过滤，字符串转换等等。
尤其关注全局函数中涉及到数据库操作，文件操作，敏感函数操作的地方。
有些cms会直接从get或post方法中提取参数，然后再进行一次过滤，这种也是有风险的，我印象中metinfo便有因为过滤的变量不包括HTTP头所导致的安全问题，在这种情况下，同样也要注意变量覆盖的问题。
整理流程
这一块我最关注的是代码逻辑和运行流程的对应，并同时关注这个流程中不同步骤需要的权限和涉及到的函数的不同。
根据路由去理清代码逻辑，注意此时的权限变化，分清哪些功能模块是不登陆便可以接触的，哪些是登陆了就可以接触，而哪些是管理员才能接触的。
除了权限管理，在流程中涉及到的函数也是需要关注的，如果有耐心的话，可以挨个跟进去看，这一点可以往后放放，先理清楚流程，回过头来挖可能会更有效。
如果是一开始定的目标是挖掘后台的漏洞，只需要简单的梳理下前台的逻辑，便将主要精力投放在后台。
整理函数
这一块根据函数需要的权限分为两块：
- 前台函数
- 后台函数
对于如何挖掘这一块的洞，各人有各人的喜好，有的喜欢先定位危险函数，然后从定位的危险函数往外查找，最后一直跟到用户正常逻辑所能接触到的地方。有的人就喜欢（比如我）先看用户的逻辑，然后根据参数的传递去跟进函数，当然，在进行这一步前，都推荐先浏览一下全局函数。
用户函数模块通常都会涉及数据库操作，如用户登录注册，查询、更新个人信息等等。因此会可能涉及到SQL注入的漏洞，根据是否使用了现成的框架，挖掘思路也分成两种:
- 如果使用了框架，可以分辨一下框架名称以及版本，去搜索一下该版本的框架是否存在漏洞，如果存在再去cms中验证。因为本篇文章主要讲我自己在cms审计上的一些经验，因此不多深入框架的审计部分。
- 如果没有使用框架，则需要仔细的观察数据库函数，一般来说，cms是将select、insert等函数进行了封装的，比如$db->table(‘test’)->where(“name=admin”)便是 select * from test where name=admin这种格式，而此时若是发现cms使用的是过滤+拼接，那么很有可能会出现问题，而如果使用了PDO，则继续跟进涉及到table，order by等字段的拼接去，因为这些字段是无法使用PDO的。
关于第二点说的table字段这种安全问题，是真实存在的。我拿我之前挖的某个洞举个例子，目标cms是使用CI框架编写的，其中数据库函数有个函数count_all_results，传入的参数是表名，虽然也有过滤，但是是可以绕过的，因此便形成了注入，有关这个详情，我写在了这里：https://xz.aliyun.com/t/2050，这个洞后面有师傅给我提醒说可以用updatexml进行报错注入，我比较头铁直接拿dns通道打了…
说完了数据库，再一个是用户的个人信息修改部分，比如常见的上传图片、更改姓名等等。
用户信息的修改部分注意存储型xss的问题，主要是关注入库和出库过程的过滤问题。比如常见的标签是否过滤，标点符号实体编码等等。
上传图片注意后缀问题，常见的后缀问题比如黑名单绕过，还有比如finecms的base64写图片，然而后缀部分可控制，同样形成了getshell这种情况。
还有一些函数可能存在问题，但是只是阅读源码可能找不到入口点，这时候就能体现熟悉目标cms的路由的重要性，即使找不到正常的逻辑入口，也可以通过路由去访问。
前台便说到这里，说说后台.
后台一般作为管理员登陆的地方，所能接触到的功能相比于普通用户，要多出一大截，但是因为管理员本身便是高权限的代名词，因此挖掘难度比前台低了许多。
后台漏洞一般可以对着getshell或者注入找。
getshell有这么几个思路：
- 写入配置文件
- 未经过有效过滤，并且能接触到敏感函数
其中写入配置文件一般也是建立在写入的内容未经过过滤，或过滤不严格，可以被绕过。细说起来，可以分为直接写入配置文件和写入文本文件，而后include这两种，有关这两个方面，可以参考这几篇dede后台的getshell:
未经过有效过滤通常来说是直接在cms中执行命令函数，有的cms本身带有文件管理的功能，可能会有人觉得无需再去想办法getshell，但是如果用户将相关功能删除，那么想办法执行命令便是必须的了。同样给个例子：
再说到注入，一般来说，常见的where后面的条件字段是不太好注入的，这一部分的过滤通常来说，是比较完善的，但是也像我前面所说的order by这一类的语句用来注入是很好的，并且我观察我最近挖的后台的注入，order by语句所占的比例非常的高。
（通常来说，这种洞只要挖到一个，不出意外都会有第二个，我猜测是写这一块的是同一个人或者按照类似的要求来写的，因此会呈现一定的重复性）
整理类
这一部分主要是理清楚代码中有哪些类，一般来说，类文件会单独由文件夹进行存放，内容涉及广泛，比如文件上传类、用户类、数据库操作类等等。
如果准备挖掘反序列化漏洞，因为需要触发一些敏感函数去完成操作，因此需要对这一块进行深入的梳理，正常情况下，遇到了再跟进去看就足够了。
CTF与审计
平常接触过很多实战审计和CTF审计关系不大的言论，我觉得这是不对的。在CTF情景下的审计中的许多tricks可以直接照搬到实战审计中，如果不知道这些tricks，即使在实战审计中，遇到了同样的点，多数情况下也会直接绕过去，因此我才认为，一道合格的CTF题目和实战不是分割的。