博彩平台收银台安全测试：签合同前要核对的测试用例清单

简短回答

一次针对博彩平台收银台的渗透测试，要验证五件事：一笔存款不能被记两次账；一笔提款不能被付两次、也不能付到未授权的地址；红利引擎不能被玩成超出促销规则的派彩；收银 API 执行的授权检查与网页端完全一致；后台的特权操作有日志、且不能自己审批自己。下面是我们定范围时逐类对照的测试用例矩阵。签合同前，拿它去核对供应商的范围书。

这篇写给谁

写给即将在渗透测试工作说明书（SOW）上签字的 CTO、安全负责人或合规负责人：你想知道报价单里的“收银台”三个字，指的是一个被命名、被实际测试的资产，还是一个没人会碰的行项目。本文默认你已经决定做渗透测试；如果还在漏洞扫描和完整人工测试之间犹豫，先读漏洞评估与渗透测试的区别。本文也不讲撞库攻击如何一路打到收银台，也不讲整个项目的分档与价格——那些在渗透测试报价单必须写清的几件事里。

为什么收银台需要自己的测试用例清单

对面向亚洲玩家的平台来说，收银台从来不是一个功能，而是四个子系统：存款、提款、红利与促销、以及它们背后的 API 与特权工具。再加上现实情况——USDT 与多条本地支付通道并行、白牌平台与代理后台各自有一套接口——通用的 Web 应用测试清单根本不是为它写的。一个把“收银台”当成一次登录加几次点击的测试员，会确认页面能渲染、表单有校验，然后漏掉所有真正让运营商亏钱的问题。因为那些问题藏在系统允许一个合法的、已登录的会话做什么，而不是什么会把系统弄坏。

这也是自动化扫描器在结构上帮不上忙的原因。纯人工测试存在的意义，就在于扫描器不知道一个红利每个账户只能触发一次，也不知道修改提款地址应该要求重新验证身份——它只能确认端点返回了格式正确的响应。下面每一条用例都是一个业务逻辑问题，不是一次特征匹配。

测试用例矩阵

存款

测试用例	验证什么
确认回调重放	来自支付处理商或链上监听器的存款确认回调，不能被重放后给同一笔存款记两次账
服务端金额校验	入账金额来自处理商或链上已确认的数值，而不是客户端传上来、可在传输中篡改的参数
责任博彩存款限额	玩家自设或牌照方要求的存款限额在 API 层执行，而不只是在前端表单里
链上确认深度	加密货币存款达到配置的确认数后才入账；同一个交易哈希不能被重复提交再记一次账

提款

测试用例	验证什么
并发提款竞争	对同一余额同时发起的两笔提款请求，不能都成功
修改收款地址时的升级验证	新增或更改收款地址（银行账户、电子钱包或链上地址）需要当前会话之外的再次身份验证——这是对抗账号接管后套现最有杠杆的一道控制
余额边界操纵	负数、溢出、小数单位等花样不能产生超过实际可用余额的提款
KYC/AML 冻结状态执行	合规部门设置的冻结状态在每一条提款路径上都由服务端执行——包括移动端、代理与合作方 API，而不只是主站网页流程

红利与促销引擎

测试用例	验证什么
红利 ID 重放	同一身份不能通过账号找回、会话克隆或并行注册路径再领一次红利或促销码
流水要求完整性	作废、取消或退款的投注被排除在流水进度之外，而不是被算进去
对冲套利滥用	能产生近乎确定回报的投注方式（例如在相关盘口上下对冲注）按设计被排除在红利资格之外，而不只是写在规则里
跨账户红利叠加	同一资金来源、设备或身份信号不能在多个账户上领取“新玩家”红利而不被发现

收银 API

