接口逆向这件事做Web安全研究的人早晚都会碰到。你抓包看到一个加密参数比如sign、token每次请求都在变盯着那一串动态Token无从下手第一反应往往是到处翻JS文件翻半天找到个混淆得妈都不认识的函数然后就没有然后了。这篇文章我想把动态Token和加密参数逆向的完整链路拆开讲清楚。从最基础的为什么要动态到抓包定位、算法识别、动态调试、脚本复现再到最后怎么从防御视角看这套体系一次说透。适合刚接触接口安全测试的初学者也适合做过一些逆向但总在某个环节卡壳的同行。内容偏实操我会尽量把每一步背后的判断逻辑也写出来毕竟很多时候你缺的不是工具而是下一步该干嘛的决策依据。1. 动态Token与加密参数的本质先说清它们在防什么1.1 所谓的动态Token到底是什么简单说动态Token就是一个每次请求都会变化、无法静态固定的凭证字段。它在接口层面通常长这样POST /api/order/query X-Token: 9f2c1a8e5b7d4f3a7c8e9b0a1d2c3f4e X-Sign: 6a1b2c3d4e5f60718293a4b5c6d7e8f9同一个接口你刷新页面再点一次这两个值就变了。变化可能是随机的也可能是基于时间戳、随机种子、会话状态算出来的。那它到底在防谁大多数场景下防的并不是真正意义上的攻击者而是三类人爬虫脚本、自动化工序、以及绕过前端校验直接调接口的人。你想想如果没有动态Token攻击者只要在BURP里把参数复制一遍就能无限重放接口等于裸奔。动态Token至少让直接复制请求这条路断了逼着你先去还原它的生成逻辑。1.2 加密参数与Token的分工逻辑这里有个常见的误区把Token和签名混为一谈。其实它们是两件事经常组合出现。Token解决的是你是谁、这次请求是否新鲜的问题。它通常由服务端下发一个种子比如登录后返回的随机串前端拿着这个种子再做二次加工最终变成请求里那一串东西。服务端收到请求后会校验Token的新鲜度和合法性不让旧的、超时的请求通过。加密参数一般叫sign或signature解决的是参数有没有被篡改的问题。它的典型逻辑是把请求体里的业务参数按一定规则排序、拼接加上一个密钥或盐跑一遍散列算法MD5、SHA-256或对称加密AES、DES产生一个签名串。服务端用同一套逻辑算一遍比对一致才认为数据可信。大多数实际项目里动态Token和签名是叠加的。Token管这次请求是否有效签名管请求里的数据是否被改过两种组合起来直接构造请求的成本就高了一大截。1.3 适合谁来学、学到什么程度这类技术学的不是破解本身而是一种分析思路。对于安全测试人员来说会逆向Token和签名意味着你能评价接口是否存在重放风险、防篡改能力是否合格。对于前端或后端开发来说理解逆向原理能帮你意识到自己的签名算法弱点在哪、混淆方案为什么挡不住真正的分析。我要把技术细节讲出来但你也得记住一件事所有逆向分析仅限于你自己拥有或获得明确授权的目标。这个边界不是套话是必须遵守的职业红线。后面所有的实战演示都会基于这个前提。2. 准备工作工具、环境与合法边界2.1 授权确认先回答这三个问题动手之前先花一分钟确认边界。我自己的习惯是问三个问题这个目标网站、App、接口是不是我拥有权限进行安全测试的是否签订了测试授权书或明确了测试范围会不会对生产环境造成影响测试流量会不会触发大规模封禁如果三个问题里有一个不确定那就别碰。宁可多做点书面沟通也不要用技术中性来给自己的越界找理由。这一步不是废话它决定了你后续所有的分析是安全研究还是非法侵入性质完全不同。2.2 工具清单与用途说明逆向动态Token不需要什么高精尖工具核心就四类工具类别代表工具干什么用代理抓包Fiddler、Charles、Burp Suite、Whistle截获请求、观察Token变化、修改重放浏览器开发者工具Chrome DevTools、Firefox DevTools断点调试JS、查看调用栈、定位逻辑脚本复现Python、Node.js还原算法、批量验证、自动化生成Token逆向辅助各类反混淆插件、Source Map解析工具处理压缩混淆后的前端代码其实抓包工具一个就够用了其余都是辅助。我个人的经验是抓包工具的选择不重要重要的是你能不能看懂请求里的每一个字段。很多人在第一步就卡住了不是因为工具不行而是因为不知道哪些字段值得深挖。2.3 环境准备与初始信息收集一个干净的Firefox或Chrome无痕环境配好代理关掉浏览器自带的缓存手机模拟器或者真机配置代理如果目标是App。然后开始收集目标接口的基础信息接口地址、请求方法GET/POST/JSON等请求头有哪些自定义字段哪些参数是固定的哪些是动态的响应的状态码和返回结构初始信息收集做得越细后面定位Token生成逻辑就越快。我会在纸上或笔记里画一个简单的表把每个参数标出来固定/动态、出现位置、可能的作用。这一步很像医生问诊哪儿疼都没搞清楚之前别急着开药。3. 动态Token定位流程从抓包到JS溯源3.1 第一步观察Token的变化规律拿到请求包之后不要急着去翻JS。先做一件事连续刷新页面、重新提交几次请求对比Token的变化。这里有个实用的小技巧——把两次请求里的Token差分一下如果Token长度固定比如32位、64位且变化无序大概率是某种散列结果或随机串。如果Token的变化与时间相关比如一小时内前缀相同大概率加入了时间因子。如果Token和Cookie或某个响应头字段同步变化大概率是服务端下发的种子值。我给过一个类比Token变化的规律就像别人家门上的密码锁你先按几次按钮听声音判断是电子锁还是机械锁比直接拆锁的效率高得多。抓包之后先观察、再动手能节省大量时间。3.2 第二步全局搜索与关键字定位所谓定位就是在前端代码里找到生成Token和加密参数的那个函数。最常见的方法是全局搜索。打开浏览器开发者工具切到Sources面板然后按CtrlShiftF全局搜索关键字。搜什么我一般按优先级从高到低搜请求头里自定义字段的名字比如X-Token、X-Sign、Authorization接口URL中的路径关键字比如order/query常见加密相关关键词比如sign、token、encrypt、md5、sha、aes、timestamp、nonce搜到之后逐个看搜索结果找到最接近生成参数的那一段代码。这里有个经验判断真正生成签名的函数一般不会直接在接口调用处写死而是被封装成某个方法比如buildSign()、getToken()、encryptData()。你搜到的那些大面积命中的地方往往是引用点不是定义处。3.3 第三步断点调试还原调用链找到候选函数之后下一步就是断点。在可疑函数的第一行打上断点触发一次请求代码会在断点处停下来。这时就该看Call Stack调用栈从下往上还原是谁调用了这个函数调用前传入了什么参数实际调试过程中的一个重要经验是先看函数入参再读函数体逻辑最后看返回值。顺序别搞反。很多人在函数体里绕了半天百思不解其实他连入参都没看清楚。断点停下来第一件事就是瞄一眼Scope面板里的参数值。举个例子假设你定位到一个函数叫createToken(tokenSeed)入参tokenSeed是服务端登录时下发的一个值。那你已经摸清一大半逻辑了——动态Token不是纯前端生成的而是服务端种子 前端加工的产物。这时候你要继续往下研究的就不是Token本身而是服务端这个种子是怎么下发、何时刷新的。3.4 分清防重放与防篡改的目标差异做逆向分析时我经常提醒自己和同伴时刻问一个问题——我逆的这个东西它真正的防御目的是什么如果它是防重放的Token那核心在于时效性和一次有效性你关心的是怎么让新请求通过校验。 如果它是防篡改的Sign那核心在于算法和密钥你关心的是怎么让改过的参数也能生成正确的签名。这两个目标的分析路径完全不同。防篡改的签名你可能会花大部分时间研究算法和密钥管理防重放的Token你可能只需要关心怎么把对应的随机数或时间戳拿到。带着这个判断进入下一步分析路线会清晰很多。动态Token的定位其实就是一个抓包观察 → 全局搜索 → 断点调试 → 确认生成链的循环。大部分项目在这一步就能出结果偶尔遇到混淆严重的JS才需要上更进阶的反混淆手段这个我在后面第6节再具体讲。4. 加密参数的算法识别与还原思路4.1 通过特征快速判断加密算法签名参数还原之前先判断算法类型。这一步看着简单但很多人栽在看到一串十六进制就说是MD5这种粗心上。常见算法特征可以整理成一张速查表算法输出长度特征表现MD532位十六进制32位全是a-f,0-9无特殊符号SHA-140位十六进制40位十六进制串SHA-25664位十六进制64位十六进制串Base64不定长4的倍数末尾常带号字符含大小写字母、数字、、/AES按块加密不定长解密需要密钥和IV特征不明显得从代码找RSA不定长输出模长固定通常几十到几百字符特征由公钥决定HMAC系列与所选散列一致带密钥的散列光看输出和MD5/SHA没区别要注意的是光看输出长度只能做排除法不能确认真实算法。真正可靠的判断方法是回代码里找实现。比如看到md5()函数名、CryptoJS.enc.Utf8.parse(...)这类调用基本就实锤了。4.2 从函数入口还原生成逻辑一旦确定了算法就要还原完整的生成逻辑。我给自己定的步骤是找到生成函数后把入参列出来。把函数内部涉及字符串拼接、编码转换、密钥加载的部分统统标记。按执行顺序梳理成一串伪代码。用脚本语言复现。以最常见的参数拼接签名为例伪代码通常长这样def generate_sign(params, secret_key): # 1. 过滤空值和签名字段 filtered {k: v for k, v in params.items() if k ! sign and v ! } # 2. 按key排序 sorted_keys sorted(filtered.keys()) # 3. 拼接成 k1v1k2v2 格式 sorted_str .join([f{k}{filtered[k]} for k in sorted_keys]) # 4. 拼接密钥 raw_string sorted_str key secret_key # 5. 计算MD5并转大写 sign hashlib.md5(raw_string.encode(utf-8)).hexdigest().upper() return sign这段伪代码不是从某个特定项目里抄的但它概括了市面上至少一半接口签名算法的骨架。抓到逻辑之后的思路是按这个骨架代入目标参数算一遍和抓包里的sign对比一致就说明还原成功。4.3 动态调试在代码里找到活的密钥密钥盐是签名算法的核心。有的项目把密钥写在代码常量里这种是最好处理的有的项目密钥由服务端下发存在内存或Cookie里还有的密钥是通过另一个接口动态获取的。寻找密钥我的经验是按这个顺序排查函数内是否有硬编码字符串或复制粘贴的常量。函数是否访问了某个全局变量、配置对象或运行环境的window属性。调用栈上层的入参里是否出现了一个看起来不像业务数据的字符串。动态调试时别忘了用条件断点。比如你怀疑某个变量里存着密钥但又不想每次都被断点打断就可以在Sources面板里写条件让代码满足特定条件时才停下来。这个技巧在处理高频请求的接口时特别有用让你不用一遍遍手动播放流程。4.4 别忘了防调试与混淆是分析的一部分现代前端几乎没有不混淆的代码。遇到混淆代码常规应对是两个思路一个是硬啃把混淆JS拿下来格式化配合变量名重命名工具慢慢看。遇到压缩成一大行的代码先交给格式化插件展开再分段定位。另一个是绕道不读混淆后的逻辑而是直接让代码自己告诉我们答案。比如在生成签名的函数处打断点查看实际运行时的入参和返回值再想办法把这段逻辑摘出来复用到自己的脚本里。绕道法其实是绑着调试器往下走混淆能藏逻辑但藏不住运行时的数据和函数行为。只要断点断得住调用顺序、参数列表、返回值都能直接观察到根本不需要读懂每一行混淆代码。这也是很多实战场景下效率最高的路径。关于加密参数的识别和还原核心就一句话先看结构再找算法复现逻辑验证相等。你要是卡住了多半是前面的定位问题没解决回到第3节重新摸排一遍比硬在算法层面对抗混淆要实际得多。5. 实战案例一个模拟订单查询接口的Token逆向记录接下来用一个虚构的模拟项目走一遍全流程。为了避开任何敏感内容我做了脱敏处理接口路径、字段名都用代号替代但分析方法完全一致。5.1 环境与目标描述模拟项目X是一个带管理员后台的订单管理系统前端是一个标准单页应用接口走HTTPS。假设我是项目组的开发人员同时也是这次安全评估的负责人目标是自测订单查询接口是否存在重放和篡改风险。接口信息POST /api/order/query Content-Type: application/json { orderId: 202501010001, pageNo: 1, pageSize: 10 } 响应 { code: 0, data: {...}, msg: success }请求头里有几个自定义字段X-Token: 3f9a8b1c... X-Sign: d5c7b3... X-Timestamp: 17356896005.2 抓包观察与特征判断先用代理抓了几个请求发现X-Timestamp是标准的Unix时间戳每次请求都会变X-Token是32位十六进制串变化规律和X-Timestamp不完全一致初步怀疑是时间戳某种随机种子X-Sign也是32位十六进制对同一参数请求体响应的X-Sign相同参数一变就变符合防篡改签名的特征。这里就体现了我前面说的分工判断X-Token负责新鲜度X-Sign负责完整性。两个参数都要逆向但优先级我先处理X-Sign因为它更直接关系到接口能否被伪造请求攻击。5.3 全局搜索与断点定位打开Chrome DevTools全局搜索X-Sign命中了三个文件。前两个是构建工具生成的公共代码不用管第三个文件是业务代码里面有这样一段function buildSign(params, secret) { var keys Object.keys(params).sort(); var str ; for (var i 0; i keys.length; i) { if (params[keys[i]] ! params[keys[i]] ! null) { str keys[i] params[keys[i]] ; } } str key secret; return md5(str).toUpperCase(); }这里的secret是从哪来的再往上看发现它来自一个全局对象var AppConfig { secret: simulate-secret-key-for-demo, tokenSeed: null };前后端是同一团队在维护签名的密钥就写在前端配置里这明显是个典型的安全弱点。项目的设计目的是做内部分析演练所以这个缺陷是故意保留的。5.4 还原Token生成流程X-Token的定位稍微绕一些。在Sources面板里搜X-Token发现它在请求拦截器里被赋值。继续追踪代码找到Token生成的逻辑function generateToken() { if (!AppConfig.tokenSeed) { AppConfig.tokenSeed getTokenSeed(); // 调用接口拉取种子 } var timestamp Math.floor(Date.now() / 1000); return md5(AppConfig.tokenSeed : timestamp); }看明白了吗Token MD5服务端下发的种子 冒号 当前时间戳。每次请求时间戳都在变所以Token也一直在变。而那个getTokenSeed()会先检查内存里有没有没有就向/api/auth/seed发请求拿一次种子然后存在全局变量里反复使用。所以完整的Token生成链是前端启动时调用/api/auth/seed拿到随机种子。令牌生成时取当前时间戳。种子 冒号 时间戳拼起来做MD5。5.5 用Python脚本复现完整流程逆向到这里其实已经可以写脚本验证了。我用Python写了个简化版复现import hashlib import math import time import requests def md5_upper(text): return hashlib.md5(text.encode(utf-8)).hexdigest().upper() def get_seed(session): 1. 拉取Token种子 r session.get(https://target.example/api/auth/seed) return r.json()[data][seed] def generate_token(seed, timestamp): 2. 生成动态Token raw f{seed}:{timestamp} return md5_upper(raw) def build_sign(params, secret): 3. 生成签名 keys sorted(params.keys()) parts [] for k in keys: v params[k] if v ! and v is not None: parts.append(f{k}{v}) raw .join(parts) key secret return md5_upper(raw) # 实际操作 s requests.Session() seed get_seed(s) secret simulate-secret-key-for-demo timestamp int(time.time()) token generate_token(seed, timestamp) payload { orderId: 202501010001, pageNo: 1, pageSize: 10, } sign build_sign(payload, secret) headers { X-Token: token, X-Sign: sign, X-Timestamp: str(timestamp), Content-Type: application/json, } resp s.post(https://target.example/api/order/query, jsonpayload, headersheaders) print(resp.status_code) print(resp.json())脚本跑下来请求正常通过返回数据和前端一致。这证明X-Sign和X-Token两套动态参数都能被完整还原接口的防篡改与防重放保护实际上等于不存在。5.6 案例复盘与风险结论这个案例暴露了三个问题密钥直接写在前端配置里等于把门锁钥匙挂在门框上。Token虽然动态化但种子只在登录时拉取一次时效性没有做毫秒级控制重放窗口很长。服务端只验证签名一致性没有验证业务参数是否被恶意修改后的语义合理性。到这里逆向的全链路已经闭环抓包→定位→还原→脚本复现→风险确认。整个过程没有绕过任何登录权限模拟项目本身就是授权评估目标所以这套分析是合规的安全自测。6. 常见问题与排查技巧实录6.1 搜索不到关键字怎么办全局搜索不到X-Sign、X-Token这类字段名时别急着怀疑人生。常见原因有两个一个原因是字段名在源码里是拼接出来的。比如代码写的是X- Sign搜索一个完整字符串自然搜不到。另一个原因是请求头字段在代码里用的是变量名而不是字符串字面量。比如headers[X-Token] getToken()里的X-Token是有字符串字面量的但如果代码经过混淆属性被转成了h[K%d]就没法直接搜了。此时换个思路回到调用栈。在Network面板里找到请求点发起者(Initiator)那一列能直接看到栈顶的调用函数和对应行号。沿着调用栈往回走比漫无目的地搜索要精准得多。6.2 断点被反调试逻辑干扰有些前端页面会做反调试比如无限debugger或者检测DevTools是否打开。遇到这种情况常规办法是禁用断点Deactivate breakpoints或条件断点避开那些无意义的debugger语句。使用本地替换在Sources面板里修改掉反调试代码。直接做成整页静态副本在副本里恢复原文件再配合代理工具做响应替换。这个操作属于安全测试中常见的评估手段只对授权目标使用我更建议从分析思路上理解它而不是变成模板化的绕过技巧。核心原则始终是合法性优先。6.3 时间戳校验严格脚本重放总是失败如果Token里绑定了严格时间窗而你的脚本因为网络延迟等原因生成Token后超过几秒才提交服务端就会拒绝。解决办法脚本里动态计算时间戳不要手动写死。把生成Token和发起请求两步之间的网络开销降到最低。如果请求前有其他耗时步骤把Token生成放到最后一步。我见过不少人在脚本里写死一个时间戳然后反复调试加签名逻辑最后发现是这个问题白白浪费了一两个小时。这里提醒直接给到时间戳一定要实时动态取别手动写死。6.4 响应变化但签名算法不变验证失败签名验证失败最常见的原因不是算法错了而是拼接顺序不对。很多签名算法要求过滤空值、排序、并从请求头里额外取几个字段拼进去比如Token、时间戳你少拼一个字段结果就不同。排查方法也很机械把目标代码在断点处停住看一眼字符串拼接后的实际值拿这个值手动算一遍MD5跟签名比对。如果一致说明算法还原没问题是拼接规则没抄全如果不一致说明密钥或者算法实现还有出入继续回到断点往下看。6.5 从实战中总结的几条废坑清单这些是我反复踩过之后沉淀下来的写在这里算是给同行递个火先确认接口是GET还是POST参数在URL里还是body里。签名拼接用的参数字段集合完全不同。不要忽略请求头里的参与字段。很多签名算法把时间戳、随机数、Token也拼进签名原串少一个就验证失败。不要忽略空值的处理方式。有的算法过滤空值有的不过滤还有的入空字符串和null处理不一样这些细节直接决定结果。拿到混淆代码别急着读全部。先打断点看入参和返回值效率高得多。验证时一定用最新的抓包数据。不要用几条老请求里的Token和签名反复试时间窗过了必挂。7. 换个视角从逆向回到防御让Token真正动起来逆向做完我最关心的反而已经不是能不能还原了而是作为开发或者架构师怎么让这套体系更难被还原。毕竟安全研究的目的从来不是击穿它而是站在攻击者视角理解弱点再反哺防御。7.1 密钥别留在前端能后移就后移Token和签名的核心是密钥。如果密钥放在前端JS里那无论怎么混淆最终都会被耐心的人找到。最有效的方案是把关键的签名计算挪到服务端前端只做数据转发。举个例子前端不直接计算签名而是把业务参数发给一个后端签名服务后端验证会话有效性后返回计算好的签名和Token。前端只是借用一下既保证密钥不下发也让逆向的收益降到极低。如果一定要在客户端计算密钥至少要动态下发并且下发的接口要带明文的接口用途绑定而不是一个裸的常量。7.2 动态Token要动态在服务端实时校验很多系统的Token是动态生成的但校验时只验证签名格式不管时效性。这等于门锁上贴了个指纹贴纸谁都能按一下。服务端必须校验三件事Token是否在有效时间窗内、Token是否已被使用过一次性校验、Token和当前会话是否绑定。更严格的体系可以加入随机nonce、设备指纹或行为风控层层叠加。7.3 防篡改别只防一时要连同业务语义一起防签名只能证明参数没被改动不能证明参数语义上是合理的。真正有效的防御还要结合服务端逻辑比如订单金额改动时签名的确验得过去但如果后端不去校验订单总价和明细的加总关系还是会出问题。所以签名之外要加业务规则校验这是很多系统最容易忽略的一层。7.4 让逆向成本成倍增加的三个组合手段单纯混淆挡不住真正目标明确的逆向者但配合多个手段能让逆向成本变得极高JavaScript代码混淆变量名重命名、控制流平坦化。反调试机制检测开发者工具、阻止右键菜单、无限debugger。服务端强校验动态密钥、加密算法、密钥定期轮换加上请求时序、来源、行为特征校验。混淆可以把一眼看明白变成要花半天反调试把自动分析变成手工操作服务端强校验则让即便找出算法也无法长期复用。三者在同一时间组合使用比任何一个单点强得多。7.5 别忘了计算机是确定性的没有绝对不可逆写到这里我得说句实话只要计算发生在客户端逻辑就总有办法被还原。混淆能增加难度但无法消灭逆向。你选择的加密方案是否可靠本质上是逆向成本和攻击者耐心之间的赛跑。所以真正稳定的防御思路不是让Token和签名不可逆而是让即便被逆出来了它的破坏力也非常有限。比如缩短有效期、绑定设备、加上频率限制、配合风控系统等。一个只能重放一次、且对业务数据毫无影响的一次性凭证就算被完整分析出来也折腾不出什么水花。我个人做这部分工作的时间越久越觉得手册写不清楚的是那个度既要有能力做深度的逆向分析又得有足够的自我约束去守住合法边界。技术本身是中性的但用在哪里、为了什么目的一定会决定它的性质。希望这篇内容能帮你在接口安全评估这条路上走得稳一点也希望你每次动工具之前心里都有那杆秤。