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'] 就默认它是整数，其实它只是字符串——哪怕前端写了 <input type="number">，后端没校验照样能传 id=1%00abc 或 id[]=1 触发类型混淆。
使用场景：参数用于数据库查询、文件操作、跳转地址、模板渲染时，必须做显式转换和范围限制。
立即学习“PHP免费学习笔记（深入）”；
- 数字型参数别只用
(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() 校验真实路径。细节不在文档里，在每一行参数传递的上下文中。