测试用例	验证什么
网页端与移动端、合作方 API 的一致性	网页收银台执行的每一项授权与限速检查，在移动 App、代理后台与合作方集成的 API 路径上同样执行——这是我们最常发现的缺口，因为这些路径上线比评审快
对象级授权	交易、账户、提款请求的 ID 不能被枚举或替换，去读取另一名玩家的收银数据
回调签名校验	支付处理商的入站回调经过签名验证；伪造的、或从处理商公布来源之外重放的回调被拒绝
按会话限速	收银端点按账户或会话限速，而不只按 IP——跑在住宅代理上的机器人网络能轻易绕过只看 IP 的限制

特权操作与后台

测试用例	验证什么
禁止自审自批	把一笔提款标记为人工复核的客服或后台人员，不能同时是批准它的人
特权操作审计轨迹	每一次手工加款、扣款、KYC 覆盖、提款审批都记录身份、时间戳和原因——是牌照方或调查人员真正用得上的日志
会话劫持抵抗	后台与管理员会话在正常超时窗口之后，不能用被盗令牌重放或劫持
最小权限执行	只授权“查看 KYC 状态”的角色不能执行收银覆盖操作——角色边界要经过测试，而不只是写在文档里

测会动钱的系统，又不把它弄坏

收银台测试有一个多数 Web 应用渗透测试没有的约束：上面每一条用例都碰到会转移真实资金的系统，所以“直接在生产环境上模糊测试”不是可接受的方法。实践中，这意味着三件事在测试开始前就写进测试授权规则（ROE），而不是留给测试员在项目中途自己判断：

• 用有真实余额的测试账户，不用生产账户。 存款与提款用例跑在预置的测试层账户上，或者跑在对接了支付处理商沙箱的预发布环境里，这样竞争条件或重放类的发现永远不会殃及真实玩家的资金。
• 特权操作测试的爆炸半径有上限。 后台与管理员用例只针对一组限定的测试身份，客户的合规或运营负责人随时在线，确认范围之外没有任何东西被动过。
• 任何不明确的情况都有指定的停止条件。 如果一条用例的结果不清楚——那个请求到底有没有给账户记账，还是只返回了一个 200——测试暂停，由客户确认后再继续，而不是测试员猜一下就往下走。

这些都不会实质拖慢项目；它就是任何一次 AnySec 渗透测试都遵守的签字 ROE 纪律，套用到一个处理的是钱而不只是数据的系统上。

你会拿回什么

收银台范围的渗透测试交付物，与其他项目的报告结构一致：一份用业务语言写的管理层摘要；多个中危发现串联成一个严重收银台影响的利用链叙述；开发人员可以复现的步骤；以及与上面每一条失败用例一一对应的修复建议。价格沿用渗透测试服务的分档——收银台测试作为 Focused、Standard 或 Continuous 项目的一部分来定范围，而不是单独售卖的产品，单一目标的 Focused 项目起价 €2,499。

局限

这份矩阵不覆盖游戏引擎的随机数公平性（那是认证与审计的职能，不是渗透测试的），也不能替代牌照已经要求的 KYC/AML 审计——渗透测试验证的是你的技术控制是否执行了你的政策，而不是政策本身是否让牌照方满意，具体请以牌照条款为准。本文也不包含任何利用载荷或复现命令；那些只出现在 ROE 约束下交付的签字报告里，从不出现在公开内容中。

签字前要核对什么

要求供应商在工作说明书里把收银台、红利引擎和后台特权操作作为范围内的资产单独命名，而不是并入“Web 应用测试”；再问他们打算覆盖上面五大类中的哪几类。只要有一类答得含糊，这个范围就还不算是收银台测试。

下一步

把你的平台结构和支付通道列表发到联系表单，我们在你签任何东西之前，先把它对照这份矩阵逐条标出来。渗透测试服务页有分档与范围说明，联系我们即可获取固定报价。

延伸阅读

• 漏洞评估与渗透测试的区别——还没决定买扫描还是买人工测试，先看这篇。
• 渗透测试报价单必须写清的几件事——这份用例矩阵所在的整个项目范围、ROE 与分档。
• 给加密货币交易所定渗透测试范围——同样的方法用在另一类会动钱的平台上。
• English original: Casino cashier security testing: the test-case matrix