post_encrypted_audit.md 4.1 KB

登录后接口是否「POST + 入参出参密文 + 时间戳与签名」排查

结论概览

不是全部这样开发。目前只有心跳、密钥同步(keys/sync)、用户信息(user/profile) 以及登录/注册/充值/解绑/改密等 安全端点 符合:POST、入参密文、出参密文、校验时间戳与签名。
选品相关 4 个接口 和 密钥交换 keys/hmac 仍为明文请求(GET 或 POST JSON),无密文、无时间戳与签名校验。


符合「POST + 密文 + 时间戳与签名」的接口

接口 调用方式 方法 入参 出参 时间戳/签名
心跳 invoke('secure_heartbeat') → Rust secure_heartbeat_call_inner POST /api/v1/heartbeat encrypted_params + aes_key + timestamp + nonce + signature encrypted_data + response_signature ✓ 请求签名、响应验签
密钥同步 心跳任务内 secure_keys_sync_and_store POST /api/v1/keys/sync 同上(安全端点) 密文 ✓
用户信息 invoke('get_user_profile') → Rust secure_get_user_profile_call POST /api/v1/user/profile 同上 密文 ✓
登录/注册/充值/解绑/改密 invoke('secure_user_*') POST 对应 /api/v1/auth/* 同上 密文 ✓

上述均在 Rust 侧 构造 AES+RSA 加密体、timestamp、nonce、signature,POST 到后端;响应为 encrypted_data,并做 response_signature 校验后解密再返回前端。


不符合的接口(明文)

接口 调用方式 方法 入参 出参 说明
BUFF 筛选项 前端 fetch(url) GET /api/v1/buff/filter-options?game=&session_id=&machine_code= URL 查询参数明文 明文 JSON 无密文、无时间戳、无签名
BUFF 商品属性 前端 fetch(url) GET /api/v1/buff/goods-attr-list?goods_ids=&session_id=&machine_code= URL 查询参数明文 明文 JSON 同上
选品配置-获取 前端 fetch(url) GET /api/v1/buff/selection-config?session_id=&machine_code= URL 查询参数明文 明文 JSON 同上
选品配置-保存 前端 fetch(url) POST /api/v1/buff/selection-config body 明文 JSON(session_id, machine_code, config_json 等) 明文 JSON 无密文、无时间戳、无签名
选品开始 若由前端/ Rust 调用 POST /api/v1/buff/selection-start body 明文 JSON 明文 同上
HMAC 密钥同步 invoke('sync_hmac_key') → Rust fetch_hmac_key_from_server POST /api/v1/keys/hmac body 明文 JSON { username, machine_code } 明文 JSON 无密文、无时间戳、无签名

选品 4 个接口均在 前端 Vue 的 secureApiClient.ts 里用 fetch 直接请求,未经过 Rust 加密层。
keys/hmac 在 Rust 里用 reqwest::post().json(&json!({...})) 发明文 JSON,响应也是明文。


若需统一为「POST + 密文 + 时间戳与签名」的改造方向

  1. 选品相关(filter-options / goods-attr-list / selection-config / selection-start)

    • 后端:为这 4 个能力提供安全端点(与现有 /api/v1/heartbeat 一致):接收 POST,body 为 encrypted_params + aes_key + timestamp + nonce + signature,响应为 encrypted_data + response_signature。
    • 客户端:不再用前端 fetch;改为通过 Tauri 命令(Rust)调用,在 Rust 中复用与心跳相同的一套:组请求 → AES+RSA 加密 → 带时间戳与签名 POST → 验签并解密响应 → 将结果返回给前端。
  2. keys/hmac

    • 后端:将 /api/v1/keys/hmac 改为安全端点(或新增一个安全端点),入参出参密文、校验时间戳与签名。
    • 客户端:Rust 侧改为与 heartbeat/keys/sync 相同的加密请求与响应解密流程,不再使用明文 JSON。
  3. 公告
    当前为 GET 明文,若业务上允许公告公开,可保持现状;若也要纳入统一安全规范,需改为 POST 安全端点并由 Rust 调用。


文档日期:2026-03-01