代码审计思路之PHP代码审计

f9yx0du

00×0 前言

近期亦是边挖src边审计代码，总结下近期的php代码审计的有些思路，我通常根据次序往下做，限于能力水平，可能会有不对或欠缺的地区，期盼各位师傅能够指点。

00×1 前期工作,需要的工具（我运用的)

PHPStorm|是PHP编程语言研发的集成环境。

Fotify|代码审计静态扫描工具，商场化静态代码扫描工具，误报率相对较低。

seay|源代码审计工具

CodeQl | 有效的QL非商场的开源代码自动化审计工具。

xcheck| Xcheck 是一款静态应用安全测试工具，旨在即时发掘业务代码中的安全危害，尤其是由于不受信输入所触发的安全漏洞。检测范围覆盖主流 Web 安全漏洞，具备速度快、误报低和准确率高等优点。

chrome & HackerBar插件

00×3 知道目的

在审计之前，咱们首要先确定自己此次审计的目地，我觉得会有三种状况

为了提高自己的审计经验项目中为了审计出能进一步利用的漏洞，通常需要getshell、ssrf这种级别的。为了挖点洞，去换钱或换cve&cnvd。

有什么区别呢？

为了提高审计经验，我会去重点关注历史漏洞，并去复现。

倘若是为了能审出漏洞，去用作渗透中的进一步利用，那样我觉得，能够重点运用xcheck、Fotify等自动化代码审计，而后关注下面的文件上传、包括、sql注入等等有严重害处的漏洞

倘若是为了挖0day，搞证书什么的，那样全方位按过程过一遍，是不错的选择。

【一>所有资源关注我，私信回复“资料”获取<一】

1、200份非常多已然买不到的绝版电子书

2、30G安全大厂内部的视频资料

3、100份src文档

4、平常安全面试题

5、ctf大赛经典题目解析

6、全套工具包

7、应急响应笔记

8、网络安全学习路线

00×4 判断是不是是用了框架

判断是不是运用了框架，是蛮重要的，能帮忙咱们快速定位有用的函数集，筛选不需要去看的代码。

通常来讲，我觉得运用了框架的更好审计一点，由于运用了框架的，他的函数集文件（各样办法function）会比较规整，在某些固定文件夹中，清晰可见，当然需要咱们先对框架有所认识。

日前比较主流的设计模式是MVC，即多层模型（M）、视图（V）、掌控器（C），这里不多赘述，php的主流框架几乎都运用了MVC设计模式。

PHP底下的研发框架日前见的比较多的有Laravel，ThinkPHP，yii等。

4.1. ThinkPHP框架

ThinkPHP这儿需要区分TP3和TP5的差别，首要咱们先来瞧瞧TP3的目录结构。（此刻基于TP3的系统都很少了。。。认识一下就好

其中，Application和Public目录下面都是空的。

Application是存放项目中的重要的有些函数集，Public是公共文件夹，供用户拜访的，重要的函数集千万不可放这里文件夹下。

Application目录默认是空的，然则第1次拜访入口文件会自动生成，参考后面的入口文件部分。其中框架目录ThinkPHP的结构如下：

另一TP5和TP3实质上差距有点大，先瞧瞧TP5下载下来的默认文件结构。其中在public文件下有个route.php文件，它的功效是用于php自带webserver支持，可用于快速测试，起步命令：php -S localhost:8888 router.php。而它的关联网站功能目录亦需要从根目录下的index.php入手。

以下为TP5的目录结构。

通常倘若是审计基于框架的cms，我不会去看框架系统目录，便是上面的ThinkPHP文件夹下的东西，第三方类库vendor亦不会去先看，除非是在审计过程中流向了这些文件中，才会大概看一看，而重点在Application文件夹下做文案。

既然是MVC框架的，那样咱们真正关心的是其中的掌控器（C），由于功能点大部分都在C上，咱们能找到的大部分漏洞亦都在C上

