验证PHP 7.3文件包含漏洞修复是否生效，需通过四类实操方法：一是用curl测试典型载荷（如路径穿越、php://filter）确认响应为400/403且无敏感内容；二是审查所有include/require调用点，确保白名单校验或路径规范化全覆盖；三是用phpsploit或Acunetix复测并比对报告；四是检查服务器与PHP日志中是否拦截攻击且不泄露路径。
验证 PHP 7.3 文件包含漏洞（如 LFI）修复是否生效，不能只看“补丁装了没”，关键在于确认攻击路径是否真正被阻断、输入是否被有效约束、响应是否符合防御预期。以下四类实操方法缺一不可，覆盖检测、触发、代码、日志四个层面。
用典型载荷直接测试响应行为
文件包含漏洞的修复效果，最直观体现在对恶意路径请求的拦截能力上。PHP 7.3 常见绕过方式包括路径穿越（../../../../etc/passwd）、空字节截断（%00，虽在 PHP ≥5.3.4 默认禁用，但旧配置或兼容模式下仍需验证）、伪协议（php://filter/read=convert.base64-encode/resource=/etc/passwd）等。
- 用 curl 发起测试：
curl "http://your-site.com/vuln.php?file=../../../../etc/passwd"，检查返回状态码是否为 400/403/404，且响应体中不出现系统文件内容或目录结构信息 - 补充测试伪协议：
curl "http://your-site.com/vuln.php?file=php://filter/read=convert.base64-encode/resource=index.php"，确认返回不是 base64 编码的源码，而是报错或空响应 - 若应用使用 POST 参数，改用
curl -X POST -d "page=../../../../etc/passwd" http://...复测，覆盖全部用户输入入口
检查修复代码是否覆盖所有包含点
很多修复只改了主逻辑，却遗漏了 include_once、require 等调用点，或未处理 $_REQUEST 混合来源。必须人工审查实际运行的 PHP 文件。
- 定位所有含
include(、require(、include_once(、require_once(的文件，尤其是接收$_GET、$_POST、$_REQUEST的位置 - 确认每个调用前是否有白名单校验（如
in_array($page, ['home', 'about', 'contact'])）或路径规范化+固定前缀（如realpath('pages/' . $page) === 'pages/' . $page） - 检查是否禁用危险配置：确认
php.ini中allow_url_include = Off、allow_url_fopen = Off（防 RFI），且display_errors = Off（防路径泄露）
借助安全扫描工具交叉复测
人工测试易漏变体，需用工具覆盖常见载荷组合与编码绕过。
- 使用 phpsploit 或 Arjun 对目标接口发起自动化 LFI 扫描，重点关注
?file=、?page=、?lang=等常见参数名 - 商业工具如 Acunetix 或 Nessus 可识别 CVE-2026-109618/109619 关联特征（如内存耗尽响应、释放后使用触发的 502 错误突增）
- 对比修复前后扫描报告，确认原漏洞条目状态变为 “Not Exploitable” 或 “No Issue Found”
监控 Web 服务器与 PHP 错误日志
真正的修复会在日志中留下“防御痕迹”。攻击尝试仍在发生，但响应方式已改变。
- 查看 Apache 的
error_log或 Nginx 的error.log，搜索关键词Warning: include()、failed to open stream，确认其不再输出完整路径（如include(): Failed opening '/var/www/html/../../../../etc/passwd' for inclusion） - 检查 PHP-FPM 的
slowlog和access.log，观察含可疑路径参数的请求是否返回 502 Bad Gateway（表明补丁已触发内存保护机制）或 400 Bad Request（表明前置过滤拦截） - 若部署了 ModSecurity 或 ngx_waf，确认规则 ID（如
930110LFI 规则）有匹配记录，且action字段为deny
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
