企业官网建设流程全解析

接手SRC运营和漏洞挖掘这些年，我最大的感受是：真正能稳定产出高危漏洞的人，靠的从来不是运气，也不是无脑跑一遍扫描器，而是对攻击面的理解和对业务逻辑的敏感度。很多新人一上来就打开Burp抓包，看到参数就往里塞SQL注入和XSS payload，折腾一晚上最后交上去一个中危甚至低危，审核还被驳回。反观那些SRC榜上靠前的人，他们更像是在做一场有准备的狩猎：先把目标资产摸得明明白白，再挑最可能出问题的业务逻辑下手，一发命中，直接击穿防线。

这篇文章我想把自己在SRC漏洞挖掘实战里的完整思路拿出来复盘，重点是两件事：攻击面管理和业务逻辑漏洞的精准确认。前者解决“测哪里”的问题，后者解决“怎么测才值钱”的问题。适合刚入门半年、已经会基础Web漏洞利用但产出不稳定的朋友，也适合企业安全团队里负责SRC运营和自测的同学参考。

1. 攻击面管理：所有漏洞都藏在“被遗忘的资产”里

1.1 为什么做攻击面管理而不只是资产枚举

很多人觉得攻击面管理就是收集子域名、扫端口、跑指纹，其实这只是个起点。我理解的攻击面管理，核心是搞清楚三件事：目标系统对外的边界到底在哪里，这些边界里哪些页面承担了核心业务逻辑，以及哪些入口被有意无意隐藏了起来。SRC测试和普通渗透测试最大的区别就在这里，普通渗透可以什么接口都打一打，但SRC是有授权范围、有规则约束、有业务边界的，你只能在厂商给的范围和作用域里打，不能越过红线。所以攻击面管理在SRC场景下，更准确的说法是“在合规授权前提下，把允许测试的所有资产梳理成一张可用地图”。

只有把地图画清楚了，后面找业务逻辑漏洞才不会漏掉关键的页面。很多高危漏洞都出在连主办方自己都忘了的旧接口、测试环境页面、后台管理入口、开发调试API上，这些恰恰是扫描器不容易发现的，也是业务逻辑漏洞最容易藏身的地方。

1.2 攻击面梳理的完整流程

我的习惯是分四个步骤走：域名与资产收集、端口与指纹识别、Web目录与API提取、入口分类与价值排序。每一步都有对应的工具和注意点，我具体展开说说。

域名与资产收集方面，除了常见的子域爆破工具，我更依赖证书透明度日志和备案信息。证书透明日志能查到很多没有在DNS里公开记录的子域，这些往往是对外测试环境、灰度环境或者老系统的域名。备案信息则能帮你把目标集团旗下其他品牌的域名一起纳入视野，很多SRC平台是按整个集团来算奖励范围的，你只盯着主域名，很容易错过集团下面其他系统的漏洞。

端口与指纹识别这里，我习惯先用轻量级的端口扫描确定哪些端口开放了HTTP/HTTPS服务，再用指纹工具确认中间件、框架、服务器类型。这一步不用太贪多，关键是搞清楚哪些端口是Web服务，哪些是数据库或中间件管理端口。如果发现测试环境直接暴露了管理面板，那后面值得重点记录，因为这类管理后台如果存在弱口令或者未授权访问，往往直接就是高危。

Web目录与API提取是攻击面管理里最容易被低估的一步。很多业务逻辑漏洞的入口并不在导航菜单里，而是藏在JavaScript文件里的接口地址。我会用爬虫把目标站点的所有JS文件拉下来，再用正则提取里面的URL、API路径、参数名，这一步能发现不少隐藏接口。还有个细节是看JS文件里有没有调试用的开关，比如debug=true、test=1这种参数，有时候改一个值就能让服务端返回完全不同的逻辑。

入口分类与价值排序是攻击面管理的最后一步。我会把所有收集到的入口整理成一个表格，标注入口类型、所属业务模块、是否需要登录、是否存在参数交互、以及初步判断的价值。价值判断依据是：这个入口如果出问题，会造成什么影响？能改别人数据、能未授权访问后台、能操纵资金或订单，那就优先级很高；如果只是一个纯静态页面，价值就低一些。这步做好后，整个测试方向就非常清晰了。

1.3 攻击面地图的优先级排序方法

