4、数据校验：服务端权威校验、客户端数据签名、防篡改机制

数据校验这块，说白了就是解决一个问题：你怎么知道客户端发过来的数据是真的？

我见过太多游戏项目，前期图省事，客户端说什么服务器就信什么。结果呢？上线第一天就被外挂刷爆了排行榜。嗯，今天我们就来聊聊怎么把这道防线扎紧。

4.1 服务端权威校验：永远不要相信客户端

这是游戏安全的第一铁律。我个人习惯把它刻在工位上——所有关键逻辑，必须在服务端重新算一遍。

举个例子，玩家购买一把武器，客户端发来请求：

// 客户端发来的请求（不可信）
{
    "playerId": 10001,
    "itemId": "sword_01",
    "price": 100,
    "signature": "abc123..."
}

服务端收到后，不能直接扣100金币就发货。你得做三件事：

  1. 验证玩家身份：这个请求是不是10001本人发的？
  2. 校验价格：这把剑到底卖多少钱？从配置表里查，而不是信客户端说的100。
  3. 检查状态：玩家金币够不够？背包满了没？

核心原则：客户端只能作为「展示层」，所有涉及数值变更、状态修改的操作，服务端必须重新计算一遍。

我在项目中遇到过最典型的案例：某款MMO的装备强化系统，客户端传了强化等级和消耗材料数量。服务端没校验材料是否足够，结果外挂直接传个「消耗0个材料，强化到+15」。嗯，那天的工单量直接爆了。

4.2 客户端数据签名：给数据加把锁

你可能会问：「那客户端发来的数据，我完全不信，是不是就不用签名了？」

不是的。签名的作用是防止数据在传输过程中被篡改。说白了，就是给每个请求盖个章，谁改动了数据，章就碎了。

4.2.1 签名算法怎么选？

我个人推荐用 HMAC-SHA256。为什么？

  • 比MD5安全（MD5已经被破解了，别用了）
  • 比RSA快（服务端扛得住高并发）
  • 带密钥，客户端不知道密钥，伪造不了签名

签名流程大概是这样的：

// 服务端和客户端共享一个密钥（通过安全通道分发）
const SECRET_KEY = "game_secret_key_2024";

// 客户端生成签名
function generateSignature(data, timestamp) {
    // 1. 把所有参数按字典序排序
    // 2. 拼接成字符串
    // 3. 加上时间戳和密钥
    // 4. 计算HMAC-SHA256
    const sortedKeys = Object.keys(data).sort();
    let rawStr = "";
    for (let key of sortedKeys) {
        rawStr += `${key}=${data[key]}&`;
    }
    rawStr += `timestamp=${timestamp}&key=${SECRET_KEY}`;
    
    return CryptoJS.HmacSHA256(rawStr, SECRET_KEY).toString();
}

// 客户端发送请求
const requestData = {
    playerId: 10001,
    itemId: "sword_01",
    price: 100,
    timestamp: Date.now(),
    signature: generateSignature({playerId: 10001, itemId: "sword_01", price: 100}, Date.now())
};

避坑指南：我曾经见过一个项目，签名时没加时间戳。结果外挂把同一个请求重放了几万次，服务器直接被打挂了。记住：签名一定要绑定时间戳和随机数，防止重放攻击。

4.2.2 服务端验签

服务端收到请求后，用同样的算法重新算一遍签名。如果对不上，直接拒绝：

// 服务端验签
function verifySignature(data, signature, timestamp) {
    // 1. 检查时间戳是否在有效期内（比如5分钟内）
    if (Math.abs(Date.now() - timestamp) > 5 * 60 * 1000) {
        return false; // 请求过期
    }
    
    // 2. 重新计算签名
    const expectedSig = generateSignature(data, timestamp);
    
    // 3. 比较签名（用恒定时间比较，防止时序攻击）
    return constantTimeCompare(expectedSig, signature);
}

注意：比较签名时，千万别用普通的字符串比较。要用恒定时间比较函数，否则攻击者可以通过响应时间推断出签名内容。嗯，这个坑我踩过。

4.3 防篡改机制：多层防护网

签名只是第一道防线。真正要防住篡改，得搞一套组合拳。我个人习惯用三层防护：

层级 防护手段 作用
第一层 数据签名 防止传输过程中被篡改
第二层 服务端校验 防止客户端伪造数据
第三层 状态一致性检查 防止逻辑漏洞被利用

4.3.1 状态一致性检查

这个比较高级。你想想看，外挂可能不直接改数值，而是利用游戏逻辑的漏洞。比如：

  • 同时发送两个互相矛盾的请求
  • 在某个状态变更的瞬间发送请求
  • 利用网络延迟制造时间差

怎么防？我分享一个实战经验：给每个玩家维护一个状态版本号。

// 服务端维护
playerState = {
    gold: 1000,
    level: 10,
    version: 5  // 每次状态变更，版本号+1
}

// 客户端请求必须带上当前版本号
request = {
    action: "buy_item",
    itemId: "sword_01",
    clientVersion: 5  // 客户端看到的版本号
}

// 服务端校验
if (request.clientVersion != playerState.version) {
    // 客户端状态已过期，拒绝请求
    return "STATE_MISMATCH";
}

这样做的好处是：外挂如果缓存了旧的状态，发过来的版本号对不上，直接拒绝。我曾经用这个办法堵住了一个利用「背包已满但客户端显示未满」漏洞的外挂。

4.3.2 关键数据加密存储

有些数据，比如玩家的货币数量、道具属性，不能明文存。我建议：

  1. 服务端加密存储：用AES-256加密后写入数据库
  2. 内存中保持加密态：只在需要计算时才解密
  3. 定期校验数据完整性：用哈希值检查有没有被篡改

一句话总结：客户端发来的数据，签名要验、逻辑要重算、状态要核对。这三步走完，大部分外挂就挡在门外了。

4.4 实战中的常见陷阱

最后，我列几个自己踩过的坑，你遇到了可以少走弯路：

  • 签名密钥硬编码在客户端：反编译一下就暴露了。建议用动态下发或白盒加密。
  • 只验签不校验逻辑：签名通过了，但数据本身是伪造的。比如传个「等级=999」。
  • 忽略边界情况：比如数量为负数、价格为0、时间戳为未来时间。这些都要校验。
  • 日志记录不足：被攻击了都不知道从哪进来的。建议记录每次验签失败的原因。

数据校验这件事，说白了就是「信任但验证」——不对，应该是「永远不信任，永远要验证」。你想想看，外挂作者比你更熟悉你的代码，他们每天都在找漏洞。我们能做的，就是把每一道防线都扎扎实实地做好。

嗯，下一章我们聊聊更高级的话题：内存保护与反调试。到时候见。

← 上一章 📖 返回目录 下一章 →