中断后不要直接重跑,也不要凭“扫过一半”估算覆盖。更可靠的做法是:先确认扫描器是否留下可续跑的进度记录或结果文件,再按目录、URL 清单和文件时间三个维度交叉比对,找出“已出结果”“已请求但无结果”“完全未触及”三块区域,最后只补扫缺口。下面用一个假设情境说明判断过程。
挂马扫描软件的中断点通常落在三种位置,覆盖范围的判断方式完全不同。
判断第一步是找到扫描器输出的中间产物:结果文件、进度文件、日志、缓存目录。如果这些都不存在,覆盖范围就只能靠外部证据重建,成本会明显上升。
假设某站点有约 2 万个可访问 URL,用一款挂马扫描软件做全站扫描,跑到中途进程被终止。扫描器留下了一个结果文件和一个日志文件,但没有断点续跑功能。可以按以下顺序处理。
这样得到的补扫范围是“B 减 A”加上“C 减 B”,再加上 A 中被剔除的可疑条目。它通常比“重跑全站”小,但比“只补后半段”更准确。
仅凭结果条数判断覆盖容易出错,因为同一批文件可能被重复记录,也可能有大量条目指向不存在的路径。更稳的交叉验证是看文件修改时间。
在假设情境中,可以取结果文件里出现过的文件路径,按修改时间排序。如果扫描是按目录顺序推进的,结果覆盖的时间分布应该与目录顺序大致对应;如果结果集中在某个时间段、某个目录,说明扫描很可能在那里中断,之后的目录基本未覆盖。反过来,如果结果分散在所有目录但每个目录都不完整,说明中断发生在并发扫描过程中,不能按目录边界切分补扫范围。
这一步的实际动作是:导出结果中的“路径 + 修改时间”两列,按目录聚合,看哪些目录的结果数量明显低于其文件总数。这些目录优先补扫,而不是平均分配资源。
已覆盖部分的结果并非都能直接用于处置,需要按证据强度分层。
换句话说,中断后的扫描结果可以用来“发现已发现的问题”,不能用来“证明没有问题”。这个边界决定了后续动作:先处理已确认的命中项,再安排补扫,而不是先宣布站点干净。
补扫不是简单重跑。根据前面的分层结果,可以选两种路径。
路径一:只补缺口。适合扫描器支持指定 URL 列表或目录范围、且中断前的有效结果可信度较高的情况。把“B 减 A”和“C 减 B”合并成补扫清单,交给扫描器定向执行。代价是清单构建本身需要一次 URL 全集整理,如果站点结构复杂,这一步可能比全站重跑更费时。
路径二:全站重跑但保留旧结果。适合扫描器不支持定向输入、或中断原因不明(可能是工具本身不稳定)的情况。重跑前先归档旧结果,避免新旧结果混在一起无法区分。重跑后把新旧结果按目标路径合并去重,再统一判定。
选择依据不是“哪个更快”,而是“哪个能给出可复核的覆盖证明”。如果补扫清单无法覆盖所有未触及区域,全站重跑反而更省事。
无论选哪条路径,补扫完成后都应重新生成一份覆盖清单,标明每个目标的状态:已检查、已请求未检查、未请求、已检查但结果可疑。这份清单是判断本轮扫描能否收尾的唯一依据,也是下次中断时重建进度的起点。