收集完攻击面之后，我不建议立即开始盲测，而是先做一轮排序。排序的核心逻辑是“业务重要性×可达性×参数复杂度”。业务重要性决定漏洞的上限，比如订单支付模块出问题可能就是严重；可达性决定测试成本，一个不需要登录就能访问的接口明显比藏在五级菜单后面的页面更值得先测；参数复杂度决定漏洞概率，接口参数越多、越复杂，越容易有逻辑考虑不周全的地方。

排序的时候我还会特别留意一种情况：同一个功能在两个入口都有实现，一个做了校验，另一个没做。比如Web端下单时校验了金额和库存，但App端的对应接口没校验，这不就是典型的横向越权加业务逻辑漏洞的温床吗？攻击面管理做到位了，这种双入口对比的思路自然就会浮现出来。所以不要只收集资产然后拉倒，一定要带着“哪里可能有两个入口、哪里可能有新旧版本并存”的视角去看地图。

2. 业务逻辑漏洞：从攻击面到精准狩猎的转场

2.1 业务逻辑漏洞为什么是SRC高危的主力

攻击面是地图，那业务逻辑漏洞就是宝藏。SRC平台对SQL注入、XSS这类通用漏洞的审核越来越严格，一方面因为这些漏洞很多人都在测，很容易重复，另一方面很多厂商都已经上了WAF和代码审计，通用漏洞的生存空间在被压缩。但业务逻辑漏洞不一样，它依赖的是厂商自己的业务规则和实现代码，每个系统都不一样，第一批测试的人挖到就是独有的，重复概率远低于通用漏洞。

更重要的是，业务逻辑漏洞往往能直接打穿业务本身。比如你通过修改负数的购买数量把订单金额变成负数，或者通过修改用户ID越权查看别人的订单，这种漏洞的影响是立竿见影的，审核方很容易理解你的严重性定级，给高危甚至严重都不奇怪。而且这类漏洞无法用通用扫描器发现，必须靠人去理解业务链路，所以这正是SRC挖掘里最值得投入精力的方向。

2.2 业务逻辑漏洞的六大经典模式

从实战归纳来看，绝大多数业务逻辑漏洞跑不出这六种模式：身份验证与授权绕过、流程顺序篡改、请求参数篡改、并发与条件竞争、状态机异常、业务数据可信校验缺失。我用大白话逐一讲讲。

身份验证与授权绕过是最好理解的一类。你登录一个普通账号，结果能访问管理员的接口，这叫垂直越权；你能查看或修改另一个普通用户的数据，这叫水平越权。这类漏洞的根源是后端接口没有校验当前用户的权限，只信任了前端传过来的ID号。我见过很多电商平台，一个订单详情接口，把订单号换成别人的，就能看到别人的姓名、电话、地址，这数据量一累积，问题就严重了。

流程顺序篡改是指原本必须按步骤走的业务流程，你跳过了某一步。比如正常的购买流程是选商品、确认订单、支付、回调通知，结果有平台因为支付回调接口没做验证，攻击者可以直接伪造一个支付成功的通知，跳过真实支付，订单就变成已支付状态。还有投票、抽奖、签到这类活动，先判断是否能参与再走流程，但如果你直接调用后续接口，有时候就能绕过参与资格校验。

请求参数篡改最典型的就是金额和数量。下单时把单价改成0，把数量改成负数，把优惠券金额改成超过订单金额，这些都属于参数篡改。开发同学如果只在前端页面做了价格校验，后端没有重新计算，这类漏洞就很容易被利用。这里的重点不是参数本身，而是后端是否完全信任了前端提交的数据。

并发与条件竞争是近两年SRC里很火的方向。简单说，就是同一时间发大量请求，绕过对某个状态的校验。最经典的就是电商平台的优惠券领取或账户充值：服务端先查余额，发现是0，然后进入加钱逻辑，但由于没有加锁，你同时发100个请求，全部通过了“余额为0”的检查，然后每个请求都加了10块钱，结果账户多了1000块。这就是典型的并发竞态漏洞。

状态机异常是指业务流程在某个状态下做了不该做的事情。比如订单已经退款了，但系统还允许你继续申请售后；一个抽奖活动已经结束了，但接口还能继续抽奖。很多状态流转的判断依赖一个布尔值或者一个枚举值，如果服务端没有在每个状态节点都做校验，就存在状态跳跃的可能。

