PHP原生开发篇&SQL注入&数据库监控&正则搜索&文件定位&静态分析

代码审计------第一百零五天

PHP原生开发篇&SQL注入&数据库监控&正则搜索&文件定位&静态分析

前置知识

代码审计主要的挖掘思路：
- 通过白盒审计 -> 直接审计源代码去搜索文件名、函数、功能点、关键词找漏洞
- 通过黑盒审计 -> 先黑盒找功能点，再白盒找对应逻辑漏洞
本节课主要是关于PHP代码中的SQL注入漏洞，用到三个CMS案例，通过三种方式去进行挖掘

PHP审计 - 原生开发-SQL注入-正则搜索

第一个案例是bluecms，在1.6版本中存在SQL注入，参数位置为user_id：
安装完之后用PS打开目录，由于是SQL注入，所以直接全局正则匹配关键词：

php 复制代码

# 通用匹配SQL语句
(update|select|insert|delete|).*?where.*=
# 或者更精确一点：
(update|select|insert|delete).*?\s+where\s+[`'"]?user_id[`'"]?\s*[=<>].*?

ctrl+shift+f全局搜索，记得这里打开正则匹配，然后找user_id的查询语句：
这里有几处都是查询user_id的，所以审计的时候就一个个看，或者也结合目录，从一些高风险目录开始看；也可以结合查询语句，重点看SELECT语句，然后参数是拼接的形式传入的，比如这个：
可以看到首先它在admin目录下，这个目录一看就知道是后台管理目录；其次它是SELECT语句，我们比较熟悉；最后它的参数是直接拼接上去，并且能够控制，不像下面的intval($_GET['user_id'])会转为整型，即：
1. 看文件路径
2. 看SQL语句
3. 看代码里面的变量
4. 看变量前后的过滤
因此这个点就是绝佳漏洞点，很可能出现漏洞，点进去看看，发现确实调用的query是原生的查询函数，没有做任何过滤：
于是我们直接找功能点，首先看路由信息，但是这里就是纯原生PHP，所以可以直接访问/admin/user.php来到对应功能点：
源码中这里是act=edit，所以应该就是这里的编辑功能，点进去就能发现它的参数为?act=edit&user_id=1，刚好对应我们的代码，所以可以直接尝试union联合注入：

python 复制代码

# 列判断
http://bluecms:7821/src/uploads/admin/user.php?act=edit&user_id=-1 order by 17 --+

# 注入回显
http://bluecms:7821/src/uploads/admin/user.php?act=edit&user_id=-1 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17 --+

可以看到回显位有4，12，13，14，这时候就已经说明存在注入了，那我们就直接用sqlmap跑就行了，注意由于是后台，所以尽量用数据包的形式去跑：

bash 复制代码

python sqlmap.py -r bluecms.txt --dbs

可以看到爆出了数据库名，所以这里就成功复现了这个SQL注入漏洞，比较简单，主要就是前期的一个寻找手段

PHP审计 - 原生开发-SQL注入-功能跟踪

第二个案例是emlog，也是国产的CMS，目前仍在更新，它的v6.0.0版本后台co**.php页面存在SQL注入：
同样安装完成之后PS打开源代码，找到后台co**.php目录，也就只有comment.php和configure.php这两个文件
那首先这个configure.php文件就不用考虑了，因为是配置文件，那剩下的就只有comment.php了，这个根据名字就知道是评论功能
简单看一看我们可以发现在$action=='delbyip'这里，它需要接收一个ip值，然后调用delCommentByIp()函数去删除评论：
跟踪这个删除函数，可以发现它会先查询然后再删除，并且没有任何过滤，构成SQL注入条件：
我们直接来前台功能点，看看在哪里能够触发：
这里很明显就是删除功能，但是触发它需要先创建评论，我们就随便创建个评论然后点ip旁边的删除按钮才是触发通过IP删除：
抓包拿到它的url链接就是我们代码中看到的参数格式：

php 复制代码

/admin/comment.php?action=delbyip&ip=127.0.0.1&token=856ae20d334b43d98cb847785df8cad0

所以这里的参数ip存在SQL注入，尝试注入验证一下：
可以看到成功报错，于是直接sqlmap注入，或者手工报错注入一下：
这里也找到注入点并且利用成功，也是复现了这个漏洞

PHP审计 - 原生开发-SQL注入-语句监控

今天最后一个案例依旧是emlog，在其2.1.9版本的/admin/user.php文件存在SQL注入：
同样安装完成之后PS打开文件，找到对应位置，但是一开始看其实是没有直接传入然后拼接的，都是经过addslashes()转义的，然后我们看功能点好像也找不到什么注入的地方：
所以直接这么看源码我们可能找不到从哪个点入手，于是这里可以换种思路，就是这个程序在启动当前页面时会执行哪些数据库查询操作，从而反推出哪些参数我是可以间接控制的
于是我们就会用到一些数据库监控工具，比如这个MySQL-Monitor，将它的源码放到网站源码下，访问mysql_monitor_client.html：
输入账密连接即可监控，这里我们就监控user.php文件刚打开时加载的SQL语句：
可以看到加载了5条SQL语句，你就可以拿着这几个语句去代码中搜索，看看在哪里，然后看看传入的参数有没有过滤之类的
然后在这里我们可以看到这个admin，明明上面我的用户名是emer，但这里却没有，所以这里可能就是有问题的
这个admin其实是我们登录时的用户名，而这个个人信息这里我们刚好是可以修改这个登录用户名的：
但是把源码翻了一遍发现...修改的部分全部都被过滤掉了，那看看能不能添加用户去尝试二次注入，但这里的逻辑也不对：
它的nickname是随机生成的，其他参数也是被过滤的，所以我自己审的时候也是真没找到哪里可以注入
看了小迪发现是在data.php这里可以导入sql语句数据包去添加用户，在添加用户的时候注入，泥煤的这谁能想到：
于是先导出数据包，在最后添加一行插入语句：

sql 复制代码

INSERT INTO emlog_user VALUES('2','test','$P$BHGJVzzyTVZn6hjFvimUWEO7BFLsds.',(select version()),'admin','n','','12346@qq.com','','127.0.0.1','0','1775287797','1775305049');

通过导入备份上传，成功注入，也就完成了这个漏洞的复现：