下图为基于TP6的ThinkAdmin项目目录

app（亦便是application），下面有admin、data、index、wechat几个文件夹，每一个文件夹表率了一个应用，例如admin通常来讲都是后台的服务，wechat为微X应用服务，每一个应用下面都有Controller（掌控器）、Module（模型）、View（视图，通常是html文件）

此刻目录很知道，目的就很知道，拿到这般基于框架的cms，就应该晓得，该重点审计的地区在哪里。

4.2. Laravel框架

目录怎么变，MVC架构的重点还是在Controllers里

4.3. 倘若没用框架

没用框架的话，先搞明白目录结构，通常来讲

审计过程中需要关注几个点：（在咱们后面起始审计的过程中，自己要重视这些地区，经常想一想）

1）函数集文件，一般命名包括function或common等关键字，这些文件里面是有些公共的函数，供给其他文件统一调用，因此大都数文件都会在文件头部包括到其他文件。寻找这些文件一个非常好用的技巧便是去打开index.php或有些功能性文件，在头部通常都能找到。

2）配置文件，一般命名中包含config关键字，配置文件包含web程序运行必须的功能性配置选项以及数据库等配置信息。从这个文件中能够认识程序的小部分功能，另一看这个文件的时候重视观察配置文件中参数值是单引号还是用双引号括起来，倘若是双引号可能就存在代码执行的问题了。

3）安全过滤文件，安全过滤文件对代码审计至关重要，这关系到咱们挖掘到的能够点能否直接利用，一般命名中带有filter、safe、check等关键字，这类文件重点是对参数进行过滤，大都数的应用其实会在参数的输入做一下addslashes()函数的过滤。

4）index文件，index是一个程序的入口，因此一般咱们只要读一读index文件就能够大致认识全部程序的架构、运行的流程、包括到的文件，其中核心的文件有那些。而区别目录的index文件亦有区别的实现方式，意见最好将几个核心目录的index文件都通读一遍。

00×5 认识路由

我很爱好Thinkphp这类框架的原由是，她们的路由很好摸清，倘若在哪个办法中找到了漏洞，我就能直接按照路由拜访这个办法，直接利用。

认识路由亦是为了能快速定位漏洞位置，要否则，你经过审计源码找到的漏洞，却不晓得在浏览器中用什么样的url去拜访，这不是件很尴尬的事儿吗？

例如Thinkphp的路由有三种方式

5.1. 普通模式

关闭路由，完全运用默认的pathinfo方式URL：

‘url_route_on’ => false,

路由关闭后，不会解析任何路由规则，采用默认的PATH_INFO 模式拜访URL：

module/controller/action/param/value/…

module便是运用的应用。

controller是掌控器，跟文件名一致。

action是办法，某掌控器下的办法。

param是需要的变量

value是参数

但仍然能够经过Action参数绑定、空掌控器和空操作等特性实现URL位置的简化

5.2. 混合模式

开启路由，并使用路由+默认PATH_INFO方式的混合：

‘url_route_on’ => true,

该方式下面，只需要对需要定义路由规则的拜访位置定义路由规则，其它的仍然根据默认的PATH_INFO模式拜访URL。

5.3. 强制模式

开启路由，并设置必须定义路由才可拜访：

‘url_route_on’ => true, ‘url_route_must’=> true,

这种方式下面必须严格给每一个拜访位置定义路由规则，否则将抛出反常。

首页的路由规则是 /。

其实，在实质审计过程中，我通常会先去黑盒拜访一遍功能点，分析后差不多亦能晓得路由怎么样形成，倘若有的地区不清楚，能够去源码中找路由文件

通常带有route关键词的文件，或文件夹与路由相关。

分析好路径，之后就能够真正的起始审计。

00×6 审计