业务数据可信校验缺失，说白了就是后端把不该信任的外部数据当成了可信数据。比如把用户输入的JSON、XML、跳转地址、回调地址直接拿来用，没有做白名单校验。最经典的场景是支付回调，回调里带了订单号和支付结果，如果服务端只校验签名不校验订单归属，你就能用自己的订单状态影响别人的订单。还有一种常见情况是跨业务线数据串用，比如A应用的token拿去访问B应用的接口，如果鉴权体系没打通，就可能造成越权。

2.3 如何挖掘业务逻辑漏洞：思路与切入点

挖掘业务逻辑漏洞，核心方法论就八个字：梳理链路、对比差异、突破边界。这不是什么高深理论，而是实操者的经验总结。

先梳理链路。以电商下单为例，完整链路是：登录-浏览商品-加入购物车-提交订单-选择支付方式-支付-支付回调-订单状态更新-物流发货-确认收货。你要先把这条链路的每个节点列出来，再挨个问：这个节点是从哪里接收数据的？谁生成的数据？数据是否被校验？校验是在前端还是后端？链路梳理得越细，找漏洞的抓手就越多。

再对比差异。对比不同角色（普通用户和管理员）、不同入口（Web端和App端）、不同版本（新旧接口）之间的差异。差异的地方就是漏洞可能藏身的地方。比如同是修改用户昵称，Web端传的是nickname，App端传的是user_id加nickname，这就不一样了，App端那个接口可能就没做归属校验。

最后突破边界。突破边界的意思是在正常操作之外，试着给参数添加一些“计划外”的值。比如正常金额是正整数，你试试负数、0、极大值、浮点数、字符串拼接、数组传参。比如正常商品数量是1，你试试0.5、-1、99999999。这些“计划外”的值最容易让后端处理逻辑崩溃或者产生非预期结果。

提示：挖掘业务逻辑漏洞时，一定要把目标当成一个“有业务规则的系统”，而不是一堆HTML和接口的堆砌。你要站在开发者的角度想：如果我来实现这个功能，哪些地方我只做了前端校验？哪些地方我可能会偷懒不校验？这些偷懒的地方，就是你的突破口。

3. 精准狩猎实战：一个完整的SRC挖漏洞流程复盘

3.1 前期侦察与目标选定

拿一次考核来举例，目标是一个电商类SRC，平台本身名气不算大，但是用户量还可以，注册用户可以下单、领券、充值。按照第一部分的方法，我先做了攻击面梳理。子域收集阶段，发现了一个很奇怪的双字母子域，看起来像是内网网关旁挂的一个老系统，直接访问能打开一个只有登录框的页面。指纹识别显示这个页面用的是某老版本PHP框架，登录框下方的版权信息写着“只限内部测试使用”。这个入口我直接标了高分，因为内部测试系统往往没有严格的权限校验，甚至可能有固定的测试账号。

注册了一个普通用户之后，我先把能用到的正常功能全部走了一遍：改头像、填收货地址、下单、领券、取消订单。每一步都开着抓包工具记录下来。走流程的主要目的不是找漏洞，而是理解这个系统的正常业务规则长什么样。你连正常流程都不清楚，怎么可能判断出哪里是非正常的？

3.2 挖掘过程的关键尝试与思路转化

在下单流程中，我发现了一个很有意思的细节：提交订单时，前端请求里带了两个参数，一个是sku_id（商品编号），另一个是price（商品价格）。价格参数我一眼就注意到了，很明显这是前端把商品单价传给了后端。我第一反应是，如果后端直接用这个price来算总价，那就是参数篡改漏洞了。于是我找一个便宜的商品，抓包把price改成0.01元，提交订单，结果订单结算页真的显示应付0.01元。我继续支付了一分钱，订单状态变成已支付，后台模拟出库正常流转。

到这里我已经确认了一个高危候选，但我没有立刻提交，而是继续往深处打了几个组合拳。我试着把price改成负数，比如-1元，结果更离谱，订单价格算出来是负数，结算页显示“应付金额：-1元”，系统甚至提示我支付时可以获得1元退款。这就是典型的业务数据可信缺失，后端完全没有对price参数做范围和类型校验。我立刻把这个链接到了“影响资金安全”这个严重性判定上，明确了这会带来资金损失风险。

