结业笔试复习图谱

安全需求要明确：

• 保护什么业务或数据。
• 谁在什么条件下可以操作。
• 条件不满足时，系统怎样处理。
• 用什么结果验证处理正确。
• 谁负责，验证证据保存在哪里。

示例：「普通用户只能查看本人订单。访问他人订单应被拒绝，访问本人订单应正常成功，并保留对应的请求和响应记录。」

✗「系统应当安全可靠」「尽量减少安全问题」等表述，缺少具体检查条件和验收标准。

• 身份认证：确认「你是谁」，凭据是否真实、有效。
• 业务授权：判断「你有没有权执行这项操作、访问这条数据」。

• 登录成功、Token 合法，不代表可以查看所有订单。
• 订单服务应使用可信的当前用户身份，检查订单归属及相应权限。
• 客户端提交的用户编号、管理员角色或订单归属，不能直接作为授权依据。
• 网关认证、WAF、前端隐藏按钮，都不能替代服务端的对象权限检查。

常见缩写

• JWT 是一种令牌格式，本课程用它承载认证信息。
• BOLA 指对象级授权缺失，例如用户越权读取他人订单。
• SAST 指静态应用安全测试，主要分析代码，不能替代业务场景的运行验证。

保持同一个用户身份，比较以下结果：

• 缺陷路径能够读取他人订单：说明存在越权风险。
• 安全路径拒绝读取他人订单：说明当前越权场景受到限制。
• 安全路径允许读取本人订单：说明当前正常业务没有被误伤。

★ 后两项应成对保留。只有拒绝结果，不能证明正常业务仍然可用。

记录还应说明用户、订单、请求路径、环境、版本和实际响应，不能只保存几个状态码。

状态码要结合请求条件和业务结果判断。

• 200 请求得到成功响应，但不自动表示安全控制正确。他人订单被错误返回，也可能是 200。
• 201 通常表示创建了新资源，课堂中用于首次创建订单。
• 401 身份凭据未通过检查，不能直接当成对象授权拒绝的证据。
• 403 请求被拒绝，需要结合身份、对象和拒绝原因解释。
• 409 课堂中用于重复事件或幂等内容冲突，需要继续核对业务是否发生重复更新。

格式错误的 Token 返回 401，且服务没有崩溃，只能说明这类异常认证输入被受控拒绝，不能证明全部 JWT 风险已经消除。

支付回调

• 同一支付事件重复到达，不能再次产生业务更新，例如重复记账、重复发货。
• 支付回调是支付方通知商城处理支付结果。先检查通知真实性及适用的时效、订单、金额和状态，再决定是否更新。
• 校验失败不能错误改变业务状态。
• 判断防重复处理是否正确，要查看响应、订单状态和业务更新次数，不能只看日志里有没有某个标记。

回调防重复关注同一支付事件，创建订单幂等关注同一业务请求；两者都要避免重复副作用，但标识和处理协议不一定相同。

课堂回调场景可用 409 表示重复事件；真实支付协议也可能要求重复通知返回成功确认。不能死记「重复请求必须返回 409」，关键是按约定响应且不再更新业务。

创建订单的幂等控制

掌握三种情况：

• 首次提交：创建一个业务结果。
• 同一个幂等键、相同内容再次提交：返回原结果，不重复创建订单。
• 同一个幂等键、不同内容再次提交：按规则拒绝冲突，不能静默采用新金额。

关键证据包括订单是否相同、是否识别为重放，以及库存、金额等业务副作用是否只发生一次。

读输出时：id 是业务对象标识；replayed=true 表示系统将本次识别为重放。仍要核对是否返回同一对象，以及订单数量等副作用。没有提供库存或记账结果时，应写「未提供，待验证」。

CORS 管的是浏览器能否让网页读取跨源响应。需要分清：

• 没有获得跨源读取许可，不代表请求没有到达服务器。
• 浏览器读不到响应，不代表业务没有产生变化。
• 命令行等非浏览器客户端，不受浏览器的 CORS 机制约束。
• CORS 不能替代服务端身份认证和对象授权。

ACAO 是 Access-Control-Allow-Origin 响应头，表示允许哪个网页来源跨源读取。Gateway 配置文件写好只说明形成配置候选；还要核对真实产品版本、加载情况和目标环境中的异常与正常结果。课程 Node 服务的测试结果不能直接证明 Gateway 或 Redis 配置生效。

判断顺序：先核实身份 → 再检查对象权限 → 最后根据角色和用途决定字段显示范围。

需要掌握：

• 角色应来自可信身份和服务端授权，不能相信客户端自称管理员。
• 无权查看他人订单时，应拒绝访问，不能遮住手机号后继续返回整张订单。
• 管理员查看原文也需要相应的权限、用途和范围。
• 接口、日志、数据库、备份和导出需要分别检查。

接口显示星号，不证明数据库已经加密，也不证明数据已经匿名化。

一份日志里搜不到完整手机号，只说明当前样本和检索条件下未发现，不能据此宣布整个项目的数据安全达标。

可复核的记录应包含

• 操作环境、版本、时间和操作者。
• 工作目录、命令、地址或端口。
• 测试身份、对象、输入和前置条件。
• 异常路径与正常对照的实际结果。
• 原始输出保存位置。
• 当前状态和未验证项。

★ 应保留失败输出，不能只留下成功截图。

不同材料能够证明的内容不同

• 需求或设计：说明提出了要求或方案。
• 配置文件：说明形成了配置，不一定已加载或生效。
• 课堂运行结果：只支持当前环境、版本和已测场景。
• 定向静态检查通过：不等于编译、业务回归和真实复扫已经通过。

课程结果不能直接写成客户生产环境已经验证。

扫描没有报告问题，不等于问题不存在。High 为零，也不能单独作为上线依据。

扫描结果与手工测试看似冲突时，应当：

• 核对版本、环境、身份、对象和时间范围。
• 判断两份材料各自覆盖什么。
• 保留实际可复现的问题及原始证据。
• 核对修复后的异常拒绝与正常成功。
• 按仍存在的缺口调整结论。

扫描未发现对象越权，不能抵消同范围内实际读取到他人订单的结果。修复后的成功验证，也不能成为删除原失败证据的理由。

修复状态

个人修改后得到 1/1 PASS，在没有编译、业务回归和真实复扫时，应写：

「课程定向静态修复检查通过，待编译、回归与同版本真实复扫。」

不能直接写「漏洞已关闭」或「已在生产生效」。

发布条件

• 发布结论应与证据匹配。关键验证缺口未解决时，不能无条件宣布可以上线。
• 分清评审建议与发布授权。关键前置条件尚未满足时，应写「暂不发布，满足条件后重新评审」，不能把「带条件」理解成允许先上线后补关键验证。
• 正式风险接受与生产发布由有权责任方决定，课堂答辩不构成实际授权。

可检查的条件要包含：

• 补证对象与执行动作。
• 可观察的完成标准。
• 责任人和截止时间。
• 未完成时的阻断、回退或重新评审安排。

「后续加强监控」「持续关注」「尽快修复」都不够具体。

回退安排

• 需要说明什么情况触发回退、恢复哪个版本或配置、由谁执行，以及回退后怎样检查正常业务与安全控制。

★ 回退目标也必须经过验证，不能退回仍有原漏洞的版本。没有安全可用的版本时，应提出暂停或隔离受影响功能等方案，并由有权责任方确认。