挂马扫描软件一次全站扫描被中断后怎样判断已覆盖范围

📍 WDQWDWQD987AAAAA:136.243.57.164
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /abd53d41c0cf.html
📄

挂马扫描软件一次全站扫描被中断后怎样判断已覆盖范围

中断后不要直接重跑,也不要凭“扫过一半”估算覆盖。更可靠的做法是:先确认扫描器是否留下可续跑的进度记录或结果文件,再按目录、URL 清单和文件时间三个维度交叉比对,找出“已出结果”“已请求但无结果”“完全未触及”三块区域,最后只补扫缺口。下面用一个假设情境说明判断过程。

先分清中断发生在哪一层

挂马扫描软件的中断点通常落在三种位置,覆盖范围的判断方式完全不同。

判断第一步是找到扫描器输出的中间产物:结果文件、进度文件、日志、缓存目录。如果这些都不存在,覆盖范围就只能靠外部证据重建,成本会明显上升。

假设情境:一次中断后怎样重建覆盖清单

假设某站点有约 2 万个可访问 URL,用一款挂马扫描软件做全站扫描,跑到中途进程被终止。扫描器留下了一个结果文件和一个日志文件,但没有断点续跑功能。可以按以下顺序处理。

  1. 从结果文件提取已出结果的目标集合,记为集合 A。这是唯一能确认“已检查”的部分。
  2. 从日志提取已发起请求的目标集合,记为集合 B。B 减去 A 就是“请求过但没有有效结果”的部分,包括超时、被拦截、解析失败。
  3. 用站点自身的 URL 清单(sitemap、内链抓取结果或访问日志)构建全集 C。C 减去 B 就是完全未触及的部分。
  4. 对 A 内部再做一次可信度筛选:把返回 403、429、5xx 或空响应的条目从“已覆盖”里剔除,归入待复查。

这样得到的补扫范围是“B 减 A”加上“C 减 B”,再加上 A 中被剔除的可疑条目。它通常比“重跑全站”小,但比“只补后半段”更准确。

用文件时间做交叉验证,而不是只看数量

仅凭结果条数判断覆盖容易出错,因为同一批文件可能被重复记录,也可能有大量条目指向不存在的路径。更稳的交叉验证是看文件修改时间。

在假设情境中,可以取结果文件里出现过的文件路径,按修改时间排序。如果扫描是按目录顺序推进的,结果覆盖的时间分布应该与目录顺序大致对应;如果结果集中在某个时间段、某个目录,说明扫描很可能在那里中断,之后的目录基本未覆盖。反过来,如果结果分散在所有目录但每个目录都不完整,说明中断发生在并发扫描过程中,不能按目录边界切分补扫范围。

这一步的实际动作是:导出结果中的“路径 + 修改时间”两列,按目录聚合,看哪些目录的结果数量明显低于其文件总数。这些目录优先补扫,而不是平均分配资源。

中断后的结果能用到什么程度

已覆盖部分的结果并非都能直接用于处置,需要按证据强度分层。

换句话说,中断后的扫描结果可以用来“发现已发现的问题”,不能用来“证明没有问题”。这个边界决定了后续动作:先处理已确认的命中项,再安排补扫,而不是先宣布站点干净。

补扫范围确定后,下一步怎么走

补扫不是简单重跑。根据前面的分层结果,可以选两种路径。

路径一:只补缺口。适合扫描器支持指定 URL 列表或目录范围、且中断前的有效结果可信度较高的情况。把“B 减 A”和“C 减 B”合并成补扫清单,交给扫描器定向执行。代价是清单构建本身需要一次 URL 全集整理,如果站点结构复杂,这一步可能比全站重跑更费时。

路径二:全站重跑但保留旧结果。适合扫描器不支持定向输入、或中断原因不明(可能是工具本身不稳定)的情况。重跑前先归档旧结果,避免新旧结果混在一起无法区分。重跑后把新旧结果按目标路径合并去重,再统一判定。

选择依据不是“哪个更快”,而是“哪个能给出可复核的覆盖证明”。如果补扫清单无法覆盖所有未触及区域,全站重跑反而更省事。

无论选哪条路径,补扫完成后都应重新生成一份覆盖清单,标明每个目标的状态:已检查、已请求未检查、未请求、已检查但结果可疑。这份清单是判断本轮扫描能否收尾的唯一依据,也是下次中断时重建进度的起点。

图1 图2

nginx