同一平台上，我又顺藤摸瓜测了优惠券模块。领券接口返回了一个券码，提交订单时带上券码，再改一个优惠金额参数，原本5元的优惠券被我改成了500元，系统也照单全收。这进一步证实了后端对订单金额计算链路的校验形同虚设。我接下来把整个订单生命周期里的参数都整理了出来，重点标注了哪些是前端可控的、哪些是后端生成的，做了一张对比表，这为后面的报告编写打好了基础。

3.3 复现验证与影响范围确认

挖到这一步还不能松懈，关键的打法已经找到，但影响范围必须确认好。我先用了两个账号做交叉验证。账号A发起一个删除收货地址的请求，抓包后把address_id换成账号B的地址ID；结果A的请求成功删掉了B的地址，这就是水平越权，这两个漏洞叠加在一起，伤害值直接拉满。

为了验证影响是否覆盖所有用户，我再看了一下接口文档和前端JS代码，发现接口路径里带了一个/api/v1/的版本标识，新老版本接口同时存在。我顺手测了一下老版本的接口，发现老版本的数据校验更松，连登录态都可以不怎么校验。这下影响面就不只是某一个功能了，而是整条订单和用户链路都存在越权和参数篡改问题。SRC审核方看到这种影响面，大概率会给一个高分定级。

在复现时我注意了一个原则：能用最小权限、最少数据量验证就绝不扩大测试。比如修改价格我选的是平台上标价最低的商品，目的就是证明漏洞存在，而不是想着怎么薅羊毛。不要为了展示危害真的把大量券领走，或者真的删掉别人的核心数据，一旦越过了测试边界，性质就变了。这个底线在SRC挖掘里非常非常重要。

3.4 编写报告的关键细节

报告写得好不好，直接决定了你的漏洞被定级为严重还是被退回，这里面的门道不少。我提交报告遵循一个固定结构：漏洞名称、漏洞等级、涉及域名与接口、漏洞描述、复现步骤、影响范围、修复建议。每一部分都有讲究。

漏洞名称强烈建议直接点名业务影响，比如“订单接口未校验价格参数导致任意金额下单支付”，而不要写“价格参数可控”。前者一眼就知道严重性，后者还需要审核方自己去脑补业务影响，体验差距很大。漏洞等级也要结合业务影响来写，你能影响资金、越权访问数据，就往严重了评，但要有论据支撑，不能瞎写。复现步骤要精确到每一步的输入和输出，最好附上抓包截图和请求响应对照，我还会把关键的请求报文格式化成可复现的文本，方便审核方直接复测。

修复建议这块很多新人容易漏掉或者写得比较敷衍。我的看法是，提建议要贴合具体代码逻辑。比如这个订单金额问题，你要建议的不是空泛的“加强防护”，而是具体到“服务端应重新从数据库读取商品价格计算订单金额，忽略前端传入的price参数；金额类型应使用整型分而不是浮点元；对价格和数量参数做上下限与正数校验”。审核方看到这种建议会明显感觉你是认真分析过的。

3.5 与厂商审核的沟通经验

报告提交之后，审核周期一般在几天到几周不等。如果遇到审核方不理解漏洞原理，我会主动根据对方反馈补充演示数据、重新整理流程，甚至录一个短视频展示如何从头复现。不要觉得这是在麻烦你，实际上每一次跟审核方的沟通都是拉高漏洞定级的机会，前提是你的漏洞是真实有效的。

这里有几个沟通的节奏要点：提交后如果一周没动静，可以在SRC平台上礼貌地问一句审核进度；如果审核方反馈说无法复现，第一时间重新自查是不是环境变化导致，然后把每一步重新跑一遍，带着操作录屏或更详细的报文回复；如果对方问了漏洞影响范围，干脆利落给出具体的数据量和受影响的用户量，不要含糊其辞。整个沟通始终围绕“真实、准确、可复现”这三个词展开，审核方是不会亏待这种报告的。

4. 常见问题与排查技巧实录

4.1 SRC挖漏洞日常踩坑记录

我见过太多人在SRC上栽跟头，踩的坑无非就那几种。最常见的一个坑是看到啥测啥，完全没有梳理攻击面就开始扫描和payload轰炸，结果不是测了一堆重复漏洞，就是测到了授权范围之外的资产。还有一种是不做登录态管理，明明可以访问后台或用户中心，却只测公开页面，白白浪费了宝贵的攻击面。

