JMeter中x-appiyo-key与x-appiyo-hash头的作用及加密请求体处理

• 两个字段的设计用途决定了其不具备直接解密的能力：
  • x-appiyo-hash 属于单向校验类字段，通常是将明文请求体叠加约定盐值，通过SHA256、HMAC等单向哈希算法生成的完整性校验值，本身不存在逆向还原明文的能力
  • x-appiyo-key 属于加密密钥的包装传输字段，常规实现是前端生成随机对称加密密钥用于加密请求体，再通过服务端预置的非对称公钥对该对称密钥加密后填入该Header；由于没有对应非对称私钥，无法从该字段中提取出可用于解密的真实密钥
• 直接尝试对录制得到的加密请求体搭配两个Header字段解密，只会得到无效乱码，无法拿到结构化的明文请求内容。

• 逆向定位前端完整加密逻辑
  • 在前端页面触发对应接口请求的位置打调试断点，定位到生成加密请求体、计算两个x-appiyo系列Header值的函数代码，梳理清楚完整的链路规则：包括对称加密算法类型、密钥长度、偏移量生成规则、哈希计算的盐值、非对称加密的公钥等核心参数
  • 常规实现链路为：前端生成随机对称密钥→加密结构化JSON格式的原始请求体→用非对称公钥加密对称密钥生成x-appiyo-key→基于加密后的请求体、对称密钥、约定盐值计算哈希值生成x-appiyo-hash
• 在JMeter中复刻完整加密链路实现动态生成请求
  • 跳过“解密已有加密请求体”的思路，直接在JMeter中通过前置处理器（推荐用Groovy脚本）复刻前端的加密逻辑：
    • 接入CSV Data Set Config组件读取批量测试的参数值，拼接生成结构化的原始明文请求体
    • 按梳理好的规则动态生成随机对称密钥，加密明文请求体作为实际发送的请求Body
    • 动态计算x-appiyo-hash、x-appiyo-key值，自动填入请求的Header管理器对应位置
• 校验脚本一致性
  • 对比脚本动态生成的加密请求体、两个Header值和录制得到的真实请求内容，确保逐字段匹配后，再启动批量压测

• 不要硬编码录制得到的固定加密请求体、固定Header值用于参数化测试：更换CSV中的参数值后，硬编码的旧加密内容会触发服务端的完整性校验失败，直接返回错误
• 部分场景下x-appiyo-key存在会话时效性，脚本中需要处理该值和当前会话Token的动态关联，避免因Key过期触发请求拦截
• 如果前端JS做了混淆处理，优先在加密函数的入参位置打断点，直接抓取函数接收到的原始明文请求体作为基准，比对脚本生成的明文内容，减少逆向调试成本

内容的提问来源于stack exchange，提问作者Vaibhav