1. 项目概述为什么我们要研究请求签名如果你做过爬虫或者逆向过一些现代Web应用大概率会碰到一个让人头疼的“拦路虎”请求签名。简单来说就是客户端在发送请求前对请求的某些部分如URL、参数、时间戳、设备信息等按照一套只有服务端知道的规则进行计算生成一个看似随机的字符串通常放在x-s、x-t、sign等请求头里然后随请求一起发送。服务端收到后会用同样的规则再算一遍如果对不上直接拒绝请求。这玩意儿最初是为了防止请求被篡改防重放攻击、防参数伪造但现在它已经成了保护后端API、对抗自动化脚本比如爬虫、刷量工具的核心防线之一。小红书XiaoHongShu的x-s参数就是这类机制的典型代表。你会发现直接用requests或urllib这类基础HTTP库去请求小红书的API十有八九会返回406、403或者各种签名错误。网上很多讨论都指向了这一点“纯urllib方式无法工作”必须“改用selenium”或者去逆向它的JavaScript。但用Selenium这类浏览器自动化工具效率低、资源消耗大不适合大规模、高频的数据获取。所以理解并逆向出它的签名算法用纯Python或其他语言实现就成了一个既有挑战性又有实用价值的“硬核”技术活。这不仅仅是写个爬虫更是对现代Web应用安全机制的一次深度剖析。接下来我就以小红书x-s参数为例拆解这套机制的设计思路、实现原理和逆向方法。2. 请求签名机制的核心设计思路要逆向一个签名首先得理解它被设计出来是为了解决什么问题以及通常如何解决。这能帮助我们在逆向时建立正确的“搜索方向”。2.1 签名机制要防御什么签名机制主要对抗以下几种常见攻击或自动化行为重放攻击Replay Attack攻击者截获一个合法的请求然后原封不动地重新发送给服务器。如果服务器没有防护就会重复执行操作比如重复转账、重复点赞。签名机制通常会引入时间戳x-t和随机数nonce确保同一个签名在一段时间内只能使用一次。参数篡改Parameter Tampering攻击者在传输过程中修改请求参数比如把转账金额从10元改成10000元。签名机制会将所有关键参数纳入计算任何篡改都会导致签名校验失败。未授权访问Unauthorized Access试图绕过登录态直接调用需要权限的API。签名机制常会与用户令牌Token或会话Session绑定或者使用设备指纹等作为输入的一部分。自动化脚本/爬虫Automated Scripts/Crawlers这是目前最常见的应用场景。网站通过复杂的、动态变化的签名算法大幅提高自动化工具直接调用API的门槛。因为算法逻辑和密钥通常隐藏在混淆过的前端JavaScript代码中直接模拟请求变得异常困难。2.2 通用签名算法流程一个典型的请求签名生成流程如下理解这个通用模型对逆向具体实现至关重要收集原材料确定哪些数据需要参与签名。常见元素包括请求方法MethodGETPOST等。请求路径Path/api/sns/web/v1/feed 不包括域名和查询字符串有时包括。查询参数Query Parameters需要按特定规则如字母序排序并拼接。请求体Body对于POST请求可能是JSON或FormData。时间戳Timestamp通常为毫秒或秒级时间戳作为x-t头传递。随机字符串Nonce防止重放。固定密钥Secret Key一个只有客户端和服务端知道的字符串是签名的核心机密。其他动态值如设备ID、版本号等。构造待签名字符串将上述原材料按照一个确定的规则拼接成一个长长的字符串。这个规则比如字段顺序、分隔符必须和服务端严格一致。例如methodGETpath/api/xxxparamsa1b2t1234567890进行密码学哈希或加密计算将上一步得到的字符串结合密钥通过某种算法进行计算。哈希算法最常用的是HMAC-SHA256。公式可以理解为sign HMAC-SHA256(secret_key, string_to_sign)。哈希结果是不可逆的。加密算法有时也会使用AES等但相对少见。自定义算法为了增加逆向难度开发者可能会在标准算法前后增加额外的步骤如自定义的编码、位运算、字符串变换等。编码输出将计算得到的二进制结果进行编码通常为Base64或Hex十六进制字符串然后放入x-s这样的请求头中。小红书的x-s以及与之配套的x-t、x-s-common等就是遵循这个范式但具体到“收集哪些原材料”、“按什么顺序拼接”、“使用什么算法及密钥”就是我们需要逆向的具体内容了。3. 逆向分析定位与拆解签名逻辑逆向Web请求签名本质上是在逆向前端JavaScript代码。我们的目标是找到生成x-s的那几行关键代码并理解其逻辑。3.1 前期准备与抓包分析工欲善其事必先利其器。你需要准备好以下工具浏览器开发者工具Chrome DevTools核心工具用于网络抓包、JavaScript调试。抓包工具Charles 或 Fiddler用于拦截和查看HTTPS流量有时比浏览器工具更直观。代码格式化与搜索工具浏览器自带的Pretty Print美化功能以及CtrlShiftF全局搜索。Node.js环境用于在本地模拟执行一些提取出来的JavaScript函数片段。第一步永远是抓包。打开小红书网页版进行一个能触发API请求的操作比如刷新首页、搜索、查看笔记详情。在Network面板中找到一个返回数据是JSON的XHR/Fetch请求重点关注它的请求头Headers。你会发现除了常见的Cookie、User-Agent还有一组以x-开头的自定义头例如x-t: 1715167890123 x-s: 7a8f3b...一长串十六进制字符串x-t看起来是时间戳x-s就是我们的目标签名。记下这个请求的URL、方法、所有参数和请求体。3.2 搜索与定位关键代码由于签名逻辑在前端我们必须在前端代码里找到它。现代Web应用通常代码被压缩和混淆直接阅读很困难。全局搜索关键词在DevTools的Sources面板按CtrlShiftF在整个已加载的代码中搜索x-s、x-t、sign、encrypt、hmac、sha256等关键词。这能快速定位到可能与签名相关的代码区域。XHR/Fetch断点在Network面板找到目标请求右键选择“Replay XHR”会重新发送请求。在此之前在Sources面板的XHR/Fetch Breakpoints里添加一个断点URL包含该API的关键部分。当请求发出时代码执行会暂停此时调用栈Call Stack会显示是哪个函数发起了这个网络请求。顺着调用栈向上回溯很可能就能找到构造请求头、计算签名的函数。Hook关键函数在Console面板可以注入代码来“钩住”标准函数帮助我们定位。例如// 钩住 fetch var originalFetch window.fetch; window.fetch function(...args) { console.log(Fetch called:, args); debugger; // 自动触发断点 return originalFetch.apply(this, args); }; // 钩住 XMLHttpRequest 的 setRequestHeader var originalSetRequestHeader XMLHttpRequest.prototype.setRequestHeader; XMLHttpRequest.prototype.setRequestHeader function(header, value) { if (header.toLowerCase() x-s) { console.log(x-s being set:, value); debugger; } return originalSetRequestHeader.apply(this, [header, value]); };执行这段代码后再进行页面操作当设置x-s头时浏览器会自动断住此时查看调用栈即可。通过以上方法你最终会定位到一个或多个负责生成签名的JavaScript函数。它们可能被命名为一些无意义的字母也可能藏在某个巨大的、混淆过的模块里。3.3 拆解算法逻辑找到函数后接下来的工作是理解它。即使代码被混淆其核心逻辑数据拼接、加密调用通常还是有迹可循的。参数分析看这个函数接收哪些参数。通常会有URL、请求参数、时间戳、某个固定的密钥或密钥的索引等。流程跟踪在函数内部打上断点一步步执行Step Over/Into观察每一步中变量的值。重点关注哪些数据被拼接concat运算符到了一起拼接的顺序和分隔符是什么拼接后的字符串传递给了哪个加密函数是CryptoJS.HmacSHA256还是window.async调用的某个模块或者是btoa、md5等加密函数输出的结果又经过了哪些处理toString(Hex)substrtoUpperCase等提取关键代码一旦理清了逻辑目标就是将这个生成签名的函数以及它依赖的辅助函数、常量特别是密钥从庞大的前端代码中“剥离”出来。你需要将其复制到一个独立的JS文件中并确保它能在Node.js或浏览器控制台独立运行。这个过程可能需要你补全一些它依赖的全局变量或函数。注意很多应用会将密钥或算法的一部分放在服务端前端通过异步接口获取或者使用WebAssembly等更隐蔽的技术。小红书的x-s算法相对复杂且可能不定期更新增加了逆向的难度和时效性。网上有一些历史版本的分析但直接套用很可能已失效。4. 以小红书 x-s 为例的实操模拟由于小红书的签名算法是其核心安全策略具体细节属于商业机密且频繁变动这里我无法提供当前可用的、完整的算法代码。但我可以基于通用原理和常见模式构建一个高度简化的模拟示例来演示从分析到实现的全过程。请注意此示例仅用于教学理解不能用于实际请求小红书API。假设我们通过逆向分析推测出一个简化版的签名流程这很可能与实际不符输入请求方法method 请求路径path 查询参数字典params 时间戳timestamp。步骤一构造待签名字符串将params按key进行字母序排序。将排序后的params转换为key1value1key2value2格式的字符串。如果value是复杂对象可能需要先JSON序列化。将method、path、排序后的参数字符串、timestamp用换行符\n连接。示例GET\n/api/sns/web/v1/feed\ncursor_score0num20\n1715167890123步骤二计算HMAC-SHA256使用一个固定的密钥假设我们从代码中提取出密钥是fixed_secret_key_2024。计算hmac_sha256(secret_key, string_to_sign)。步骤三输出编码将上一步得到的二进制哈希结果转换为十六进制Hex字符串并全部转为小写作为最终的x-s值。根据这个假设的流程我们可以用Python实现一个模拟函数import hmac import hashlib import time import urllib.parse def generate_xiaohongshu_x_s(method, path, params, secret_keyfixed_secret_key_2024): 模拟生成小红书 x-s 签名 (假设版本) :param method: HTTP方法如 GET :param path: 请求路径如 /api/sns/web/v1/feed :param params: 字典请求的查询参数 :param secret_key: 从JS中逆向得到的密钥 :return: (x_t, x_s) 元组 # 1. 生成 x-t (时间戳毫秒) x_t str(int(time.time() * 1000)) # 2. 构造待签名字符串 # 2.1 参数排序并拼接 sorted_params sorted(params.items(), keylambda x: x[0]) # 注意需要对参数值进行URL编码确保特殊字符正确处理 encoded_params .join([f{k}{urllib.parse.quote(str(v), safe)} for k, v in sorted_params]) # 2.2 按假设规则拼接 string_to_sign f{method}\n{path}\n{encoded_params}\n{x_t} print(f[DEBUG] 待签名字符串:\n{string_to_sign}) # 3. 计算 HMAC-SHA256 # 注意密钥和消息都需要转换为 bytes key_bytes secret_key.encode(utf-8) msg_bytes string_to_sign.encode(utf-8) hmac_obj hmac.new(key_bytes, msg_bytes, hashlib.sha256) digest hmac_obj.digest() # 二进制摘要 # 4. 转换为十六进制字符串 (小写) x_s digest.hex() print(f[DEBUG] 生成的 x-s: {x_s}) return x_t, x_s # 模拟一个请求 if __name__ __main__: method GET path /api/sns/web/v1/feed params { cursor_score: 0, num: 20, source: notes_feed } x_t, x_s generate_xiaohongshu_x_s(method, path, params) print(fx-t: {x_t}) print(fx-s: {x_s}) # 理论上这个 x-s 和 x-t 应该能用于构造请求头这个模拟代码展示了核心步骤排序、拼接、哈希、编码。在实际逆向小红书时你需要用真实抓包得到的数据反复调试你从JS中提取出的算法函数确保其输出与真实请求中的x-s完全一致。这个过程可能需要处理更复杂的细节比如请求体JSON如何参与签名是否包含某些固定的请求头如User-Agent密钥是否是动态获取的是否有额外的盐值salt或混淆步骤5. 逆向工程中的常见问题与排查技巧即使思路清晰逆向过程也绝不会一帆风顺。下面是我在多次类似项目中踩过的坑和总结的技巧。5.1 问题一代码混淆严重无法定位现象全局搜索x-s等关键词无结果所有变量名都是abcor等单字母。解决思路寻找入口混淆不会改变网络请求的入口。使用“XHR/Fetch断点”是最可靠的方法。断住后即使调用栈里的函数名是乱的但堆栈顺序是真实的你可以从最顶层的匿名函数开始一步步跟。关注字符串混淆工具通常不会加密所有字符串常量。在代码中搜索/api/sns、hmac、sha256甚至sign的完整单词可能直接定位到关键函数附近。美化与重命名利用DevTools的{}Pretty Print美化代码。虽然变量名改不了但你可以手动在脑海中或纸上给关键函数、变量起别名帮助理解逻辑流。5.2 问题二算法依赖浏览器环境或闭包变量现象把函数代码单独复制到Node.js中运行报错xxx is not defined或者结果不对。解决思路补全依赖在浏览器中在签名函数执行前断点查看Scope面板中的Closure和Global作用域找到那些未定义变量实际的值是什么。它们可能是全局函数、其他模块导出的对象或者是外层函数定义的常量。将这些值硬编码到你的独立JS文件中。模拟环境如果依赖window、document、navigator等浏览器特有对象需要在Node.js中用jsdom库模拟一个简易浏览器环境。直接使用浏览器上下文最稳妥的办法是不剥离代码而是通过Chrome DevTools Protocol (CDP)或Puppeteer/Playwright工具让无头浏览器执行页面脚本然后通过exposeFunction等方式将生成签名的函数暴露给外部Python调用。这相当于一个“半自动化”方案比纯Selenium轻量比纯逆向稳定。5.3 问题三签名总是无效或过期现象自己实现的签名算法生成的x-s和服务端校验不通过或者短时间内就失效。排查清单时间戳同步检查你的x-t时间戳是否与服务器时间有较大偏差。可以使用网络时间协议NTP同步本地时间或者更简单地直接从某个API响应头中获取服务器时间。参数编码这是最常见的错误。URL参数是否需要encodeURIComponent空格是编码成%20还是JSON请求体是直接字符串化还是需要压缩必须确保你拼接的字符串和浏览器拼接的完全一致一个字符都不能差。仔细对比浏览器中抓到的原始请求Raw和你构造的请求。算法或密钥已更新网站会不定期更新签名算法或轮换密钥。你需要建立监控机制当大量请求突然失败时能意识到可能需要重新抓包和逆向了。缺少动态参数签名是否依赖一个每次请求都变化的随机数nonce是否依赖一个通过其他接口获取的临时令牌token仔细检查成功请求的完整上下文。5.4 问题四如何应对算法更新策略版本标记在你的代码中将签名算法抽象成一个独立的模块或类。为不同版本的算法标记版本号。健康检查实现一个简单的健康检查函数用当前算法请求一个简单的、无害的API如获取个人头像。如果连续失败触发警报。降级方案准备好备选方案比如当纯签名请求失败时自动切换到基于Puppeteer的降级模式保证功能不中断同时通知开发者进行算法更新。自动化逆向探索高级对于大型项目可以考虑将关键JS文件进行监控和差异对比自动发现代码变更辅助定位新的算法逻辑。逆向请求签名是一个攻防对抗的过程需要耐心、细心和对Web技术的深入理解。每一次成功的逆向不仅是为了获取数据更是对自身技术能力的一次锤炼。面对像小红书这样拥有成熟技术团队的产品其防护机制必然是多层次、动态变化的这就要求我们保持学习灵活运用各种工具和方法论。记住尊重网站的robots.txt和服务条款将技术研究控制在合法合规的范围内是每一位开发者应有的底线。