PHP项目怎么看这波进攻的威胁程度？从日志、流量到代码层的完整研判指南
目录导读
- 为什么"看威胁"比"挡威胁"更重要
- 第一层研判：从访问日志里读出进攻意图
- 第二层研判：流量特征与请求指纹分析
- 第三层研判：代码与配置面的暴露程度
- 第四层研判：威胁等级评分模型
- 常见问题问答（FAQ）
- 落地清单：今天就能做的七件事
为什么"看威胁"比"挡威胁"更重要
很多PHP项目团队一遇到异常流量,第一反应是"赶紧上WAF、赶紧封IP"，但封禁是动作，研判才是决策依据，如果威胁程度判断错了，轻则误封正常用户、影响业务，重则把真正的攻击面漏在视野之外。
所谓"看这波进攻的威胁程度"，本质是回答三个问题：谁在打、打到哪一层、打穿之后能拿到什么，PHP项目的特殊性在于——它通常暴露在公网、依赖大量第三方组件、错误信息容易泄露路径、上传与反序列化入口多，这些特性决定了同一波攻击对不同PHP项目的威胁程度可能相差十倍，因此研判必须结合项目自身资产价值，而不是照搬通用结论。
第一层研判：从访问日志里读出进攻意图
日志是最低成本、最高信息密度的研判素材，重点看四类信号：
请求路径的"探测密度"。 短时间内对 /wp-admin、/.env、/phpinfo.php、/vendor/、/backup.zip 等路径的集中请求，说明对方在做资产测绘，威胁处于"侦察期"，尚未形成实质打击，但意味着你的项目已被列入目标清单。
状态码分布。 大量404说明在盲扫；大量403说明对方在试探权限边界；出现500则要警惕——可能是对方触发了你的报错路径，错误页若回显堆栈，等于免费送出框架版本与目录结构。
请求方法的异常。 对静态资源发POST、对接口发PUT/DELETE、OPTIONS高频探测，往往是在寻找可写入或可越权的入口。
UA与Referer的一致性。 空UA、伪造UA、UA与请求路径明显不匹配（如用curlUA去打管理后台），是自动化工具的典型特征。
研判结论应落到一句话：对方是在"找门"还是"撞门"，找门阶段威胁程度中等但需立即收敛暴露面；撞门阶段（出现登录爆破、上传尝试、SQL关键词）威胁程度直接上调。
第二层研判：流量特征与请求指纹分析
单看日志容易误判,需要结合流量层特征交叉验证。
速率与节奏。 匀速低频的扫描往往是定向侦察，威胁等级高于无差别高频爆破——前者说明有人专门盯着你，反之，突发洪峰更可能是通用扫描器或DDoS前置探测。
参数载荷特征。 检查请求体是否携带 union select、sleep(、${jndi、O: 反序列化前缀、phar://、base64_decode 等特征串，PHP项目要特别关注反序列化与伪协议相关载荷，这是PHP生态的高危区。
会话与认证行为。 同一IP短时间内在多个账号间切换、登录失败后立即换路径重试、Cookie结构异常，都是账号层攻击的前兆，若项目使用JWT，还要看token是否被高频重放。
指纹识别反向利用。 攻击者会通过你的响应头、报错页、静态资源哈希判断框架与版本，你自己也要做同样的事：确认这些信息是否过度暴露，暴露越多，对方的攻击成本越低，等效威胁程度越高。
第三层研判：代码与配置面的暴露程度
威胁程度 = 攻击强度 × 你的暴露面，前两层看攻击方，这一层看自己。
依赖组件版本。 用 composer audit 与 composer outdated 核对是否存在已知漏洞的包，一个存在反序列化或文件包含漏洞的旧版本组件，会让"中等强度攻击"直接升级为"高危"。
危险函数与入口。 排查 eval、assert、unserialize、include、file_get_contents 的可控入参；检查上传接口是否校验了扩展名、MIME与内容；检查是否存在可被利用的 phar 触发点。
配置层暴露。 生产环境是否开启 display_errors、是否暴露 .git、.env、composer.json、是否关闭了目录索引、session存储是否可预测，这些"小问题"叠加起来，会把一次普通扫描变成一次成功的入侵。
权限与隔离。 数据库账号是否最小权限、上传目录是否禁止执行、是否与主站同域同权限，隔离做得越差，单点突破后的横向移动越容易，威胁的实际后果越严重。
第四层研判：威胁等级评分模型
把前四层信号折算成分数,形成可复用的判断标准：
| 维度 | 低（1分） | 中（2分） | 高（3分） |
|---|---|---|---|
| 攻击阶段 | 盲扫探测 | 定向侦察/爆破 | 已出现利用载荷 |
| 暴露面 | 组件最新、无敏感文件 | 个别旧组件 | 存在已知可利用漏洞 |
| 数据价值 | 展示型站点 | 含用户信息 | 含支付/身份数据 |
| 隔离水平 | 严格隔离 | 部分隔离 | 同权限混布 |
总分≤5为低威胁，按常规监控处理；6–8为中威胁，需收敛暴露面并加频率限制；≥9为高威胁，应立即启动应急响应、留存证据、评估是否已被打穿。
常见问题问答（FAQ）
Q1：只有日志没有WAF，能判断威胁程度吗？ 可以，日志+流量特征+自身暴露面三者交叉，足以给出可执行的等级判断，WAF提供的是拦截能力，不是判断能力。
Q2：扫描量很大，是不是一定很危险？ 不一定，高频盲扫往往是通用工具，威胁程度可能低于低频定向探测，要看载荷是否精准、是否针对你的框架版本。
Q3：PHP项目最该优先补的口子是什么？ 上传校验、反序列化入口、错误信息回显、敏感文件暴露，这四项覆盖了PHP生态最常见的失陷路径。
Q4：判断为高危后第一步做什么？ 先留存证据（日志、流量包、时间线），再做收敛与阻断，顺序反了，后续无法复盘攻击是否已成功。
Q5：多久复盘一次威胁程度？ 建议在每次异常流量事件后即时复盘，并每季度做一次暴露面全面体检，形成基线。
落地清单：今天就能做的七件事
- 关闭生产环境错误回显,统一错误页。
- 屏蔽
.env、.git、composer.json、备份文件的对外访问。 - 对登录与上传接口加频率限制与行为校验。
- 运行依赖审计,列出高危组件并排期升级。
- 上传目录禁止脚本执行,数据库账号降权。
- 建立日志基线,标注正常请求特征便于对比。
- 按上述评分模型,为当前这波进攻打一次分并记录结论。
看威胁程度,不是看攻击有多猛，而是看你的项目在那一刻有多脆，把攻击信号与自身暴露面放在同一张表上，威胁程度自然清晰。