在人工审计之前，能够运用我之前说到的xcheck、Fotify、codeql等自动化审计工具先审计一遍，按照报告，验证一遍，再往下去按照下面的过程审一遍，一个项目，亦就能审个七七八八了，深层次的利用亦就得看自己的实力与经验了。

倘若运用了框架，能够先瞧瞧此项目还有无框架的漏洞存在，我就再也不赘述了。

6.1. 鉴权

首要针对项目整体的一个权限认证做一个判断，判断是不是存在越权，未授权拜访的状况。

通常来讲，需要权限认证的地区，是后台管理，即admin应用下的。

因此针对admin下的掌控器这些办法，需要判断是不是能够未授权拜访。

日前针对全部后台管理鉴权的方式，通常是采用写一个基类，例如Base.php或common.php，其中存在鉴权办法，而后在每一个掌控器类继承这个类。

例如xiaohuanxiong漫画cms的后台，便是采用了这种办法。

不外我亦看到了，有的比较好的项目，自己二开框架，做了自己的组件，而后，每一个类都继承了此组件，亦是一样的原理

例如ThinkAdmin，继承了自己组件的controller。

咱们晓得了鉴权的方式，因此咱们首要看的是，倘若他无这些鉴权方式，或其他鉴权方式亦无，那样他就会存在未授权拜访，即不登录亦能拜访后台功能。这是很危险的，一个是管理员才可看到的敏锐信息，未授权就能看到，更危险的是，结合后台的漏洞，直接未授权getshell亦是特别有可能的，因此鉴权咱们首要去看，况且容易去看的地区。

6.2. 根据漏洞类型审计

我认为针对我来讲，比较好的审计办法是黑盒白盒一块，按照漏洞类型一个一个的去找寻可能存在漏洞的地区，而后再回溯查看是不是用户可控，以此快速定位漏洞。

因此通常我是按照漏洞类型，以及每一个漏洞可能触及的危险函数，去快速定位。

那通常看的地区有SQL注入、XSS、CSRF、SSRF、XML外边实体注入等等

6.2.1. sql注入

倘若运用了框架，能够分辨一下框架名叫作以及版本，去搜索一下该版本的框架是不是存在漏洞，倘若存在再去cms中验证。由于本篇文案重点讲我自己在cms审计上的有些经验，因此呢不多深入框架的审计部分。倘若无运用框架，则需要仔细的观察数据库函数，通常来讲，cms是将select、insert等函数进行了封装的，例如$db->table(‘test’)->where(“name=admin”)便是select * from test where name=admin这种格式，而此时若是发掘cms运用的是过滤+拼接，那样特别有可能会显现问题，而倘若运用了PDO，则继续跟进触及到table，order by等字段的拼接去，由于这些字段是没法运用PDO的。

审计要素：

参数是不是用户可控是不是运用了预编译

那样首要，倘若无运用框架封装的sql语句，那样全局搜索insert、select等sql语句关键词，而后定位到详细的语句，而后查看里面有无拼接的变量，回溯可不可控。倘若可控并且存在字符串拼接，特别有可能就存在漏洞。

运用了框架的便是搜索的关键词不同样，还是得看是不是存在字符串拼接，可不可控。

即使运用了预编译，然则倘若在预编译之前字符串拼接了，那照样无鸟用，该注入还是能注入。

下面供给通常我会搜索的关键词（框架的按照你审计项目的框架的手册，自动搜索。）师傅们有想弥补的亦能够弥补。

insert create delete update order by group by where from limit desc asc union select

6.2.2. xss漏洞

审计要素

是不是存在全局参数过滤器，过滤规则是不是符合安全需求，是不是存在需过滤和不需过滤两种输出，页面是不是掌控恰当。输出时是不是进行编码（HTML、JS等）。前端是不是采用了Angularjs、React、vue.js等拥有XSS防护功能的前端框架进行数据输出。

这个的话，我就不会关键词搜了，我便是会在寻找其他漏洞的过程中，重视有无直接把输入原样输出的地区，亦无尤其关注这一起。