另一个坑是不会抓关键节点。很多人抓包只会看请求头和请求参数，看响应只看状态码，完全不关心整个业务流程存在哪些可信边界。你看到的是一个一个孤立的HTTP包，人家看到的是购物车、订单、支付、售后整条链路上可能存在的校验缺失，这两种视角的产出差距是巨大的。

再有一个高频坑是工具依赖过重，一门心思用扫描器跑全站，结果被WAF封了IP，还被平台警告。扫描器不是不能用，但它只能帮你完成攻击面发现的阶段，真正让漏洞值钱的还是人对业务逻辑的思考和验证。有些平台对自动化扫描有明确限制，测试前一定要看清SRC的规则说明，别辛辛苦苦扫出来的漏洞最后因为违规操作被判定为无效。

4.2 如何有效收敛自动化扫描的风险

SRC测试里搞自动化要有分寸。我的经验是，针对单一URL可以用低频扫描，比如设置线程数不超过5，每个请求间隔至少几百毫秒；如果目标站点有验证码或限流机制，要主动降低请求频率。曾经碰上过某目标只在凌晨2点到5点放开测试流量的限制，白天一旦频率高就弹出滑块验证，整批代理IP全被拉黑，血泪教训。

除了频率，还要控制测试范围。自动化扫描前务必配置好作用域匹配规则，只允许访问授权范围内的域名和IP。曾经有次我跑目录扫描时，脚本跟着响应里的一个外链跳到了第三方的CDN域名，幸好巡检及时拦住，不然后果不好说。做SRC测试，边界意识要刻在骨子里，宁可少测两个目录，也不要让流量越过授权范围。

4.3 排查业务逻辑漏洞时的高效姿势

业务逻辑漏洞的排查思路，我总结了一个三步走的习惯，基本可以应对绝大多数目标。

第一步是列“操作链”。把目标的每个核心业务线（注册登录、下单支付、优惠营销、售后申诉、后台管理等）全部列出来，每条线画出从开始到结束的所有状态节点和动作节点。哪个节点涉及钱、哪个节点涉及权限、哪个节点涉及数据返回，全部标注清楚。

第二步是对“角色权限集”。整理目标系统有哪些角色，比如游客、普通用户、VIP用户、运营、客服、管理员。然后在每个节点上问一个问题：这个节点的操作，是否判断了当前角色是否允许做？如果没判断，或者判断条件可以绕过，那垂直越权或水平越权的机会就出现了。最典型的就是修改个人资料时把角色参数从member改成admin，如果后端只判断前端传参里的角色字段，漏洞就出来了。

第三步是试“异常输入集”。对每个关键参数，按类型、范围、符号、逻辑四个维度构造异常输入。类型上试字符串、数组、JSON对象、数字浮点；范围上试负数、0、极小值、极大值、越界值；符号上试+、-、%、空值、null、Unicode特殊字符；逻辑上试重复请求、并发请求、乱序请求、过期重放请求。这一步工作量最大，也是最需要耐心的，但往往就是某个异常输入触碰到了开发逻辑里没考虑到的分支。

4.4 如何判断一个漏洞是否值得提交

判断漏洞是否值得提交，我有几条硬性标准。第一是影响真实性，你要能证明漏洞可以产生实际影响，而不是你臆想出来的影响；第二是影响独特性，如果这个漏洞全网其他人都已经提交过一百遍了，你那就是浪费时间；第三是漏洞可达性，攻击者是否真的能在合理权限下触发；第四是危害可量性，能不能用“可以读取多少用户数据”“可以造成多少金额损失”“可以操作多少账户”这种量化的语言来描述。

只要这四条里有两条成立，我就认为这个漏洞值得打磨后提交。如果四条全中，那基本是必高危的种子选手。这里我要强调一句，很多新人容易把“有影响”和“有价值”混为一谈。比如你发现后台登录页面可以爆破，理论上算是有影响，但既然你已经处于后台登录页面前，在没有其他条件配合时，这种影响不足以支撑一个高分漏洞。真正有价值的漏洞是能够走完一整条攻击链的，比如“未授权接口获取手机号+批量遍历用户ID+垂直越权访问后台”，三个问题串在一起，说服力就出来了。

