先把“页数”和“对象”分开:扫描器通常按URL、文件路径、请求参数或资源指纹中的一种或多种计数,而你要处理的可能是“同一个被挂马的页面被多种方式命中”。在缺少完整数据或权限时,最小动作是导出报告的全部行,找出对象标识列,按同一实际对象做归并,再决定哪些行需要进入人工核验;这一步只能把重复项收敛,不能据此证明站点已经安全。
读一份报告时,不要先看“共发现多少条”,先看每一行到底在描述什么。常见情况是同一段恶意脚本被注入到多个页面,或同一页面被多个URL变体访问。两者都表现为“页数多”,但归并方式不同。
假设你拿到一份只有URL和命中类型的报告,没有服务器权限,也拿不到完整日志。此时不要追求一次性清空列表,按下面顺序做:
做完这四步,你得到的不是“真实感染数”,而是一份去重后的处理队列。队列变短说明归并规则生效,不说明漏报或误报已经排除。
假设报告里有100行,其中60行是同一段外链脚本出现在不同文章页,20行是同一页面的带参数URL,10行是同一文件的多个路径写法,剩下10行无法访问。按实际对象归并后,处理队列可能变成“清除1段脚本、核验1个页面、核验1个文件、调查10个待定项”。这个结果帮助你先做批量清除,再集中调查待定项;但它不能推出“只有4个对象被挂马”,因为待定项仍可能对应更多对象。
再假设报告里同一URL出现两次,一次标记为恶意脚本,一次标记为可疑外链。若两次都指向页面中同一段代码,可以合并为一行;若一次指向页面模板,一次指向数据库输出,合并会掩盖两个不同的注入位置。判断依据不是行数,而是注入位置和修复动作是否相同。
没有完整日志、服务器文件列表或数据库权限时,你仍可完成导出、归并、标记和排优先级。但以下结论不能仅凭去重后的报告得出:
若报告中的请求量、抓取量或命中量突然归零,也要保留其他解释:扫描任务未完整执行、目标不可达、规则被调整或输出被截断,都可能造成同样的现象。此时应回到原始报告和任务记录核对,而不是直接宣布问题消失。
去重表的用途是分配动作,不是替代核验。可按“同一修复动作”分组:需要删除同一段脚本的页面放在一组,需要检查同一模板的文件放在一组,需要登录或提权的对象放在一组。每组先做一个小样本,确认修复动作不会破坏页面功能,再扩展到同组其他对象。若小样本处理后报告仍出现相同指纹,说明注入源可能不在该页面本身,应转向模板、公共脚本、数据库输出或权限入口继续查。这个动作的结果会直接改变下一步:指纹消失且页面功能正常,才适合扩展到同组;指纹仍在,就不应继续批量删除,而要先定位注入源。