倘若想特意挖掘这一起，能够

查看是不是配置了全局的拦截器、过滤器。检测数据输出函数，例如常用的输出函数有print、print_r、echo、printf、sprintf、die、var_dump、var_export。

6.2.3. CSRF漏洞

与XSS攻击相比，CSRF攻击常常不大流行（因此呢对其进行防范的资源亦相当稀疏）和难以防范，因此被认为比XSS更具危险性。

审计要素

是不是在表单处存在随机token。是不是存在敏锐操作的表单。

CSRF重点利用场景实质上是有些越权的操作，或有些敏锐功能存在的地区，例如管理后台、会员中心等地区。咱们能够尝试搜索表单位置，查看是不是会生成随机token，在查看后端代码中是不是会先验证这部分的token。倘若无验证token，再进一步瞧瞧是不是有refer的关联验证，倘若无，那样就存在CSRF的问题。

能够尝试全局搜索

csrf-token csrf_token csrftoken csrf

下面是一个更新秘码的操作，假设构造一个链接为http://127.0.0.1/index.php?password_new=password&password_conf=password&Change=Change#的链接，直接发送给受害者点击，那样当前状况下，能够直接修改受害者的秘码，由于无进行任何的验证办法。当然通常代码不会这么写，只是拿DVWA的CSRF举个例子。

6.2.4. SSRF漏洞

ssrf是利用存在缺陷的web应用做为代理攻击远程和本地的服务器。平常的方式如下：

1.能够对外网、服务器所在内网、本地进行端口扫描，获取有些服务的banner信息;

2.攻击运行在内网或本地的应用程序（例如溢出）;

3.对内网web应用进行指纹识别，经过拜访默认文件实现;

4.攻击内外网的web应用，重点是运用get参数就能够实现的攻击（例如struts2，sqli等）;

5.利用file协议读取本地文件等。

审计要素:

是不是存在能够产生SSRF漏洞的函数。是不是存在内网ip位置正则过滤，且正则是不是严谨。是不是存在限制请求的方式只能为HTTP或HTTPS。

当然PHP底下经常可能会显现SSRF漏洞的重点有几个函数，它们分别是file_get_contents()、fsockopen()、curl_exec()、get_headers()。经过全文关键函数搜索，在看是不是限制了拜访端口，拜访协议，内网ip位置等。

利用file://、http/https:// 、dict://、gopher://协议去搞内网。

列一下，我经常搜索的关键词

file_get_contents fsockopen curl_exec get_headers fopen readfile

重视

通常状况下PHP不会开启fopen的gopher wrapperfile_get_contents的gopher协议不可URL编码file_get_contents关于Gopher的302转会显现bug，引起利用失败curl/libcurl 7.43 上gopher协议存在bug(%00截断) 经测试7.49 可用curl_exec() //默认不跟踪转，file_get_contents() // file_get_contents支持 php://input协议

各样绕过，我就不在这说了。

6.2.5. XML外边实体注入

审计要素

参数是不是用户可控是不是libxml版本为2.9.0以上是不是禁用了外边实体

这个通常我关注的少，仅仅是搜索“DOMDocument”，“SimpleXMLElement”和“simplexml_load_string”等关键词，分析下是不是存在参数拼接的XML字符串，或未做限制的批量解析办法。对参数进行回溯，判断其是不是用户可控。

6.2.6. 文件包括漏洞

审计要素

参数是不是用户可控是不是存在include，require，include_once, require_once等函数。

文件包括算是拿shell最快的办法了，因此通常要重点关注。

无非是include，require，include_once, require_once这四个函数，全局搜索这四个函数，一个一个去看，去回溯，查看变量可不可控。

6.2.7. 文件上传漏洞

审计要素

是不是检测了上传文件的文件类型是不是限制了文件上传路径是不是对文件进行了重命名文件体积是不是限制是不是返回了文件路径或文件路径很好猜测

