业务接口签名绕过实战常见校验缺陷复盘免责声明本文所有内容仅用于安全学习、授权渗透测试、代码审计严禁在未授权业务系统上进行抓包、伪造请求、签名绕过测试。任何违规操作带来的法律责任均由操作者自行承担。前言在业务接口安全体系里签名sign是最常见的防护手段。开发者希望通过签名实现两件事防止请求参数被中间人篡改、抵御请求重放攻击。支付接口、APP 后端、小程序接口、Webhook 回调、文件上传、敏感查询接口几乎都会接入 sign 校验。但在历年 SRC 漏洞挖掘、代码审计和攻防演练中大量接口签名只是 “看上去安全”。很多团队照搬网上示例代码对签名拼接规则、参数过滤、验签逻辑、密钥管理理解不到位出现各式各样的校验缺陷。攻击者不需要破解密码只需要利用验签逻辑漏洞直接篡改业务参数造成越权、订单篡改、资金风险、数据泄露等严重后果。很多开发存在一个误区只要加了 MD5/HMAC 签名接口就是安全的。实际上签名只是数据完整性校验手段不能替代权限校验、参数过滤、业务幂等。一旦验签代码存在逻辑漏洞整套防护直接失效。本文结合实战案例复盘接口签名最常见的缺陷讲解对应的绕过思路最后给出安全的签名设计规范。一、接口签名基础原理标准签名流程简单概括客户端收集所有业务请求参数GET 查询串、POST JSON / 表单参数按照约定规则剔除 sign 自身字段将参数按字典序排序拼接成原始字符串拼接密钥 AppSecret使用 MD5、SHA1、HMAC-SHA256 等算法进行哈希生成 sign将 sign 放入请求头或者请求参数随业务参数一起提交给后端服务端收到请求重复相同的拼接逻辑重新计算签名对比客户端传入的 sign 是否一致。只有签名一致才继续执行业务逻辑签名不一致直接拒绝请求。核心关键点后端验签的拼接逻辑必须和客户端完全一致并且不能忽略任何参与计算的参数。绝大多数签名绕过都是后端拼接逻辑和前端不一致导致。典型标准伪代码安全版本# 安全验签伪代码 def verify_sign(params, secret, client_sign): # 移除sign字段sign不参与签名计算 params.pop(sign, None) # 按键字典排序 sorted_items sorted(params.items()) # 拼接keyvalue使用连接 raw_str .join([f{k}{v} for k,v in sorted_items]) secret calc_sign hashlib.md5(raw_str.encode()).hexdigest().lower() return calc_sign client_sign.lower()二、实战中高频出现的签名缺陷与绕过案例缺陷 1参数排序逻辑缺失可新增冗余参数绕过这是最普遍的签名漏洞。开发在写验签代码时忘记对参数做字典序排序直接按请求传入顺序拼接字符串。攻击者可以新增无关参数不影响后端验签结果甚至修改原有参数。漏洞场景前端拼接amount100user_id1001 secret → md5 得到 sign后端直接按传入顺序拼接没有排序。攻击者抓包新增一个无关参数xxx123。如果后端不做排序新增参数如果拼在末尾部分实现下签名校验直接放行更经典的变种后端只取部分参数参与签名额外传入的参数不参与 sign 计算但是后端业务逻辑会读取新增参数。举例原始请求/api/pay?user_id1001amount100signxxxx后端验签只拿user_id和amount计算签名但业务代码会读取所有 GET 参数。Payload/api/pay?user_id1001amount100signxxxxuser_id1002部分 web 框架会取后面的 user_id 值业务使用 user_id1002而签名校验只读取第一个 user_id校验直接通过实现越权。补充变种空参数、无值参数绕过后端拼接时自动过滤 value 为空的参数前端却把空值参与签名。攻击者增加test这类参数后端拼接会丢弃前端计算时带进去逻辑不一致。审计要点检查后端验签代码是否对参数 key 做字典排序是否统一过滤空值、null。缺陷 2签名只校验部分参数业务读取全部参数高危很多开发图省事签名只对少量核心参数做计算但是业务处理代码读取全部请求参数。这是非常严重的漏洞。实战案例某商城订单接口参与签名的参数order_id、user_id业务处理参数order_id、user_id、pay_amount前端计算 sign 只使用 order_id、user_idpay_amount不参与签名。攻击者抓包直接修改 pay_amountsign 保持不变验签通过后端直接使用篡改后的金额执行扣款。一句话总结所有会被后端业务代码读取并参与业务逻辑的参数必须全部参与签名计算。只要业务会读取就必须放进签名原文。很多人踩坑POST JSON 请求签名只对 URL 上的 GET 参数计算完全没有把 JSON 请求体纳入签名。攻击者可以保持 URL 不变直接修改 body 里面所有业务字段sign 不变验签直接放行。这是渗透测试中遇到最多的一类高危签名漏洞。缺陷 3密钥硬编码在前端 / APP攻击者可复刻签名MD5、SHA 这类哈希签名如果密钥写在 JS 前端或者 APP 里面攻击者通过 JS 逆向、APP 逆向拿到 AppSecret就可以完全复刻签名算法任意伪造请求。很多开发误以为 JS 代码混淆之后密钥就安全。混淆只能增加逆向成本不能保护密钥。只要密钥下发到客户端就存在泄露风险。实战场景小程序接口JS 代码里面直接写secret abc123456。抓包看到 sign 算法拿到 secret 之后写 Python 脚本任意构造参数、实时计算合法 sign批量发起请求实现越权查询用户数据。✅ 区分对称签名MD5secret适合服务端之间调用客户端浏览器、APP、小程序不能存放密钥。客户端场景推荐使用非对称 RSA 签名客户端用私钥签名后端使用公钥验签或者使用 token 体系。缺陷 4缺少时间戳 /nonce无重放防护签名只校验参数完整性没有时间戳、随机串 nonce。攻击者抓包拿到一个合法请求包原封不动反复提交。典型危害支付扣款接口抓包一次成功扣款请求循环重放多次扣款投票接口反复提交投票。很多项目虽然加了 timestamp 时间戳但是校验窗口设置过大±30 分钟甚至不限制依然存在重放风险。还有的只校验时间戳格式不校验时间差值。安全做法增加 timestamp设置合理时间窗口一般业务 ±5 分钟高安全场景 ±30 秒增加一次性随机串 nonce存入 Redis设置过期时间防止同一个 nonce 重复使用业务层增加幂等控制唯一订单号保证同一个订单不能重复处理。缺陷 5拼接字符串逻辑不一致特殊字符处理漏洞前后端对特殊字符处理不一致造成签名绕过。URL 编码问题前端参数做 urlencode后端验签时直接使用原始未编码值换行、空格、中文转义差异JSON 参数前端序列化时使用单引号后端使用双引号或者 JSON 键值排序不一致数字类型前端传amount:100数字后端解析成字符串100拼接字符串不一致。案例复盘前端 JSON 序列化{id:1001,name:test}参与签名后端验签时解析 JSON 后拼接数字 1001 转为字符串 “1001”理论没问题但攻击者传入{id:1001,name:test}前后类型不同部分框架下签名校验逻辑出现差异在部分实现中可构造绕过。缺陷 6验签使用非恒定时间比较存在时序攻击简单使用if calc_sign client_sign做字符串对比。编程语言字符串对比是逐字符比较遇到第一个不相等字符直接返回 false。攻击者通过响应时间差异逐位爆破 sign。这类漏洞相对少见但高安全系统支付、金融需要规避。修复使用恒定时间对比函数不提前终止字符串比对。缺陷 7多租户共用同一个 AppSecret密钥隔离失效多个商户、多个客户端共用同一个密钥。A 商户的合法签名可以拿到 B 商户接口尝试请求。一旦一处密钥泄露全部业务接口沦陷。规范不同客户端、不同商户分配独立 AppSecret密钥隔离。缺陷 8JWT 类签名算法混淆攻击扩展很多项目把 JWT 当作接口签名。如果后端信任 token 头部的alg字段攻击者修改alg:RS256为alg:HS256后端使用 RSA 公钥当做 HMAC 密钥攻击者可以伪造合法 JWT。或者设置alg:none部分库直接跳过签名校验。三、接口签名漏洞的黑盒测试思路渗透实战拿到带 sign 的接口按照下面顺序依次测试修改业务参数保持 sign 不变抓包修改金额、user_id、order_id 等核心参数sign 原样保留发送。如果验签通过代表该参数没有参与签名计算高危漏洞。新增额外参数在 GET 或者 JSON body 增加test1、aaabbb保持原有参数和 sign 不变观察接口是否正常返回。如果成功返回大概率没有做严格参数过滤或者排序缺陷。删除部分非核心参数删掉请求里某个非必填参数sign 不变发包判断后端验签是否校验全部参数。重放测试直接原样重放已经成功的请求包观察是否可以重复执行业务操作判断有无时间戳、nonce 防重放。时间戳篡改测试修改 timestamp改成很久之前、很久之后的时间测试时间窗口是否过大或者根本没有校验时间。逆向分析签名算法前端 / APPJS搜索关键词 sign、md5、CryptoJS、secret断点定位签名生成函数APP反编译 dex、so定位加签逻辑提取密钥复现签名脚本。测试注意点POST 接口区分是表单参数还是 JSON body。很多坑就在于只对 url 参数签名忽略 body。四、代码审计重点检查清单代码审计时重点看验签模块逐一核对下面项目是否移除 sign、timestamp、nonce 这类签名字段本身不参与签名原文拼接是否对所有参与签名的参数 key 进行字典升序排序所有业务读取的参数是否全部参与签名GETPOST Body 不能遗漏特殊字符、中文、空格、JSON 序列化前后端处理逻辑完全一致校验 timestamp设置合理时间窗口nonce 一次性随机串存入缓存并去重密钥不硬编码在前端客户端密钥按租户隔离使用安全哈希算法优先 HMAC-SHA256避免直接 MD5 (secretdata) 存在长度扩展攻击风险签名比对采用恒定时间比较签名校验执行在业务逻辑之前不要执行业务之后再校验签名。❌ 错误实现常见特征后端验签在数据库操作、业务执行完成之后才校验 sign只校验 GET 参数POST JSON body 不参与签名参数不排序直接按传入顺序拼接secret 硬编码在 JS、APP 客户端没有时间戳或者时间窗口无限大业务读取的参数部分没有加入签名计算。五、安全的接口签名设计方案方案 1服务端之间调用后端对后端如微服务、第三方回调使用 HMAC-SHA256请求参数全部收集去除 signkey 字典升序排序拼接参数 timestamp nonce使用 HMAC-SHA256AppSecret 作为密钥生成 sign后端校验排序拼接原文HMAC 验签校验 timestamp 时间窗口校验 nonce 不重复传输sign、timestamp、nonce 放在请求头。方案 2客户端APP / 小程序 / H5请求后端禁止客户端保存对称密钥推荐两种方案RSA 非对称签名客户端使用私钥签名后端使用公钥验签私钥仅保存在客户端安全区域不能明文暴露Token 体系JWT 短有效期 token每次接口携带 token后端解析 token 获取身份不再使用自定义 sign。额外纵深防护接口增加请求频率限流业务层面幂等唯一流水号防止重复提交敏感操作增加二次验证码、短信验证WAF 层面监控异常签名、高频重放请求告警。重要签名只能保证 “数据没有被篡改请求来源持有密钥”不能替代权限校验。即使签名合法后端仍然必须校验当前用户是否有权操作目标资源。很多漏洞是签名校验通过之后缺少业务权限判断造成越权。六、复盘总结接口签名漏洞绝大多数不是密码学算法被破解而是业务代码实现层面的逻辑缺陷。开发在复制粘贴示例代码时忽略参数排序、遗漏请求体、未做时间校验、参数参与签名不完整造成防护机制形同虚设。在漏洞挖掘工作中遇到带 sign 的接口不要直接认为无法篡改。优先做黑盒简单测试新增参数、修改参数、重放请求很多时候可以直接发现绕过点。对于开发和安全同学记住核心原则凡是后端业务代码会读取使用的参数全部必须参与签名计算验签逻辑前后端拼接规则必须 100% 一致签名要配套时间戳 nonce 防重放客户端不能存放对称加密密钥签名校验要放在业务逻辑执行前签名 ≠ 权限控制验签通过依然要做业务鉴权。接口签名只是安全防护中的一环单独依靠签名无法保障业务安全需要权限控制、输入过滤、幂等机制、限流、日志审计等多层防御组合。最后关于网络安全技术储备学好网络安全不论是就业还是做副业赚钱都不错但要学会网络安全还是要有一个学习规划。最后大家分享一份全套的网络安全学习资料给那些想学习网络安全的小伙伴们一点帮助对于0基础小白入门如果你是零基础小白想快速入门网络安全是可以考虑的。一方面是学习时间相对较短学习内容更全面更集中。二方面是可以找到适合自己的学习方案包括网安成长学习路线图、SRC黑客文档、护网行动、黑客必读书单、面试题、学习视频等教程。带你从零基础系统性的学好网络安全需要的可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】1.成长路线图学习规划要学习一门新的技术作为新手一定要先学习成长路线图方向不对努力白费。对于从来没有接触过网络安全的同学我们帮你准备了详细的学习成长路线图学习规划。可以说是最科学最系统的学习路线大家跟着这个大的方向学习准没问题。2.网安入门到进阶视频教程很多朋友都不喜欢晦涩的文字我也为大家准备了视频教程其中一共有21个章节每个章节都是当前板块的精华浓缩。全套教程文末领取哈3.SRC黑客文档大家最喜欢也是最关心的SRC技术文籍黑客技术也有收录SRC技术文籍黑客资料由于是敏感资源这里不能直接展示哦全套教程文末领取哈4.护网行动资料其中关于HW护网行动也准备了对应的资料这些内容可相当于比赛的金手指5.黑客必读书单随着互联网技术的飞速发展网络安全已经成为了当今科技领域的一大热点。这些SQL注入、CCNA、Web渗透、Linux服务器等以其强大的语言理解和防御能力正在守护着我们网络世界。 那以下这些PDF籍就是非常不错的学习资源。6.网络安全岗面试题合集当你自学到这里你就要开始思考找工作的事情了而工作绕不开的就是真题和面试题。这份完整版的网络安全学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
业务接口签名绕过实战，常见校验缺陷复盘
业务接口签名绕过实战常见校验缺陷复盘免责声明本文所有内容仅用于安全学习、授权渗透测试、代码审计严禁在未授权业务系统上进行抓包、伪造请求、签名绕过测试。任何违规操作带来的法律责任均由操作者自行承担。前言在业务接口安全体系里签名sign是最常见的防护手段。开发者希望通过签名实现两件事防止请求参数被中间人篡改、抵御请求重放攻击。支付接口、APP 后端、小程序接口、Webhook 回调、文件上传、敏感查询接口几乎都会接入 sign 校验。但在历年 SRC 漏洞挖掘、代码审计和攻防演练中大量接口签名只是 “看上去安全”。很多团队照搬网上示例代码对签名拼接规则、参数过滤、验签逻辑、密钥管理理解不到位出现各式各样的校验缺陷。攻击者不需要破解密码只需要利用验签逻辑漏洞直接篡改业务参数造成越权、订单篡改、资金风险、数据泄露等严重后果。很多开发存在一个误区只要加了 MD5/HMAC 签名接口就是安全的。实际上签名只是数据完整性校验手段不能替代权限校验、参数过滤、业务幂等。一旦验签代码存在逻辑漏洞整套防护直接失效。本文结合实战案例复盘接口签名最常见的缺陷讲解对应的绕过思路最后给出安全的签名设计规范。一、接口签名基础原理标准签名流程简单概括客户端收集所有业务请求参数GET 查询串、POST JSON / 表单参数按照约定规则剔除 sign 自身字段将参数按字典序排序拼接成原始字符串拼接密钥 AppSecret使用 MD5、SHA1、HMAC-SHA256 等算法进行哈希生成 sign将 sign 放入请求头或者请求参数随业务参数一起提交给后端服务端收到请求重复相同的拼接逻辑重新计算签名对比客户端传入的 sign 是否一致。只有签名一致才继续执行业务逻辑签名不一致直接拒绝请求。核心关键点后端验签的拼接逻辑必须和客户端完全一致并且不能忽略任何参与计算的参数。绝大多数签名绕过都是后端拼接逻辑和前端不一致导致。典型标准伪代码安全版本# 安全验签伪代码 def verify_sign(params, secret, client_sign): # 移除sign字段sign不参与签名计算 params.pop(sign, None) # 按键字典排序 sorted_items sorted(params.items()) # 拼接keyvalue使用连接 raw_str .join([f{k}{v} for k,v in sorted_items]) secret calc_sign hashlib.md5(raw_str.encode()).hexdigest().lower() return calc_sign client_sign.lower()二、实战中高频出现的签名缺陷与绕过案例缺陷 1参数排序逻辑缺失可新增冗余参数绕过这是最普遍的签名漏洞。开发在写验签代码时忘记对参数做字典序排序直接按请求传入顺序拼接字符串。攻击者可以新增无关参数不影响后端验签结果甚至修改原有参数。漏洞场景前端拼接amount100user_id1001 secret → md5 得到 sign后端直接按传入顺序拼接没有排序。攻击者抓包新增一个无关参数xxx123。如果后端不做排序新增参数如果拼在末尾部分实现下签名校验直接放行更经典的变种后端只取部分参数参与签名额外传入的参数不参与 sign 计算但是后端业务逻辑会读取新增参数。举例原始请求/api/pay?user_id1001amount100signxxxx后端验签只拿user_id和amount计算签名但业务代码会读取所有 GET 参数。Payload/api/pay?user_id1001amount100signxxxxuser_id1002部分 web 框架会取后面的 user_id 值业务使用 user_id1002而签名校验只读取第一个 user_id校验直接通过实现越权。补充变种空参数、无值参数绕过后端拼接时自动过滤 value 为空的参数前端却把空值参与签名。攻击者增加test这类参数后端拼接会丢弃前端计算时带进去逻辑不一致。审计要点检查后端验签代码是否对参数 key 做字典排序是否统一过滤空值、null。缺陷 2签名只校验部分参数业务读取全部参数高危很多开发图省事签名只对少量核心参数做计算但是业务处理代码读取全部请求参数。这是非常严重的漏洞。实战案例某商城订单接口参与签名的参数order_id、user_id业务处理参数order_id、user_id、pay_amount前端计算 sign 只使用 order_id、user_idpay_amount不参与签名。攻击者抓包直接修改 pay_amountsign 保持不变验签通过后端直接使用篡改后的金额执行扣款。一句话总结所有会被后端业务代码读取并参与业务逻辑的参数必须全部参与签名计算。只要业务会读取就必须放进签名原文。很多人踩坑POST JSON 请求签名只对 URL 上的 GET 参数计算完全没有把 JSON 请求体纳入签名。攻击者可以保持 URL 不变直接修改 body 里面所有业务字段sign 不变验签直接放行。这是渗透测试中遇到最多的一类高危签名漏洞。缺陷 3密钥硬编码在前端 / APP攻击者可复刻签名MD5、SHA 这类哈希签名如果密钥写在 JS 前端或者 APP 里面攻击者通过 JS 逆向、APP 逆向拿到 AppSecret就可以完全复刻签名算法任意伪造请求。很多开发误以为 JS 代码混淆之后密钥就安全。混淆只能增加逆向成本不能保护密钥。只要密钥下发到客户端就存在泄露风险。实战场景小程序接口JS 代码里面直接写secret abc123456。抓包看到 sign 算法拿到 secret 之后写 Python 脚本任意构造参数、实时计算合法 sign批量发起请求实现越权查询用户数据。✅ 区分对称签名MD5secret适合服务端之间调用客户端浏览器、APP、小程序不能存放密钥。客户端场景推荐使用非对称 RSA 签名客户端用私钥签名后端使用公钥验签或者使用 token 体系。缺陷 4缺少时间戳 /nonce无重放防护签名只校验参数完整性没有时间戳、随机串 nonce。攻击者抓包拿到一个合法请求包原封不动反复提交。典型危害支付扣款接口抓包一次成功扣款请求循环重放多次扣款投票接口反复提交投票。很多项目虽然加了 timestamp 时间戳但是校验窗口设置过大±30 分钟甚至不限制依然存在重放风险。还有的只校验时间戳格式不校验时间差值。安全做法增加 timestamp设置合理时间窗口一般业务 ±5 分钟高安全场景 ±30 秒增加一次性随机串 nonce存入 Redis设置过期时间防止同一个 nonce 重复使用业务层增加幂等控制唯一订单号保证同一个订单不能重复处理。缺陷 5拼接字符串逻辑不一致特殊字符处理漏洞前后端对特殊字符处理不一致造成签名绕过。URL 编码问题前端参数做 urlencode后端验签时直接使用原始未编码值换行、空格、中文转义差异JSON 参数前端序列化时使用单引号后端使用双引号或者 JSON 键值排序不一致数字类型前端传amount:100数字后端解析成字符串100拼接字符串不一致。案例复盘前端 JSON 序列化{id:1001,name:test}参与签名后端验签时解析 JSON 后拼接数字 1001 转为字符串 “1001”理论没问题但攻击者传入{id:1001,name:test}前后类型不同部分框架下签名校验逻辑出现差异在部分实现中可构造绕过。缺陷 6验签使用非恒定时间比较存在时序攻击简单使用if calc_sign client_sign做字符串对比。编程语言字符串对比是逐字符比较遇到第一个不相等字符直接返回 false。攻击者通过响应时间差异逐位爆破 sign。这类漏洞相对少见但高安全系统支付、金融需要规避。修复使用恒定时间对比函数不提前终止字符串比对。缺陷 7多租户共用同一个 AppSecret密钥隔离失效多个商户、多个客户端共用同一个密钥。A 商户的合法签名可以拿到 B 商户接口尝试请求。一旦一处密钥泄露全部业务接口沦陷。规范不同客户端、不同商户分配独立 AppSecret密钥隔离。缺陷 8JWT 类签名算法混淆攻击扩展很多项目把 JWT 当作接口签名。如果后端信任 token 头部的alg字段攻击者修改alg:RS256为alg:HS256后端使用 RSA 公钥当做 HMAC 密钥攻击者可以伪造合法 JWT。或者设置alg:none部分库直接跳过签名校验。三、接口签名漏洞的黑盒测试思路渗透实战拿到带 sign 的接口按照下面顺序依次测试修改业务参数保持 sign 不变抓包修改金额、user_id、order_id 等核心参数sign 原样保留发送。如果验签通过代表该参数没有参与签名计算高危漏洞。新增额外参数在 GET 或者 JSON body 增加test1、aaabbb保持原有参数和 sign 不变观察接口是否正常返回。如果成功返回大概率没有做严格参数过滤或者排序缺陷。删除部分非核心参数删掉请求里某个非必填参数sign 不变发包判断后端验签是否校验全部参数。重放测试直接原样重放已经成功的请求包观察是否可以重复执行业务操作判断有无时间戳、nonce 防重放。时间戳篡改测试修改 timestamp改成很久之前、很久之后的时间测试时间窗口是否过大或者根本没有校验时间。逆向分析签名算法前端 / APPJS搜索关键词 sign、md5、CryptoJS、secret断点定位签名生成函数APP反编译 dex、so定位加签逻辑提取密钥复现签名脚本。测试注意点POST 接口区分是表单参数还是 JSON body。很多坑就在于只对 url 参数签名忽略 body。四、代码审计重点检查清单代码审计时重点看验签模块逐一核对下面项目是否移除 sign、timestamp、nonce 这类签名字段本身不参与签名原文拼接是否对所有参与签名的参数 key 进行字典升序排序所有业务读取的参数是否全部参与签名GETPOST Body 不能遗漏特殊字符、中文、空格、JSON 序列化前后端处理逻辑完全一致校验 timestamp设置合理时间窗口nonce 一次性随机串存入缓存并去重密钥不硬编码在前端客户端密钥按租户隔离使用安全哈希算法优先 HMAC-SHA256避免直接 MD5 (secretdata) 存在长度扩展攻击风险签名比对采用恒定时间比较签名校验执行在业务逻辑之前不要执行业务之后再校验签名。❌ 错误实现常见特征后端验签在数据库操作、业务执行完成之后才校验 sign只校验 GET 参数POST JSON body 不参与签名参数不排序直接按传入顺序拼接secret 硬编码在 JS、APP 客户端没有时间戳或者时间窗口无限大业务读取的参数部分没有加入签名计算。五、安全的接口签名设计方案方案 1服务端之间调用后端对后端如微服务、第三方回调使用 HMAC-SHA256请求参数全部收集去除 signkey 字典升序排序拼接参数 timestamp nonce使用 HMAC-SHA256AppSecret 作为密钥生成 sign后端校验排序拼接原文HMAC 验签校验 timestamp 时间窗口校验 nonce 不重复传输sign、timestamp、nonce 放在请求头。方案 2客户端APP / 小程序 / H5请求后端禁止客户端保存对称密钥推荐两种方案RSA 非对称签名客户端使用私钥签名后端使用公钥验签私钥仅保存在客户端安全区域不能明文暴露Token 体系JWT 短有效期 token每次接口携带 token后端解析 token 获取身份不再使用自定义 sign。额外纵深防护接口增加请求频率限流业务层面幂等唯一流水号防止重复提交敏感操作增加二次验证码、短信验证WAF 层面监控异常签名、高频重放请求告警。重要签名只能保证 “数据没有被篡改请求来源持有密钥”不能替代权限校验。即使签名合法后端仍然必须校验当前用户是否有权操作目标资源。很多漏洞是签名校验通过之后缺少业务权限判断造成越权。六、复盘总结接口签名漏洞绝大多数不是密码学算法被破解而是业务代码实现层面的逻辑缺陷。开发在复制粘贴示例代码时忽略参数排序、遗漏请求体、未做时间校验、参数参与签名不完整造成防护机制形同虚设。在漏洞挖掘工作中遇到带 sign 的接口不要直接认为无法篡改。优先做黑盒简单测试新增参数、修改参数、重放请求很多时候可以直接发现绕过点。对于开发和安全同学记住核心原则凡是后端业务代码会读取使用的参数全部必须参与签名计算验签逻辑前后端拼接规则必须 100% 一致签名要配套时间戳 nonce 防重放客户端不能存放对称加密密钥签名校验要放在业务逻辑执行前签名 ≠ 权限控制验签通过依然要做业务鉴权。接口签名只是安全防护中的一环单独依靠签名无法保障业务安全需要权限控制、输入过滤、幂等机制、限流、日志审计等多层防御组合。最后关于网络安全技术储备学好网络安全不论是就业还是做副业赚钱都不错但要学会网络安全还是要有一个学习规划。最后大家分享一份全套的网络安全学习资料给那些想学习网络安全的小伙伴们一点帮助对于0基础小白入门如果你是零基础小白想快速入门网络安全是可以考虑的。一方面是学习时间相对较短学习内容更全面更集中。二方面是可以找到适合自己的学习方案包括网安成长学习路线图、SRC黑客文档、护网行动、黑客必读书单、面试题、学习视频等教程。带你从零基础系统性的学好网络安全需要的可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】1.成长路线图学习规划要学习一门新的技术作为新手一定要先学习成长路线图方向不对努力白费。对于从来没有接触过网络安全的同学我们帮你准备了详细的学习成长路线图学习规划。可以说是最科学最系统的学习路线大家跟着这个大的方向学习准没问题。2.网安入门到进阶视频教程很多朋友都不喜欢晦涩的文字我也为大家准备了视频教程其中一共有21个章节每个章节都是当前板块的精华浓缩。全套教程文末领取哈3.SRC黑客文档大家最喜欢也是最关心的SRC技术文籍黑客技术也有收录SRC技术文籍黑客资料由于是敏感资源这里不能直接展示哦全套教程文末领取哈4.护网行动资料其中关于HW护网行动也准备了对应的资料这些内容可相当于比赛的金手指5.黑客必读书单随着互联网技术的飞速发展网络安全已经成为了当今科技领域的一大热点。这些SQL注入、CCNA、Web渗透、Linux服务器等以其强大的语言理解和防御能力正在守护着我们网络世界。 那以下这些PDF籍就是非常不错的学习资源。6.网络安全岗面试题合集当你自学到这里你就要开始思考找工作的事情了而工作绕不开的就是真题和面试题。这份完整版的网络安全学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
