服务端上行消息检查规范 - kyohwang/games GitHub Wiki

问题：中华项目测试期间，遇到玩家通过截包改包的方式对服务器进行试探攻击，由于逻辑不严谨，出现了以下几种问题：

1. 英雄招募（宝物招募）在判断上行消息的招募类型时，类型是否有效的判断是与对应条件是否满足的判断一起进行的，即如果玩家修改类型为取值范围之外的值时就跳过了条件判断，在扣除钻石时抛出异常，但仍然执行了招募逻辑。

2. 玩家在商城购买不限数量的物品，程序逻辑对购买数量没有判断上限，玩家修改购买数量，将其值改的非常大，在计算购买所需的消耗时进行了大量的Reward的copy操作，导致主线程卡死，程序无法响应。

3. 同2情形，当玩家将购买数量改的特别大时，再乘以购买的价格，最后的消耗将会超过int上限，变为负值，进而跳过了消耗是否满足的判断，执行了加物品的逻辑。

4. 背包物品出售功能，程序没有判断出售数量的下限，玩家修改出售数量为负数，可跳过自身物品数量是否满足的判断，当出售的总价（数量*单价）超过int下限时将会变成正数，形成了刷金币的问题。

5. 同4情形，程序扣除物品逻辑没有对数量非负进行判断，当扣除的数量为负数时，扣除逻辑其实变为了增加，形成刷物品的问题。

针对以上问题，现对服务端上行消息的检查整理以下规范，供大家参考：

1. 对于type型参数：判断所有可取的值范围，不要与条件是否满足一起判断，建议使用枚举，通过pb去做限制。

2. 对于数值型参数：

   2.1. 判断数值上下限（重要，必须）

   2.2. 判断对应数据是否存在，如武将索引是否越界，索引对应武将是否存在

3. 对于id型参数：判断id有效性（是否配表数据，是否自身相关数据）

4. 对于集合参数：

   4.1. 基础类型集合List转Set（重要，必须）

   4.2. 集合长度上下限判断（重要，必须）

   4.2. 对象类型集合酌情考虑是否要判断去重（本身修改难度较大）

另外就相关问题提出以下几点编码及检查原则，供大家参考：

原则1：对于可获得奖励的功能一定要对上行消息参数的所有可能进行排查。

原则2：考虑参数默认值是否会被使用，默认值是否正确。

原则3：对于每个参数可能参与的运算进行检查，判断是否可能因为异常导致运算量过大。

原则4：逻辑编写时先扣消耗，再加获得。