ThinkPHP如何做接口签名验证_ThinkPHPAPI安全校验详解【详解】

说到 ThinkPHP 的接口签名验证，很多人第一反应是找个现成的中间件装上。但关键不在于套方案，而是吃透那个核心逻辑：服务端必须能原样复现出客户端算出来的 sign。参数、密钥、排序规则、哈希方式，但凡有一个地方没对齐，验证就过不去——这才是最让人头疼的。

签名参数必须全局统一排序并过滤空值

ThinkPHP 默认接收参数时，键的顺序是不确定的——input() 或 $request->param() 返回的是关联数组，但顺序取决于 PHP 版本和运行时环境。而签名计算要求参数按 key 的字典序升序排列拼接。如果不做显式排序，本地测着好像没问题，一上线可能就因为 PHP 版本或 SAPI 的差异直接挂掉。

几个关键点：

• 必须用 ksort() 对参数数组排序，并且只让非空、非 null、非 '' 的值参与签名计算。手动检查时，if ($val !== '' && $val !== null && $val !== []) 是稳妥的做法，光靠 filter_var() 是不够的。
• 注意把 sign 本身、时间戳（timestamp）、随机串（nonce）这些字段排除在外，它们虽然随请求传过来，但不参与签名计算。
• 常见坑：有人把 $_GET 和 $_POST 分开处理，结果 URL 查询参数被忽略了；或者用 http_build_query() 但没指定 PHP_QUERY_RFC3986，导致空格被编码成 + 而不是 %20，服务端和客户端对不上。

think\facade\Request 获取参数时要禁用自动过滤

ThinkPHP 5.1 及以上版本，默认会对输入参数做 htmlspecialchars 转义（受 default_filter 配置影响）。如果客户端原始参数里含有 &、=、+ 这类字符，服务端拿到手的已经是转义过的版本，签名计算自然就错了。

正确的做法是：

• 在签名验证阶段，用 $request->param('', '', false)——第三个参数设为 false 可以跳过所有过滤。
• 或者临时在配置中把 default_filter 设为空，但注意只限在签名逻辑内生效，别全局关掉。
• 特别留意：如果请求体是 JSON 格式（Content-Type: application/json），必须用 $request->getInput() 读取原始流，再用 json_decode($raw, true) 解析。依赖 $request->param() 会丢失原始结构，签名基本必败。

签名密钥不能硬编码或写死在配置里

密钥（app_secret）一旦泄露，攻击者就能伪造任意请求。ThinkPHP 没有内置的密钥轮换机制，得自己设计隔离策略。

几点建议：

• 密钥应该放在独立的配置文件里（比如 config/api_sign.php），并且确保 Web 服务器无法直接访问该文件（Nginx 或 Apache 下要禁止 .php 文件在 config 目录下执行）。
• 不同应用或渠道分配不同的密钥。客户端通过请求头 X-App-Key 或参数 app_key 表明身份，服务端根据这个信息查表拿到对应的 app_secret。这样就算某个渠道的密钥泄露，也不会波及全部业务。
• 绝对不要把密钥写在控制器或模型里——哪怕只是临时测试也不行。更别用 md5('your_secret') 这种弱混淆，MD5 本身就是可逆的。

时间戳校验必须严格且带时区容错

签名里通常会带一个 timestamp 参数用于防重放攻击。但 ThinkPHP 默认用 time()（UTC 时间戳），如果客户端设备的时间偏差超过 5 分钟，验证就会失败，用户直接没法用。

处理建议：

• 服务端校验时，用 abs(time() - (int)$params['timestamp']) ，而不是 time() > $params['timestamp'] + 300——后者在客户端时间慢于服务端时会误判。
• 如果是移动端场景，服务端最好返回一个当前标准时间（比如 ISO8601 格式），让客户端自行校准，而不是强求设备时间必须精准。
• 还有一点容易忽略：PHP 的 time() 依赖系统时间。务必保证服务器 NTP 同步（可以用 ntpq -p 检查），否则全站的签名都会跟着漂移。