PHP代码审计要点与安全分析

PHP代码审计应重点盯住eval()、system()类和file_get_contents()三类函数；它们常因用户输入未过滤导致远程执行、路径遍历等高危漏洞，且易被绕过或隐匿于自定义函数与魔术方法中。

PHP代码审计最该盯住的三类函数

PHP安全问题八成出在函数误用，不是语法错，而是调用方式埋了雷。重点盯死这三类：eval()、system()、file_get_contents()（尤其带用户输入参数时）。

常见错误现象：页面报错但没回显，或某处突然能列目录、执行命令；后台日志里出现 Warning: file_get_contents(../etc/passwd) 这类路径拼接痕迹。

• eval() 几乎没有安全使用场景——哪怕加了 htmlspecialchars() 也拦不住绕过，直接搜 eval( 和 create_function(（PHP 7.2+ 已废弃，但老项目还在）
• system()、exec()、shell_exec() 必须检查所有参数是否经过 escapeshellarg() 或白名单过滤；passthru() 更危险，它不转义，直接透传输出
• file_get_contents()、include()、require() 接收用户可控变量时，极易触发路径遍历或远程文件包含（RFI），比如 $_GET['page'] 直接进 include

$_GET、$_POST、$_REQUEST 不是“默认可信”的代名词

很多审计者看到 $_POST['id'] 就默认它是整数，其实它只是字符串——哪怕前端写了 ，后端没校验照样能传 id=1%00abc 或 id[]=1 触发类型混淆。

使用场景：参数用于数据库查询、文件操作、跳转地址、模板渲染时，必须做显式转换和范围限制。

• 数字型参数别只用 (int) 强转——它会把 "1abc" 变成 1，而 filter_var($id, FILTER_VALIDATE_INT) 才真正校验合法性
• 字符串参数避免直接拼 SQL，优先用 PDO 预处理；若必须拼，至少过 addslashes() + mysql_real_escape_string()（仅限旧 MySQL 扩展），但更推荐统一走预处理
• 跳转类参数（如 redirect_url）必须校验协议头，拒绝 javascript:、data:、vbscript: 等非 http:// 或 https:// 开头的值

配置项和扩展启用状态直接影响漏洞面

有些漏洞根本不出现在业务代码里，而是 PHP 自身配置松动导致的。审计时不能只翻源码，得看 phpinfo() 输出或 php.ini 实际生效项。

性能 / 兼容性影响：开启某些调试功能会拖慢响应，但安全风险远大于这点开销。

• display_errors = On 会把致命错误、SQL 报错、路径信息直接打到页面上，给攻击者省去探测成本
• allow_url_include = On 是 RFI 的开关，只要没用到远程 include，一律关掉
• open_basedir 未设置或设为空，意味着任意文件读取不受限；设了但路径结尾没加 /，可能被绕过（如 /var/www 允许访问 /var/wwwroot）
• 已废弃扩展如 mysql_* 函数仍存在，说明项目长期未维护，大概率还混着其他过时写法

自定义函数和魔术方法容易成为漏网之鱼

审计常聚焦内置函数，却忽略开发者自己写的 get_user_by_id() 或重载的 __wakeup()。这些地方往往绕过常规过滤逻辑，又缺乏文档说明。

常见错误现象：反序列化数据进 unserialize() 后，对象属性被恶意构造，触发 __destruct() 里的 file_put_contents() 写 shell。

• 搜索所有 unserialize( 调用点，确认是否来自可信来源；PHP 7.4+ 推荐改用 json_decode() 替代
• 检查 __construct()、__wakeup()、__destruct() 方法体，看是否有未经校验的变量参与文件/SQL/命令操作
• 自定义函数命名若含 safe_、clean_ 等字样，反而要重点审——这类函数常被复用，一处有缺陷，全站失效

真正难搞的不是那些明晃晃的 eval()，而是某个 str_replace() 没处理好双写绕过，或者 basename() 前忘了 realpath() 校验真实路径。细节不在文档里，在每一行参数传递的上下文中。