📍 WDQWDWQD987AAAAA:216.73.217.70
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /46a2e15d248a.html
📄

网站漏洞检测 - 怎样安排问题优先级

网站漏洞检测后发现一堆问题，优先级的核心判断标准是：**先处理已被实际利用或可被直接利用、影响面大、修复成本低的问题**。具体来说，把远程代码执行、SQL注入、越权访问这类可直接导致数据泄露或服务器失控的漏洞排在最高位；把需要复杂前置条件、影响范围有限的问题排在后面。下面按观察、判断、处理、复查四步展开。

第一步：先观察，把问题按可利用性分类

拿到扫描报告或人工测试结果后，不要直接按“高危/中危/低危”标签排序，因为不同工具的评级口径不一致。先逐条看证据，问三个问题：

• 这个漏洞是否已有公开的利用方式（PoC）？
• 利用它需要什么前置条件（登录、特定参数、内网位置）？
• 触发后能拿到什么（数据、权限、服务中断）？

例如，扫描器报出一个 /api/user?id=1 的越权问题，如果未登录就能读取他人信息，属于可直接利用；如果必须管理员登录后才能触发，优先级就低一档。观察阶段的目标是给每个问题标注“可利用性”和“影响面”，而不是急着修。

第二步：判断优先级，用四个维度打分

把每个问题按以下四个维度各打 1–3 分，总分越高越优先：

1. 可利用性：1=需要复杂条件，2=需要登录，3=无需认证即可触发。
2. 影响范围：1=影响单个用户，2=影响部分数据，3=影响全站或服务器。
3. 暴露程度：1=仅内网可见，2=需特定路径，3=公网可直接访问。
4. 修复成本：1=改一行配置，2=需改代码逻辑，3=需重构架构。

总分最高的先修。这里有一个常见误区：不要因为某个漏洞“评级高”就优先修，如果它需要内网访问且修复要重构，而另一个中危漏洞公网可直接利用且改一行过滤就能堵住，后者应排前面。判断依据是证据链，不是标签。

第三步：处理，按批次而不是逐条修

把问题分成三批：

• 立即修：可直接利用且影响大的，当天处理，修完先验证。
• 本周期修：需要一定条件但影响明确的，排进本周任务。
• 计划修：低可利用性或高修复成本的，记录并安排后续版本。

每修完一条，记录修改前后的请求与响应差异作为证据。例如修复 SQL 注入后，用同样的 payload 再发一次，确认返回正常而非报错或泄露数据。

第四步：复查，确认修复有效且没有引入新问题

复查不是重跑一遍扫描器就结束。要针对已修问题做定向验证：

• 用原利用方式再测一次，确认不再触发。
• 检查修复是否影响正常功能（比如加了过滤后合法请求是否被误拦）。
• 确认没有因为修复而暴露新的入口。

如果复查发现修复无效，回到第二步重新判断优先级——可能之前低估了利用条件。复查结果要留档，作为下一轮检测的基线。

下一步：把当前所有未修问题按上述四维打分列成一张表，标出总分最高的三条，今天就处理第一条。