有的项目，会对文件上传下载进行分装，因此能够全局搜索相关upload、file的函数，瞧瞧是不是封装了

function upload function file

倘若封装了，那样就看这些封装好的函数，有无上面说到的审计要素的漏洞。

倘若没封装，通常是move_uploaded_file这个函数，全局搜索，这个函数，回溯查看这些漏洞存不存在。（白盒黑盒一块搞比较好。）

6.2.8. 变量覆盖

审计要素

是不是存在导致变量覆盖的函数，例如：extract()、parse_str()、import_request_variables和$$等。是不是存在能够完整利用的攻击链。

通常就这几个函数和关键词

extract parse_str import_request_variables mb_parse_str $$

不外还有个特殊的配置，亦可能导致变量覆盖

register_globals全局变量覆盖

php.ini中有一项为register_globals，即注册全局变量，当register_globals=On时，传递过来的值会被直接的注册为全局变量直接运用，而register_globals=Off时，咱们需要到特定的数组里去得到它。

重视：register_globals已自 PHP 5.3.0 起废弃并将自 PHP 5.4.0 起移除。

当register_globals=On，变量未被初始化且能够用户所掌控时，就会存在变量覆盖漏洞：

<?php echo“Register_globals: “ . (int)ini_get(“register_globals”) . “<br/>“;if ($a) { echo “Hacked!”; } ?>

经过GET和POST方式输入变量a的值：

当然，亦能够从COOKIE中输入：

6.2.9. 代码执行漏洞

审计要素

php.ini文件中的disable_function是不是有禁用函数。是不是存在代码执行的敏锐函数。是不是输入变量可控。

全局搜索下面的关键词，回溯参数可不可控。

evalasser preg_replace create_function array_map call_user_func call_user_func_array array_filter usort uasort$a($b)（动态函数）

6.2.10. 命令执行漏洞

审计要素

参数是不是用户可控是不是配置了全局过滤器，过滤规则是不是符合安全规范是不是所有的命令执行参数都经过了过滤器，或受白名单限制

全局搜索下面的关键词，回溯参数可不可控。

exec passthru proc_open shell_exec system pcntl_exec popen

“（被反引号包裹的变量亦能够执行）

6.2.11. 任意文件下载/下载漏洞审计

审计要素

是不是存在…/、.、…\等特殊字符过滤。参数是不是用户可控是不是配置了相对路径或绝对路径。

查询这些关键词，查看变量是不是可控，是不是有过滤

fgets fgetss file_get_contents readfile parse_ini_file highlight_file file fopen readfile fread

**Tip:**前两天遇到个，过滤了config/database.php这般的正则匹配，还过滤了…，目的是防止目录穿越，读取服务器其他目录的文件，可是没过滤一个.

这般我运用config/./database.php绕过了正则，照样把敏锐文件读取出来了。。。

6.2.12. 任意文件删除

和上面的下载同样

搜索的关键词变了

rmdir unlink

6.2.13. 任意文件写入

还是同样，关键词为

copy file_put_contents fwrite

6.2.14. 会话认证漏洞

会话认证漏洞实质上触及的方面比较广，如cookie、session、sso、oauth等，当然这个漏洞比较平常是在cookie上，服务端直接取用cookie中的数据而无校验，其次是cookie加密数据在可预测的状况下。

审计要素

是不是cookie中的加密数据可预测。是不是cookie中的数据可预测。服务端是不是只依赖cookie来判断用户身份。

全局去寻找cookie生成的规律，判断是不是可预测，判断用户身份是不是只依赖cookie，而不是随机的，例如

鉴权是只经过cookie中的userid来判断，倘若我遍历userid，能够达到登录绕过或越权的目地。

6.2.15. 反序列化漏洞

通常实质审计的时候，项目中见的比较少，框架中见的比较多。

全局搜索serialize。瞧瞧存不存在可控变量。