5. 测试范围与合规边界：每位测试者都必须守住的分寸

5.1 为什么SRC挖掘不能踩到业务红线

SRC注册时都有一份平台规则，里面明确定义了允许测试的范围、禁止操作的行为、以及漏洞提交的格式。绝大多数SRC都明确规定：禁止测试生产环境中的恶意攻击行为，禁止获取或篡改真实用户数据，禁止批量扫描，禁止利用漏洞获取不当利益。这些规则不是摆设，一旦违反，轻则漏洞作废、账号封禁，重则影响个人信誉甚至触及相关管理规定，这个后果没有任何一个漏洞奖励值得去冒。

实战操作里，我给自己划了三条硬边界。第一条，绝对不读取、不下载、不修改真实用户的非授权数据。即使测试中偶然发现数据返回，也只是为了证明漏洞影响，能证明就行，不扩大接触范围。第二条，绝对不对业务系统做破坏性的操作，比如删除核心数据、清空数据库、恶意消耗资源、利用漏洞提现等。第三条，绝对避开涉及资金转移、已支付订单改价、敏感个人信息拿取等可能引发严重后果的操作，一旦确认漏洞存在影响已成立就立刻停止。

5.2 授权范围之外的不碰原则

SRC平台一般会给一个明确的测试对象范围，域名、IP段、特定系统都会列出，不在范围内的资产一律不碰。有些测试者在信息收集时，会发现和主站在同一台服务器上的其他站点，看起来很像“顺带可以测试的目标”，甚至资产指纹显示同一个中间件或同一个CMS。这种情况，哪怕技术上很容易打，也不要去碰，因为你没有授权，超出授权范围的测试就是不规范行为，哪怕测试结果再厉害也不值得。

范围管理不只是为了合规，也是为了保护你自己。我早期曾有次碰到一个边缘子域没有明说是否在该SRC的测试范围里，因为疏忽直接测了一个SQL注入点，虽然没有造成破坏，但平台方看到流量告警后追查过来，沟通成本极高，还差点导致之前所有有效漏洞被清零。从那以后，每次测试前我都会先把域名列表和IP段列表爬出来，逐一比对SRC的授权范围，不在清单里的一律不测。这已经不是防守策略，而是职业习惯。

5.3 从单一漏洞到攻击链的价值提升

合规边界内，能让漏洞变得更有价值的方向是攻击链串联。发现一个越权接口后，顺着这个接口往深走一层，看能不能摸到管理员接口；找到一个未授权数据接口后，看能不能跟其他功能串联实现更高权限的操作。攻击链的每个点单独看可能只有中危，串起来可能就是高危甚至严重。而且这类报告天然具备不可重复性，审核方也会更认真对待，因为攻击链往往比单点漏洞更能还原真实攻击者的行为。

我需要提醒的是，串联攻击链的时候同样不能越界。用几个低危漏洞拼出一个高危的攻击路径没问题，但如果中途需要碰到真实用户数据才能证明，那就必须停止。证明影响范围的方式很多，你完全可以自己注册两个测试账号、构造测试数据来模拟，不一定非要动真实的业务数据。只要漏洞的触发逻辑清晰、条件明确，审核方不会因为你在测试环境复现就降低定级。

6. 写在最后：从“挖洞工具人”到“业务安全思考者”

SRC漏洞挖掘这条路，越往后走越会发现，真正拉开差距的不是手里有多少工具、脚本跑得有多快，而是理解业务的能力。有一天你能从业务规则的角度预判开发会在哪里偷懒、在哪里信任了不该信任的输入、在哪里因为历史遗留问题留下了双入口，你就不再是单纯拿着Burp的测试者，而是一个能站在整体业务视角思考安全的人，这个转变之后，发高危漏洞会变成一件越来越自然的事。

我个人在实际操作中的体会是：每次碰到一个新SRC平台，先别急着去试漏洞，花一到两天时间把业务链路和攻击面地图彻底吃透，甚至比直接开测的产出高出不少。攻击面管理解决广度，业务逻辑漏洞思路解决深度，报告编写和合规意识解决的是这条路能走多稳。希望这套流程能给你的SRC挖洞之路带来一些启发，也期待在某个榜单上看到你的名字。