1. 从一次真实漏洞报告说起为什么业务数据篡改值得你重视做SRC漏洞挖掘这几年我提交过SQL注入、命令执行、越权访问这类“硬核”漏洞但真正让我在厂商那里拿到高评级和高奖励的往往是一些看起来“不够技术”的漏洞——比如业务数据篡改。印象最深的是一次针对某电商平台的测试我仅仅通过修改下单接口里的商品价格字段就把一单价值几千元的商品结算金额变成了几分钱。厂商收到报告后连夜紧急修复直接给了高危定级。很多人觉得漏洞挖掘必须会复杂的POC、会打各种组合拳实际上业务数据篡改类漏洞完全不需要这些。它利用的是开发者在业务逻辑上的疏忽——参数校验不严、前端信任过度、服务端缺少二次校验。这类漏洞覆盖面极广从电商、金融、教育到SaaS平台几乎都能遇到而且危害直接可感知订单金额被改、积分被刷、优惠券被重复领取、用户余额被篡改。我一直认为业务数据篡改是SRC入门性价比最高的漏洞类型。它容易理解、容易复现、报告写起来清楚明白厂商也愿意认。这篇文章我会把这类漏洞的底层原理、挖掘思路、实操细节和报告撰写完整讲一遍同时把所有测试过程限定在合法授权范围内——SRC项目不是让你去打未授权的系统而是在别人明令授权的范围内做安全测试这是底线。2. 业务数据篡改的本质信任边界在哪里被突破了2.1 先搞清楚什么是“业务数据篡改”业务数据篡改简单地讲就是攻击者通过篡改客户端提交给服务端的数据让服务端处理了和预期不一致的数据从而影响业务的最终结果。这类数据包括了订单金额、商品单价、用户积分、账户余额、优惠券状态、权限标志位、密码找回凭证等等。它的本质通常是三类安全缺陷第一类是服务端对客户端提交的数据缺少校验。很多开发者习惯在前端页面做表单校验把JavaScript当成安全边界但实际上前端校验永远只是用户体验层面的东西攻击者可以直接绕过浏览器构造任意请求。第二类是服务端缺少对数据完整性和业务逻辑的校验。比如提交订单的时候只校验收货地址是否存在却不管商品单价更不检查商品价格是否被改动。第三类是客户端存储、传输的数据可以被直接控制。比如把用户身份信息、权限标志存在Cookie里且不做签名或者把关键业务标志位下拉框改成可编辑——比如支付类型、用户等级这类字段给了前端选项这等于把钥匙交给门外的人。这里有个很多人理解偏差的点业务数据篡改有时候不是越权越权是横向或纵向访问了不属于自己的资源而业务数据篡改更多体现在“同一个用户身份”下把业务流转中的参数改得更有利于自己比如把价格改成负数、把数量改成小数、把运费改成零。2.2 服务端信任了不该信任的东西要理解为什么这类漏洞如此普遍需要从后端开发者的心理模型说起。一个典型的订单创建流程是这样的前端页面渲染商品详情用户在页面上看到价格100元点击“立即购买”前端封装一个JSON请求里面携带了商品ID、数量、单价发送给后端后端拿到这些参数直接落库然后生成订单。问题出在后端为什么要相信前端传过来的单价呢正确做法是后端拿商品ID去数据库查出真实单价再和数量做乘法算出总价。很多开发者为了省事或者因为接口设计得low直接信任前端传值。究其原因往往是接口文档约定不严格、开发时间紧迫、缺少对安全设计的评审再加上前端和后端是同一批人开发的内部测试时没有绕过前端直接打后端接口的经验。业务数据篡改漏洞还有一个被低估的源头为了兼容性和开发效率接口允许传很多冗余字段但这些字段并没有被严格过滤后端代码对这些字段存在“取用”和“未校验”并存的状态。比如一个更新用户信息的接口字段里恰好有“可用余额”这个参数前端正常情况不会直接传它但审计接口时你发现它被后端接收并更新了那就是一个典型的篡改入口。2.3 实战中常见漏洞场景速查我在SRC项目里整理过一份自己的台账下面这些场景几乎每次测试都能用上这里按出现频率列一下场景具体入口典型危害订单金额篡改下单接口、结算接口任意金额购买、0元下单商品数量/单价篡改购物车添加、订单复核价格计算错误、库存异常优惠券/折扣参数优惠券领取、下单折扣字段无限领取、超低折扣用户积分/余额积分兑换、余额充值回调积分余额篡改、刷余额身份标志位篡改注册、登录返回包提权、绕过VIP限制支付金额回调支付成功通知、第三方回调伪支付、未支付判定为已支付业务状态篡改订单取消、售后服务接口跳过审核、直接完成密码找回参数找回密码确认接口任意账号密码重置数据导出范围报表导出、数据下载越权导出大量数据这张表不是让你照着一个一个去测而是给你一个排查的思维框架。后面我会逐个展开讲怎么测、怎么判断危害、怎么变成报告。3. 实战方法论从数据包分析到测试思路3.1 准备好你的测试环境和抓包工具业务数据篡改测试不需要太复杂的环境。我的主力方案是本地浏览器加代理抓包工具。浏览器用Chromium内核的为主Firefox备着代理抓包工具我是Burp Suite为主、Fiddler为辅移动端测试再配合安装证书的HTTP抓包工具。在SRC项目里测试之前务必确认这几件事目标有没有在授权范围有没有注册测试账号有没有明确的测试时间窗口这个确认不是走形式而是保护你自己。我见过有人因为没看清楚授权范围跑到生产环境随意测试最后被平台封号且被厂商发函警告。SRC规则里通常明确写了允许测试的域名、禁止测试的系统也会限制测试时间测试前必须逐条读清楚。抓包这块我个人的建议是快速改出模拟请求用Burp的Repeater需要自动化遍历参数时用Burp的Intruder遇到前端加密参数时先用浏览器断点调试定位加密逻辑再手动模拟。这些工具初始配置都不复杂但一定要花时间把证书装好、代理规则配好不然测试过程中“抓不到包”会非常影响效率。3.2 确定测试目标和数据流梳理拿到一个授权目标后我做的第一件事不是急着抓包开测而是梳理业务。我通常会先过一遍目标的功能清单找到涉及资金、积分、权限、状态这类核心业务的流程比如电商的“下单支付”、教育的“课程购买”、金融的“转账充值”。选定具体业务后把它的数据流画出来前端操作触发什么请求请求里带了哪些关键参数参数从哪里来被后端拿去做了什么。比如下单流程选择商品→确认订单页→提交订单→支付。这里抓包重点关注三个接口确认订单页的接口、提交订单的接口、支付回调的接口。有一个很实用的经验一个业务流程里前端页面上展示出来的关键数据几乎都会在某个请求里传到后端。价格、数量、总价、优惠金额、运费、库存、用户ID、订单号、状态码只要你花时间把每个操作对应的请求都过一遍就会很清楚地看到哪些参数是前端传的哪些是后端算出来返回的。前端传的、且涉及到核心业务的参数就是需要重点测的对象。3.3 参数篡改的经典测试矩阵测试业务数据篡改不要漫无目的地乱改。我把测试点整理成一个“矩阵”思维每次测试时逐项检查数值型参数的逻辑边界测试。价格、数量、积分、余额这类数字要把负值、0、极大值、小数、负数溢出、精度边界都试一试。比如把价格改成-1很多系统会出现金额变成负数订单总价反而倒贴给你钱改成0.01就实现了0.01元下单。状态型参数的枚举替换。用户角色、订单状态、支付状态这类参数先看正常流程的取值再找业务里的其他合法取值比如把“待支付”改成“已支付”、把“普通用户”改成“管理员”然后用修改后的参数重新请求后续接口。标识型参数的遍历与替换。这类参数通常是ID、账号、订单号、手机号通过替换成其他用户或者其他订单的值看后端是否校验了归属关系。虽然这严格说偏向越权但和业务数据篡改经常同源同测值得一起做。隐藏参数探测。有些接口会读取一些前端没有展示的参数比如调试标志、模拟支付标志、内部版本号可以通过参数污染的方式加上常见的参数名碰碰运气比如debugtrue、testtrue、admintrue。你可以先抓出一个正常的请求包把它在Repeater里放着每一次只改动一个参数观察响应千万不要同时改多个参数否则出问题时你根本分不清是哪个参数导致的。3.4 三个真实可复现的测试步骤模板下面我按最常见的三种场景把测试步骤写得具体一些你照着走就能上手。第一个场景修改订单金额。操作流程是在电商平台挑选一个商品加入购物车点击提交订单用抓包工具拦截提交订单的请求观察请求体里是否包含商品价格、总价、运费、优惠字段正常放行一次让订单生成去订单详情页确认后端返回的数据。然后回到拦截状态把价格字段从100改成0.01或者把总价字段改成0提交观察后端是否校验。如果订单按修改后的金额生成说明存在漏洞。你还可以更进一步在支付回调通知的接口里把支付金额改成0.01看后端是否以回调金额为准。第二个场景修改支付结果。支付流程里通常有一个“支付成功通知”接口第三方支付平台会回调商家服务器告诉它这笔订单支付成功了。如果商家后端信任回调参数比如金额、订单号、状态那你可以在测试环境模拟一个回调请求把支付金额改成任意值。这个场景测试时尤其要小心必须在授权范围内做并且建议用自己创建的订单来测。第三个场景修改数量参数。把购物车的商品数量从1改成99999或者改成小数、负数观察计算逻辑是否容错。很多系统会直接爆出库存不足但也有些系统在后续请求中引用了这个数量做金额折算可能利用数量参数算出一个异常的总价。这三个模板在无数SRC案例里反复出现不是只有固定系统才会中招几乎所有电商、外卖、课程售卖平台都有过类似的漏洞历史。4. 深入核心怎么判断一个篡改点是不是有效漏洞4.1 危害评估SRC定级的关键逻辑找到了一个能改参数的入口不代表就能提交关键看危害。SRC平台通常把业务数据篡改类漏洞分成几档严重高危直接造成资金损失、大规模数据泄露、批量账户被盗。典型例子是改价格0元下单、批量修改他人余额、重置任意用户密码。中危影响部分用户、需要特定条件才能利用、无法造成直接资金损失。比如修改自己订单状态、绕过某个业务限制、篡改自己的积分。低危影响自身数据、需要高权限配合、或者影响面很小。比如修改个人资料里的某些展示字段、低权限用户修改自己的信息。我发现很多初学者最大的问题不是找不到篡改点而是抓到一个点就兴奋得上报结果因为危害评估不清晰被打回。比如改了自己的昵称变成VIP标志这种后端只要校验登录态就够了的场景危害并不成立。提交之前先问自己三个问题这个参数影响的是自己的数据还是他人的数据篡改后会不会产生资金、信用、权限层面的实际后果这个漏洞能不能被打造成一个批量利用的接口4.2 绕过前端校验的几种常见姿势前端校验不是安全边界这句话几乎人人都知道但测试时一定要实测绕过的路径。最直接的方法就是绕过前端页面直接对后端接口发请求。用Burp抓到正常请求后把请求包保存下来改成Postman或者脚本工具直接重放这种请求不会经过前端JavaScript校验逻辑后端如果没校验就中招了。第二个姿势是修改前端的逻辑。有些前端会在提交前用JavaScript对参数做一次不可见处理而测试时你完全可以改动前端代码逻辑关掉某个校验函数再提交。最简单的做法是在浏览器开发者工具里找到相关JavaScript方法直接改方法逻辑然后重新触发提交。第三个姿势是利用请求重放。很多业务接口只校验了请求格式和登录态没有校验是否重复提交。比如一个优惠券领取接口同一个请求重复发100次看后台是否生成了100张券。还有下单接口重复提交后订单会不会重复生成。这种情况下你甚至不需要做任何参数修改只需重放就能出问题。另外还有一个容易被忽略的点尝试更换请求方式。同样一个请求把POST改成GET或者把Content-Type从JSON改成表单格式部分后端的参数解析逻辑会发生变化原本会过滤的参数可能就不会过滤了。这种情况在老旧系统里概率很高。4.3 参数污染与畸形数据不按套路出牌的测试方法除了直接改数值业务数据篡改还有很多“不按套路”的玩法。参数污染就是其中一种同一个参数名在请求里出现多次比如price100price0.01有些后端解析时只取第一个有些取最后一个有些会把两个值合到一起可以利用解析差异拿到一个不合理的数值。畸形数据也是值得尝试的方向把数组传给本应接收字符串的参数把JSON对象传给本应是数字的参数把超长的值塞给一个短字段。很多语言的类型转换有个特点当数组或对象被转成字符串时会产生Notice错误并转换成固定值。比如PHP里把price[]100传到后端做加法运算可能直接得到0或者造成未定义位移。这类问题在新手写的接口里非常多但毕竟是真实的漏洞。编码绕过也是常用手段。统一资源定位法定符URL编码、Unicode编码、两种进制表示都可能被后端在某个环节错误解码。比如把0.01改成0%2e01某些后端的正则匹配会认为它不是数字而跳过校验最终存库时又是0.01。测试这些技术点时注意两点一是确保每次测试都有响应对比改动前和改动后的响应不同才说明参数真的生效了二是改动后要观察业务链路的后续结果有时接口返回没有变化但数据库里已经变了内容需要去业务前端页面确认最终效果。4.4 影响范围评估单点漏洞如何撑起高危评级一个篡改点到底能造成多大影响往往取决于你是否愿意做“影响扩大化验证”。最简单的情况就是自己改自己的订单价格这种一般只能算中低危。但如果你把同一个接口的作用对象换成其他用户影响就完全不同了。比如平台有一个“查询用户积分明细”的接口正常前端固定传自己的用户ID但你抓包后发现后端没有校验当前用户ID和传入ID是否一致就可以把ID替换成目标用户的ID批量查看他人积分和消费记录。再进一步如果积分扣除接口也没校验归属那更严重可以批量抹掉别人的积分。影响扩大的常见思路有这么几条将自己可控的参数变成遍历他人数据的通道将自己单次操作的篡改变成批量利用的脚本将只能影响数据展示的漏洞结合其他业务变成实质资金损失。每当你的测试停留在“自己账号里出效果”的阶段都值得再往深处多想一步其他用户的数据会不会因为同一个缺陷被一起影响我个人的经验是报告里除了写清楚单次测试效果还要显式描述“可利用此漏洞批量修改任意用户数据”的场景配上1到2条辅助证明厂商审核时定级会明显更高。5. 工具链组合Burp Suite之外我还用什么5.1 Burp Suite的核心配置与使用心得Burp Suite是我业务数据篡改测试的主力工具它最常用的几个模块就够覆盖我的日常工作。Proxy模块负责截获和修改HTTP/HTTPS请求Repeater模块负责手动修改重放请求Intruder模块负责自动化参数遍历和字典爆破Comparer模块负责对比响应差异。配置方面不太复杂但有一个细节我觉得很重要强烈建议在Burp的Proxy Settings里开启“Intercept Server Response”或者配合使用Repeater的“Update Content-Length”功能。因为改请求体时字符长度往往变化不更新该头部会导致后端收不到完整请求莫名其妙的404或者400就是这里出的问题。还有一个很实用的技巧是用Burp的Match and Replace在请求通过代理时自动替换某些参数。比如想测试一个系统所有请求中的用户ID可以设置一条规则把当前用户ID替换成另一个用户ID这样不用每个请求手动改自动帮你把整个流程里的所有请求都做了替换效率翻了不止一倍。5.2 几个好用的小工具和脚本思路Burp之外有几个工具属于“用到时真好用”的类型。用于接口分析和批量测试的Postman不用多说写脚本时我会用Python的requests库配合抓包获得的数据。遇到前端参数被加密处理时就用浏览器开发者工具的Source面板在提交函数前后设置断点观察加密前的原始对象结构和加密后的密文如果加密逻辑是全JS实现的直接复制代码到Node环境里跑后端要怎么解析、我们就能怎么构造。我也常备一个简单的脚本模板用来做高频率的参数遍历测试import requests import itertools url https://target.example.com/api/order/submit headers { Cookie: session_idyour_logged_in_session, Content-Type: application/json } # 订单提交参数模板 base_payload { product_id: 1001, quantity: 1, price: 299.00, total: 299.00, coupon: 0 } # 测试价格篡改的边界值集合 price_values [-1, 0, 0.01, 1, 999999, abc, None, [1,2]] for p in price_values: payload base_payload.copy() payload[price] p resp requests.post(url, jsonpayload, headersheaders, timeout10) print(p, resp.status_code, resp.text[:200]) print(---)这段只是演示性的代码实际使用时必须改成交给你的授权目标。另外提醒一句跑自动化脚本时必须控制频率加一个time.sleep()做延时不要对目标造成过大压力这也是SRC测试的基本素养。5.3 移动端App测试的特殊注意事项移动端App的业务数据篡改套路和Web端大体一致但是多了几个需要处理的问题。第一是抓包时需要安装证书并信任代理证书Android 7.0以上系统默认不信任用户证书要做相应的证书处理才能解出HTTPS流量第二是很多App做了证书校验或者SSL Pinning这种情况下抓包工具直接挂掉需要配合开发环境或者测试包来做有时候还得处理脱壳的问题。移动端更值得关注的是App内部存储和传输的参数。有些App会把用户信息缓存在本地数据库里而另一个接口取本地数据去提交这就相当于在后端完全没校验的情况下你不通过抓包就能手工篡改本地存储再触发提交。比如一个离线模式的积分签到逻辑把本地记录的签到时间往后改几天再同步到服务端就可能被判定为连续签到。还有一个移动端特性App的接口经常比Web端多很多有些只给内部使用的接口、管理员接口、调试接口Web前端没有入口但App里有隐藏入口。抓包时多观察请求列表看到不常见的路径或参数非常值得深入测一下。6. 报告撰写与SRC提交流程从测试到赏金的最后一公里6.1 一份让别人一看就懂的高质量报告怎么写在SRC平台提交过很多次报告我总结出一条最朴素的规律厂商审核人员每天要处理几十份报告如果你的报告还要他花时间琢磨你的思路那大概率得不到高评级。报告的价值在于快速复现在于准确表达危害。一份好的业务数据篡改报告需要包含以下核心要素漏洞描述部分用一两句话说清楚漏洞出在哪个业务环节、攻击者能做什么不要写一堆铺垫直接说“某下单接口存在价格参数可篡改缺陷攻击者可利用该接口以任意金额提交订单”。复现步骤部分用编号的形式写清楚每一步登录账号、选择商品、开启抓包、修改某个参数从什么值改成什么值、提交后观察什么现象。这里最关键的是把修改前后的请求包完整贴出来尤其是参数对比。我习惯用两步来展示正常请求的抓包截图以及修改参数后的抓包截图两张图并列审核者一眼就能看懂差异。危害影响部分写清楚利用这个漏洞能达到的最坏效果。结合我前面说到的影响面评估如果能力有限只能测到自己账号也要明确写出“理论上可推广到其他用户”的推演路径。修复建议部分不用写代码给几条清晰的整改方向就行服务端必须重新查询数据库获取真实价格不能信任前端参数对关键业务参数增加后端二次校验和签名机制下单时增加价格一致性校验如果前端传的价格和库里的价格不一致就直接拒绝对支付回调结果要做验签和金额核对。6.2 截图和录屏证据链完整性的价值报告的价值很大程度上取决于证据是否完整。我的习惯是四张图起步漏洞页面的正常展示图、正常请求包图、篡改后的请求包图、篡改后导致的业务结果图。如果是API接口类漏洞就展示请求包的响应对比如果是支付回调类就展示模拟回调后订单状态的变化。截图的时候注意几个小事项把地址栏和请求行拍清楚避免只有一片马赛克篡改前和篡改后的参数差异可以用标注工具画出来这样审核人不用仔细比对也能快速定位如果截图里包含无关的个人信息或者系统内部数据记得打码但不要打到看不出业务逻辑的程度。有条件的场景可以录制一段短视频完整还原从登录到篡改再到结果的全过程这对高危漏洞的定级帮助很大。很多平台的报告系统支持上传视频附件提交时放上去比纯文字描述有说服力得多。6.3 SRC提交规范和注意事项提交之前再检查一遍授权范围测试域名是否在授权列表里是否用了测试账号是否在允许的时间窗口内这些信息没有确认到位报告写得再好也可能被拒绝。平台还会关注测试行为是否存在破坏性以及是否大量重复请求压垮了目标系统。报告描述里不要写得像攻击教程。虽然都是为了证明漏洞但措辞要专业克制。比如不要写“直接用SQLMap跑一下就把数据库拿了”这种话而是写“通过注入点可读取部分数据已验证受影响的库表和记录条数”。这不仅是文明礼貌也是保护自己报告里有攻击性、破坏性描述一旦被平台判定为恶意行为会被拉黑处理。如果平台审核人员留言要补充信息尽量在12小时内响应补充材料的时候围绕核心复现路径来讲不要扯太多无关内容。另外提交后状态变化可以适当关注一般SRC平台审核周期在3到14天不等祝你好运别踩到我没踩过的坑。6.4 被驳回的常见原因和应对策略被驳回是SRC新人最容易遇到的事。我整理了一下常见的驳回理由复现不清晰。最常见的情况是截图不完整、关键参数没有标出来、请求包和响应包对不上。这类驳回其实很好补救把完整流程重新整理一遍按顺序截图加标注重新提交即可。危害不成立。比如只修改参数后发现业务端根本没受影响或者改动被后端忽略。这种就要老老实实承认这个点测不出实际危害别硬凑转去测别的参数。越权测试行为违规。比如测试未授权域名或者使用攻击性行为这种基本都会直接封号没得商量。影响面不明确。报告里只写了“我改了自己的订单价格变成0.01元”但没有分析对其他用户的影响。要想拿到高评级还是得按我前面说的方法把影响扩大化验证写清楚。另外还有一个建议多去看平台公开的漏洞报告和评级标准同一家平台的历史报告是最好的学习材料。你会发现哪些漏洞类型他们更认可、报告怎么写评级高、哪些描述会被打回。磨刀不误砍柴功这个功夫值得花。7. 从漏洞到修复安全测试的最终价值是让系统更坚固写完报告、拿到奖金这个漏洞就算结束了吗我认为真正的安全测试者不会止步于“证明有洞”而是会思考“为什么有洞、怎么才能补上”。站在防御方的角度回头看业务数据篡改漏洞修复的本质是几个原则服务端永不信任客户端。这个原则听起来简单但真正做到很多团队都做不到。所有关键业务数据都应该在服务端重新计算或二次校验比如订单总价必须在服务端根据商品表里的价格实时计算。关键参数签名防篡改。对涉及资金、权限、身份的参数做一套签名机制服务端校验签名后再处理。签名算法和密钥要保密最好做到每次请求体加上服务端下发的随机数再签名防止重放。状态流转强校验。业务数据篡改通常劫持了业务状态流比如跳过支付直接改订单为已支付状态对应措施是状态机校验只有合法的状态流转路径才能通过比如“下单→支付→发货→完成”不允许跳过中间状态。审计与监控。所有关键业务操作写审计日志监控异常行为比如0元订单、负金额支付、短时间内大量领取优惠券等做到这些异常能被及时发现。合规的漏洞挖掘从来都不是为了攻击别人而是为了让产品更安全。每次你提交一个漏洞厂商修复它千千万万个普通用户就少一分被黑产利用的风险这是安全测试者最朴素也最真实的成就感。我自己在做SRC时的一些习惯最后也一并分享。新建一个测试项目的记录文档按时间记录目标、测试范围、发现的问题、报告状态后期整理复盘的效率高很多。每次测试尽量在干净的环境里做避免和生产数据的交叉。还有一条最想说的保持学习的心态每处理一份报告哪怕被驳回也要反思一下自己的测试思路有没有盲区。业务数据篡改这个方向一直在变化黑产的手段在升级防御方的校验也在升级只有不断更新的测试思维才是真正有价值的东西。 
长河君 · 2026/10/22 11:34:35 · 阅读 1.2k 业务数据篡改漏洞实战：从参数篡改到SRC高危报告
1. 从一次真实漏洞报告说起为什么业务数据篡改值得你重视做SRC漏洞挖掘这几年我提交过SQL注入、命令执行、越权访问这类“硬核”漏洞但真正让我在厂商那里拿到高评级和高奖励的往往是一些看起来“不够技术”的漏洞——比如业务数据篡改。印象最深的是一次针对某电商平台的测试我仅仅通过修改下单接口里的商品价格字段就把一单价值几千元的商品结算金额变成了几分钱。厂商收到报告后连夜紧急修复直接给了高危定级。很多人觉得漏洞挖掘必须会复杂的POC、会打各种组合拳实际上业务数据篡改类漏洞完全不需要这些。它利用的是开发者在业务逻辑上的疏忽——参数校验不严、前端信任过度、服务端缺少二次校验。这类漏洞覆盖面极广从电商、金融、教育到SaaS平台几乎都能遇到而且危害直接可感知订单金额被改、积分被刷、优惠券被重复领取、用户余额被篡改。我一直认为业务数据篡改是SRC入门性价比最高的漏洞类型。它容易理解、容易复现、报告写起来清楚明白厂商也愿意认。这篇文章我会把这类漏洞的底层原理、挖掘思路、实操细节和报告撰写完整讲一遍同时把所有测试过程限定在合法授权范围内——SRC项目不是让你去打未授权的系统而是在别人明令授权的范围内做安全测试这是底线。2. 业务数据篡改的本质信任边界在哪里被突破了2.1 先搞清楚什么是“业务数据篡改”业务数据篡改简单地讲就是攻击者通过篡改客户端提交给服务端的数据让服务端处理了和预期不一致的数据从而影响业务的最终结果。这类数据包括了订单金额、商品单价、用户积分、账户余额、优惠券状态、权限标志位、密码找回凭证等等。它的本质通常是三类安全缺陷第一类是服务端对客户端提交的数据缺少校验。很多开发者习惯在前端页面做表单校验把JavaScript当成安全边界但实际上前端校验永远只是用户体验层面的东西攻击者可以直接绕过浏览器构造任意请求。第二类是服务端缺少对数据完整性和业务逻辑的校验。比如提交订单的时候只校验收货地址是否存在却不管商品单价更不检查商品价格是否被改动。第三类是客户端存储、传输的数据可以被直接控制。比如把用户身份信息、权限标志存在Cookie里且不做签名或者把关键业务标志位下拉框改成可编辑——比如支付类型、用户等级这类字段给了前端选项这等于把钥匙交给门外的人。这里有个很多人理解偏差的点业务数据篡改有时候不是越权越权是横向或纵向访问了不属于自己的资源而业务数据篡改更多体现在“同一个用户身份”下把业务流转中的参数改得更有利于自己比如把价格改成负数、把数量改成小数、把运费改成零。2.2 服务端信任了不该信任的东西要理解为什么这类漏洞如此普遍需要从后端开发者的心理模型说起。一个典型的订单创建流程是这样的前端页面渲染商品详情用户在页面上看到价格100元点击“立即购买”前端封装一个JSON请求里面携带了商品ID、数量、单价发送给后端后端拿到这些参数直接落库然后生成订单。问题出在后端为什么要相信前端传过来的单价呢正确做法是后端拿商品ID去数据库查出真实单价再和数量做乘法算出总价。很多开发者为了省事或者因为接口设计得low直接信任前端传值。究其原因往往是接口文档约定不严格、开发时间紧迫、缺少对安全设计的评审再加上前端和后端是同一批人开发的内部测试时没有绕过前端直接打后端接口的经验。业务数据篡改漏洞还有一个被低估的源头为了兼容性和开发效率接口允许传很多冗余字段但这些字段并没有被严格过滤后端代码对这些字段存在“取用”和“未校验”并存的状态。比如一个更新用户信息的接口字段里恰好有“可用余额”这个参数前端正常情况不会直接传它但审计接口时你发现它被后端接收并更新了那就是一个典型的篡改入口。2.3 实战中常见漏洞场景速查我在SRC项目里整理过一份自己的台账下面这些场景几乎每次测试都能用上这里按出现频率列一下场景具体入口典型危害订单金额篡改下单接口、结算接口任意金额购买、0元下单商品数量/单价篡改购物车添加、订单复核价格计算错误、库存异常优惠券/折扣参数优惠券领取、下单折扣字段无限领取、超低折扣用户积分/余额积分兑换、余额充值回调积分余额篡改、刷余额身份标志位篡改注册、登录返回包提权、绕过VIP限制支付金额回调支付成功通知、第三方回调伪支付、未支付判定为已支付业务状态篡改订单取消、售后服务接口跳过审核、直接完成密码找回参数找回密码确认接口任意账号密码重置数据导出范围报表导出、数据下载越权导出大量数据这张表不是让你照着一个一个去测而是给你一个排查的思维框架。后面我会逐个展开讲怎么测、怎么判断危害、怎么变成报告。3. 实战方法论从数据包分析到测试思路3.1 准备好你的测试环境和抓包工具业务数据篡改测试不需要太复杂的环境。我的主力方案是本地浏览器加代理抓包工具。浏览器用Chromium内核的为主Firefox备着代理抓包工具我是Burp Suite为主、Fiddler为辅移动端测试再配合安装证书的HTTP抓包工具。在SRC项目里测试之前务必确认这几件事目标有没有在授权范围有没有注册测试账号有没有明确的测试时间窗口这个确认不是走形式而是保护你自己。我见过有人因为没看清楚授权范围跑到生产环境随意测试最后被平台封号且被厂商发函警告。SRC规则里通常明确写了允许测试的域名、禁止测试的系统也会限制测试时间测试前必须逐条读清楚。抓包这块我个人的建议是快速改出模拟请求用Burp的Repeater需要自动化遍历参数时用Burp的Intruder遇到前端加密参数时先用浏览器断点调试定位加密逻辑再手动模拟。这些工具初始配置都不复杂但一定要花时间把证书装好、代理规则配好不然测试过程中“抓不到包”会非常影响效率。3.2 确定测试目标和数据流梳理拿到一个授权目标后我做的第一件事不是急着抓包开测而是梳理业务。我通常会先过一遍目标的功能清单找到涉及资金、积分、权限、状态这类核心业务的流程比如电商的“下单支付”、教育的“课程购买”、金融的“转账充值”。选定具体业务后把它的数据流画出来前端操作触发什么请求请求里带了哪些关键参数参数从哪里来被后端拿去做了什么。比如下单流程选择商品→确认订单页→提交订单→支付。这里抓包重点关注三个接口确认订单页的接口、提交订单的接口、支付回调的接口。有一个很实用的经验一个业务流程里前端页面上展示出来的关键数据几乎都会在某个请求里传到后端。价格、数量、总价、优惠金额、运费、库存、用户ID、订单号、状态码只要你花时间把每个操作对应的请求都过一遍就会很清楚地看到哪些参数是前端传的哪些是后端算出来返回的。前端传的、且涉及到核心业务的参数就是需要重点测的对象。3.3 参数篡改的经典测试矩阵测试业务数据篡改不要漫无目的地乱改。我把测试点整理成一个“矩阵”思维每次测试时逐项检查数值型参数的逻辑边界测试。价格、数量、积分、余额这类数字要把负值、0、极大值、小数、负数溢出、精度边界都试一试。比如把价格改成-1很多系统会出现金额变成负数订单总价反而倒贴给你钱改成0.01就实现了0.01元下单。状态型参数的枚举替换。用户角色、订单状态、支付状态这类参数先看正常流程的取值再找业务里的其他合法取值比如把“待支付”改成“已支付”、把“普通用户”改成“管理员”然后用修改后的参数重新请求后续接口。标识型参数的遍历与替换。这类参数通常是ID、账号、订单号、手机号通过替换成其他用户或者其他订单的值看后端是否校验了归属关系。虽然这严格说偏向越权但和业务数据篡改经常同源同测值得一起做。隐藏参数探测。有些接口会读取一些前端没有展示的参数比如调试标志、模拟支付标志、内部版本号可以通过参数污染的方式加上常见的参数名碰碰运气比如debugtrue、testtrue、admintrue。你可以先抓出一个正常的请求包把它在Repeater里放着每一次只改动一个参数观察响应千万不要同时改多个参数否则出问题时你根本分不清是哪个参数导致的。3.4 三个真实可复现的测试步骤模板下面我按最常见的三种场景把测试步骤写得具体一些你照着走就能上手。第一个场景修改订单金额。操作流程是在电商平台挑选一个商品加入购物车点击提交订单用抓包工具拦截提交订单的请求观察请求体里是否包含商品价格、总价、运费、优惠字段正常放行一次让订单生成去订单详情页确认后端返回的数据。然后回到拦截状态把价格字段从100改成0.01或者把总价字段改成0提交观察后端是否校验。如果订单按修改后的金额生成说明存在漏洞。你还可以更进一步在支付回调通知的接口里把支付金额改成0.01看后端是否以回调金额为准。第二个场景修改支付结果。支付流程里通常有一个“支付成功通知”接口第三方支付平台会回调商家服务器告诉它这笔订单支付成功了。如果商家后端信任回调参数比如金额、订单号、状态那你可以在测试环境模拟一个回调请求把支付金额改成任意值。这个场景测试时尤其要小心必须在授权范围内做并且建议用自己创建的订单来测。第三个场景修改数量参数。把购物车的商品数量从1改成99999或者改成小数、负数观察计算逻辑是否容错。很多系统会直接爆出库存不足但也有些系统在后续请求中引用了这个数量做金额折算可能利用数量参数算出一个异常的总价。这三个模板在无数SRC案例里反复出现不是只有固定系统才会中招几乎所有电商、外卖、课程售卖平台都有过类似的漏洞历史。4. 深入核心怎么判断一个篡改点是不是有效漏洞4.1 危害评估SRC定级的关键逻辑找到了一个能改参数的入口不代表就能提交关键看危害。SRC平台通常把业务数据篡改类漏洞分成几档严重高危直接造成资金损失、大规模数据泄露、批量账户被盗。典型例子是改价格0元下单、批量修改他人余额、重置任意用户密码。中危影响部分用户、需要特定条件才能利用、无法造成直接资金损失。比如修改自己订单状态、绕过某个业务限制、篡改自己的积分。低危影响自身数据、需要高权限配合、或者影响面很小。比如修改个人资料里的某些展示字段、低权限用户修改自己的信息。我发现很多初学者最大的问题不是找不到篡改点而是抓到一个点就兴奋得上报结果因为危害评估不清晰被打回。比如改了自己的昵称变成VIP标志这种后端只要校验登录态就够了的场景危害并不成立。提交之前先问自己三个问题这个参数影响的是自己的数据还是他人的数据篡改后会不会产生资金、信用、权限层面的实际后果这个漏洞能不能被打造成一个批量利用的接口4.2 绕过前端校验的几种常见姿势前端校验不是安全边界这句话几乎人人都知道但测试时一定要实测绕过的路径。最直接的方法就是绕过前端页面直接对后端接口发请求。用Burp抓到正常请求后把请求包保存下来改成Postman或者脚本工具直接重放这种请求不会经过前端JavaScript校验逻辑后端如果没校验就中招了。第二个姿势是修改前端的逻辑。有些前端会在提交前用JavaScript对参数做一次不可见处理而测试时你完全可以改动前端代码逻辑关掉某个校验函数再提交。最简单的做法是在浏览器开发者工具里找到相关JavaScript方法直接改方法逻辑然后重新触发提交。第三个姿势是利用请求重放。很多业务接口只校验了请求格式和登录态没有校验是否重复提交。比如一个优惠券领取接口同一个请求重复发100次看后台是否生成了100张券。还有下单接口重复提交后订单会不会重复生成。这种情况下你甚至不需要做任何参数修改只需重放就能出问题。另外还有一个容易被忽略的点尝试更换请求方式。同样一个请求把POST改成GET或者把Content-Type从JSON改成表单格式部分后端的参数解析逻辑会发生变化原本会过滤的参数可能就不会过滤了。这种情况在老旧系统里概率很高。4.3 参数污染与畸形数据不按套路出牌的测试方法除了直接改数值业务数据篡改还有很多“不按套路”的玩法。参数污染就是其中一种同一个参数名在请求里出现多次比如price100price0.01有些后端解析时只取第一个有些取最后一个有些会把两个值合到一起可以利用解析差异拿到一个不合理的数值。畸形数据也是值得尝试的方向把数组传给本应接收字符串的参数把JSON对象传给本应是数字的参数把超长的值塞给一个短字段。很多语言的类型转换有个特点当数组或对象被转成字符串时会产生Notice错误并转换成固定值。比如PHP里把price[]100传到后端做加法运算可能直接得到0或者造成未定义位移。这类问题在新手写的接口里非常多但毕竟是真实的漏洞。编码绕过也是常用手段。统一资源定位法定符URL编码、Unicode编码、两种进制表示都可能被后端在某个环节错误解码。比如把0.01改成0%2e01某些后端的正则匹配会认为它不是数字而跳过校验最终存库时又是0.01。测试这些技术点时注意两点一是确保每次测试都有响应对比改动前和改动后的响应不同才说明参数真的生效了二是改动后要观察业务链路的后续结果有时接口返回没有变化但数据库里已经变了内容需要去业务前端页面确认最终效果。4.4 影响范围评估单点漏洞如何撑起高危评级一个篡改点到底能造成多大影响往往取决于你是否愿意做“影响扩大化验证”。最简单的情况就是自己改自己的订单价格这种一般只能算中低危。但如果你把同一个接口的作用对象换成其他用户影响就完全不同了。比如平台有一个“查询用户积分明细”的接口正常前端固定传自己的用户ID但你抓包后发现后端没有校验当前用户ID和传入ID是否一致就可以把ID替换成目标用户的ID批量查看他人积分和消费记录。再进一步如果积分扣除接口也没校验归属那更严重可以批量抹掉别人的积分。影响扩大的常见思路有这么几条将自己可控的参数变成遍历他人数据的通道将自己单次操作的篡改变成批量利用的脚本将只能影响数据展示的漏洞结合其他业务变成实质资金损失。每当你的测试停留在“自己账号里出效果”的阶段都值得再往深处多想一步其他用户的数据会不会因为同一个缺陷被一起影响我个人的经验是报告里除了写清楚单次测试效果还要显式描述“可利用此漏洞批量修改任意用户数据”的场景配上1到2条辅助证明厂商审核时定级会明显更高。5. 工具链组合Burp Suite之外我还用什么5.1 Burp Suite的核心配置与使用心得Burp Suite是我业务数据篡改测试的主力工具它最常用的几个模块就够覆盖我的日常工作。Proxy模块负责截获和修改HTTP/HTTPS请求Repeater模块负责手动修改重放请求Intruder模块负责自动化参数遍历和字典爆破Comparer模块负责对比响应差异。配置方面不太复杂但有一个细节我觉得很重要强烈建议在Burp的Proxy Settings里开启“Intercept Server Response”或者配合使用Repeater的“Update Content-Length”功能。因为改请求体时字符长度往往变化不更新该头部会导致后端收不到完整请求莫名其妙的404或者400就是这里出的问题。还有一个很实用的技巧是用Burp的Match and Replace在请求通过代理时自动替换某些参数。比如想测试一个系统所有请求中的用户ID可以设置一条规则把当前用户ID替换成另一个用户ID这样不用每个请求手动改自动帮你把整个流程里的所有请求都做了替换效率翻了不止一倍。5.2 几个好用的小工具和脚本思路Burp之外有几个工具属于“用到时真好用”的类型。用于接口分析和批量测试的Postman不用多说写脚本时我会用Python的requests库配合抓包获得的数据。遇到前端参数被加密处理时就用浏览器开发者工具的Source面板在提交函数前后设置断点观察加密前的原始对象结构和加密后的密文如果加密逻辑是全JS实现的直接复制代码到Node环境里跑后端要怎么解析、我们就能怎么构造。我也常备一个简单的脚本模板用来做高频率的参数遍历测试import requests import itertools url https://target.example.com/api/order/submit headers { Cookie: session_idyour_logged_in_session, Content-Type: application/json } # 订单提交参数模板 base_payload { product_id: 1001, quantity: 1, price: 299.00, total: 299.00, coupon: 0 } # 测试价格篡改的边界值集合 price_values [-1, 0, 0.01, 1, 999999, abc, None, [1,2]] for p in price_values: payload base_payload.copy() payload[price] p resp requests.post(url, jsonpayload, headersheaders, timeout10) print(p, resp.status_code, resp.text[:200]) print(---)这段只是演示性的代码实际使用时必须改成交给你的授权目标。另外提醒一句跑自动化脚本时必须控制频率加一个time.sleep()做延时不要对目标造成过大压力这也是SRC测试的基本素养。5.3 移动端App测试的特殊注意事项移动端App的业务数据篡改套路和Web端大体一致但是多了几个需要处理的问题。第一是抓包时需要安装证书并信任代理证书Android 7.0以上系统默认不信任用户证书要做相应的证书处理才能解出HTTPS流量第二是很多App做了证书校验或者SSL Pinning这种情况下抓包工具直接挂掉需要配合开发环境或者测试包来做有时候还得处理脱壳的问题。移动端更值得关注的是App内部存储和传输的参数。有些App会把用户信息缓存在本地数据库里而另一个接口取本地数据去提交这就相当于在后端完全没校验的情况下你不通过抓包就能手工篡改本地存储再触发提交。比如一个离线模式的积分签到逻辑把本地记录的签到时间往后改几天再同步到服务端就可能被判定为连续签到。还有一个移动端特性App的接口经常比Web端多很多有些只给内部使用的接口、管理员接口、调试接口Web前端没有入口但App里有隐藏入口。抓包时多观察请求列表看到不常见的路径或参数非常值得深入测一下。6. 报告撰写与SRC提交流程从测试到赏金的最后一公里6.1 一份让别人一看就懂的高质量报告怎么写在SRC平台提交过很多次报告我总结出一条最朴素的规律厂商审核人员每天要处理几十份报告如果你的报告还要他花时间琢磨你的思路那大概率得不到高评级。报告的价值在于快速复现在于准确表达危害。一份好的业务数据篡改报告需要包含以下核心要素漏洞描述部分用一两句话说清楚漏洞出在哪个业务环节、攻击者能做什么不要写一堆铺垫直接说“某下单接口存在价格参数可篡改缺陷攻击者可利用该接口以任意金额提交订单”。复现步骤部分用编号的形式写清楚每一步登录账号、选择商品、开启抓包、修改某个参数从什么值改成什么值、提交后观察什么现象。这里最关键的是把修改前后的请求包完整贴出来尤其是参数对比。我习惯用两步来展示正常请求的抓包截图以及修改参数后的抓包截图两张图并列审核者一眼就能看懂差异。危害影响部分写清楚利用这个漏洞能达到的最坏效果。结合我前面说到的影响面评估如果能力有限只能测到自己账号也要明确写出“理论上可推广到其他用户”的推演路径。修复建议部分不用写代码给几条清晰的整改方向就行服务端必须重新查询数据库获取真实价格不能信任前端参数对关键业务参数增加后端二次校验和签名机制下单时增加价格一致性校验如果前端传的价格和库里的价格不一致就直接拒绝对支付回调结果要做验签和金额核对。6.2 截图和录屏证据链完整性的价值报告的价值很大程度上取决于证据是否完整。我的习惯是四张图起步漏洞页面的正常展示图、正常请求包图、篡改后的请求包图、篡改后导致的业务结果图。如果是API接口类漏洞就展示请求包的响应对比如果是支付回调类就展示模拟回调后订单状态的变化。截图的时候注意几个小事项把地址栏和请求行拍清楚避免只有一片马赛克篡改前和篡改后的参数差异可以用标注工具画出来这样审核人不用仔细比对也能快速定位如果截图里包含无关的个人信息或者系统内部数据记得打码但不要打到看不出业务逻辑的程度。有条件的场景可以录制一段短视频完整还原从登录到篡改再到结果的全过程这对高危漏洞的定级帮助很大。很多平台的报告系统支持上传视频附件提交时放上去比纯文字描述有说服力得多。6.3 SRC提交规范和注意事项提交之前再检查一遍授权范围测试域名是否在授权列表里是否用了测试账号是否在允许的时间窗口内这些信息没有确认到位报告写得再好也可能被拒绝。平台还会关注测试行为是否存在破坏性以及是否大量重复请求压垮了目标系统。报告描述里不要写得像攻击教程。虽然都是为了证明漏洞但措辞要专业克制。比如不要写“直接用SQLMap跑一下就把数据库拿了”这种话而是写“通过注入点可读取部分数据已验证受影响的库表和记录条数”。这不仅是文明礼貌也是保护自己报告里有攻击性、破坏性描述一旦被平台判定为恶意行为会被拉黑处理。如果平台审核人员留言要补充信息尽量在12小时内响应补充材料的时候围绕核心复现路径来讲不要扯太多无关内容。另外提交后状态变化可以适当关注一般SRC平台审核周期在3到14天不等祝你好运别踩到我没踩过的坑。6.4 被驳回的常见原因和应对策略被驳回是SRC新人最容易遇到的事。我整理了一下常见的驳回理由复现不清晰。最常见的情况是截图不完整、关键参数没有标出来、请求包和响应包对不上。这类驳回其实很好补救把完整流程重新整理一遍按顺序截图加标注重新提交即可。危害不成立。比如只修改参数后发现业务端根本没受影响或者改动被后端忽略。这种就要老老实实承认这个点测不出实际危害别硬凑转去测别的参数。越权测试行为违规。比如测试未授权域名或者使用攻击性行为这种基本都会直接封号没得商量。影响面不明确。报告里只写了“我改了自己的订单价格变成0.01元”但没有分析对其他用户的影响。要想拿到高评级还是得按我前面说的方法把影响扩大化验证写清楚。另外还有一个建议多去看平台公开的漏洞报告和评级标准同一家平台的历史报告是最好的学习材料。你会发现哪些漏洞类型他们更认可、报告怎么写评级高、哪些描述会被打回。磨刀不误砍柴功这个功夫值得花。7. 从漏洞到修复安全测试的最终价值是让系统更坚固写完报告、拿到奖金这个漏洞就算结束了吗我认为真正的安全测试者不会止步于“证明有洞”而是会思考“为什么有洞、怎么才能补上”。站在防御方的角度回头看业务数据篡改漏洞修复的本质是几个原则服务端永不信任客户端。这个原则听起来简单但真正做到很多团队都做不到。所有关键业务数据都应该在服务端重新计算或二次校验比如订单总价必须在服务端根据商品表里的价格实时计算。关键参数签名防篡改。对涉及资金、权限、身份的参数做一套签名机制服务端校验签名后再处理。签名算法和密钥要保密最好做到每次请求体加上服务端下发的随机数再签名防止重放。状态流转强校验。业务数据篡改通常劫持了业务状态流比如跳过支付直接改订单为已支付状态对应措施是状态机校验只有合法的状态流转路径才能通过比如“下单→支付→发货→完成”不允许跳过中间状态。审计与监控。所有关键业务操作写审计日志监控异常行为比如0元订单、负金额支付、短时间内大量领取优惠券等做到这些异常能被及时发现。合规的漏洞挖掘从来都不是为了攻击别人而是为了让产品更安全。每次你提交一个漏洞厂商修复它千千万万个普通用户就少一分被黑产利用的风险这是安全测试者最朴素也最真实的成就感。我自己在做SRC时的一些习惯最后也一并分享。新建一个测试项目的记录文档按时间记录目标、测试范围、发现的问题、报告状态后期整理复盘的效率高很多。每次测试尽量在干净的环境里做避免和生产数据的交叉。还有一条最想说的保持学习的心态每处理一份报告哪怕被驳回也要反思一下自己的测试思路有没有盲区。业务数据篡改这个方向一直在变化黑产的手段在升级防御方的校验也在升级只有不断更新的测试思维才是真正有价值的东西。