安全测试实战手册

先问：我们到底在保护什么？

安全测试的核心不是证明系统“绝对安全”，而是识别攻击者最可能利用的路径，在上线前把高影响、低成本利用的问题消掉。

• 账户与权限：别人能否冒充用户，或获得不该有的能力？
• 业务资产：金额、库存、优惠券、积分、订单能否被篡改或重复使用？
• 敏感数据：个人资料、Token、密钥和内部配置会不会泄露？
• 可用性：恶意请求能否拖垮服务、耗尽资源或绕过限流？

测试边界

• 只在已授权的系统、环境、账号和时间窗口内测试。
• 优先使用测试环境、测试数据和非真实支付渠道。
• 发现高危问题立即停止扩大验证并同步负责人。

常见攻击面

最小威胁建模

1. 列出资产：账号、订单、资金、文件、后台权限、密钥。
2. 列出入口：页面、接口、后台、任务、回调和第三方集成。
3. 思考攻击者目标：偷数据、越权、薅优惠、伪造回调还是拖垮系统？
4. 给风险按影响和发生概率排序，先测高风险路径。

身份认证测试矩阵

额外检查

• Cookie 应设置 HttpOnly、Secure 与合适的 SameSite 策略。
• Token 不应放在 URL 查询参数中，避免进入日志、历史记录和 Referer。
• 登录、改密、绑定设备等敏感操作应有适当的二次校验。

权限测试要覆盖资源、角色和字段

实操顺序

1. 准备至少两个普通用户和一个管理员账号，资源归属要不同。
2. 分别用不同 Token 请求相同接口，只改资源 ID 或归属字段。
3. 检查读取、修改、删除、导出、批量操作是否都做了服务端校验。
4. 不能只看前端按钮是否隐藏；真正的判定必须发生在服务端。

高频验证点

输入验证的正确位置

• 前端校验提升体验，但不是安全边界；攻击者可以绕过页面直接请求接口。
• 服务端对类型、长度、格式、枚举值和业务状态做白名单校验。
• 错误信息对用户要可读，对攻击者要克制：不回传 SQL、调用栈、绝对路径或密钥。

电商与交易场景必测

• 改价格、改数量、改优惠券 ID：服务端必须重新计算金额。
• 支付回调重复、乱序或伪造：订单状态和资金流水必须幂等且可验证来源。
• 并发抢库存、领券、签到：不能超卖、超发或重复记账。
• 退款、取消、确认收货等状态不能跳级，权限和时间窗口必须受控。

一个判断标准

如果攻击者不需要绕过技术防线，只要篡改一个正常参数就能获得不当利益，这就是业务安全问题。用例要从“用户会不会这样点”升级到“恶意用户会怎样构造请求”。

一份有效漏洞报告至少包含

• 标题与等级：清楚表达什么问题、影响什么资产。
• 受影响范围：环境、接口、账号角色、前置条件。
• 最小复现步骤：请求方法、参数变化、可观察结果。
• 影响说明：攻击者实际能读取、修改或造成什么损失。
• 修复建议：给出原则与方向。
• 复测结论：原路径被阻断，正常业务没有回归。