PHP|代码审计思路之PHP代码审计( 三 ) 控制器|自动化|网络安全

如果使用了框架，可以先看看此项目还有没有框架的漏洞存在，我就不再赘述了。
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防护功能的前端框架进行数据输出。

这个的话，我就不会关键词搜了，我就是会在寻找其他漏洞的过程中，注意有没有直接把输入原样输出的地方，也没有特别关注这一块。
【PHP|代码审计思路之PHP代码审计】如果想特意挖掘这一块，可以
查看是否配置了全局的拦截器、过滤器。检查数据输出函数，例如常用的输出函数有print、print_r、echo、printf、sprintf、die、var_dump、var_export 。
6.2.3. CSRF漏洞与XSS攻击相比， CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
审计要素