先给结论:不要先争论谁的结果“对”,而要把分歧拆成可核对的三类范围——目标范围、身份权限范围、扫描配置范围。最有效的动作是让持不同结果的两个人各自导出本次扫描的任务配置(目标列表、认证方式、排除规则、扫描策略),逐项对照。只要有一项不同,两套结果就不构成互相否定的证据;如果三项完全一致却结果仍不同,才需要转向时间差、会话失效或工具本身差异去查。
常见场景是:管理员账号扫描后报告里出现一批需要登录才能触达的页面问题,普通成员账号扫描同一域名却只得到少量外部可见项。双方都认为自己的结果反映了真实情况,于是争论集中在“工具准不准”上,这其实问错了方向。
更合理的两个解释是:
这两种解释会导向完全不同的处理方式:前者要讨论“应该用哪个身份代表真实风险”,后者要统一任务模板。所以下一步必须先区分它们。
最直接的证据是每个任务在启动时记录下来的配置。核对时看四组字段:
如果两人的目标范围和排除规则一致,只有认证角色不同,那么差异基本可以归到权限解释;如果连认证方式都一样,却策略深度不同,那更可能是配置解释。这一步的产出不是结论,而是一张“差异字段表”,它决定后面该找谁确认。
确认是权限解释之后,不要停留在“管理员权限更大所以更全”这种模糊判断上。把身份差异落到具体权限项:
然后回答一个业务问题:这次扫描要代表哪种真实攻击面?如果目标是评估外部未授权攻击者能看到什么,就应以匿名或最低权限身份为准;如果目标是评估内部越权风险,就需要高权限身份,并同时保留低权限结果做对照。两种结果不是互相纠错,而是回答不同问题。
一个假设例子:某团队用管理员账号扫出 40 项、用只读账号扫出 12 项。核对后发现只读账号无法进入三个后台模块,而管理员可以。此时正确动作不是删掉 28 项,而是标注这 28 项属于“需登录后可见”,并在报告中说明所依据的身份。下一步要么补充匿名扫描作为外部视角,要么明确本次评估只覆盖已授权区域。
建议固定按这个顺序走,避免来回返工:
要警惕一种误判:把“结果更少”直接当成“权限不足”或“工具漏报”。结果变少还可能来自目标下线、排除规则新增、认证会话中途失效导致后续请求退回匿名状态,或扫描时段内目标返回了不同的响应。反过来,结果更多也不必然说明权限更高,可能只是策略更激进、爬取更深。
当三项配置完全一致、结果仍明显不同,再记录扫描起止时间、认证是否在任务中途失效,以及目标在两次扫描之间是否发生过发布变更。这些记录能把“工具不一致”这个笼统说法,收敛成可以复现的具体条件。
可执行的做法是:为同类目标建立一个基准任务模板(固定目标写法、固定排除规则、固定策略深度),只把认证身份作为唯一变量。用同一模板分别以匿名、普通成员、管理员身份各跑一次,把三次结果并列,差异项就是权限带来的可见性差异。这个对照表既能回答“谁的结果更全”,也能回答“全出来的部分是否属于本次评估范围”。
如果团队只需要一个对外结论,就选定与评估目的匹配的那个身份作为主结果,其余身份结果作为补充说明;如果评估目的本身包含越权风险,则必须以多身份结果同时呈现。具体工具支持哪些身份配置、能否导出任务配置快照,需要以你所使用工具的当前文档和实际界面为准,不同产品差异较大,不宜照搬他人的字段名。