声明本文所有技术手段仅适用于 SRC 平台明确授权范围内的目标以及你拥有书面授权的资产。未经授权的扫描、探测、数据读取均可能触犯《刑法》第 285、286 条与《网络安全法》。请对数据保持最小化原则只验证、不落地、不传播。引言为什么你挖了半年还是无漏洞很多刚接触 SRC 的同学都经历过同一个循环打开某厂商 SRC 公告页看到别人一个高危拿了几千块于是打开 Burp 对着主站一通乱扫结果要么被 WAF 拦成 403要么提交上去被标记为重复或忽略。问题的根因不在于工具不够强而在于信息差没有建立起来。主站是所有人都盯着的地方它经过了最多的安全测试防护最厚、重复率最高。而真正出洞的地方往往藏在一个三年前上线的测试域名、一个被遗忘的 Swagger 接口、一个前端 JS 里硬编码的 AppSecret、一个只做了前端校验的越权接口。SRC 挖掘的本质是在授权范围内用资产广度 × 参数深度 × 逻辑理解换取漏洞发现概率。本文按真实工作流拆解资产收集 → 攻击面梳理 → 漏洞验证 → 报告提交每一步给出可复用的代码与踩坑经验。先说一个残酷但真实的观察在多数 SRC 平台的漏洞统计里核心域名的有效漏洞占比不到 20%而子域、测试环境、边缘业务贡献了 70% 以上的有效漏洞。这不是因为核心站没有漏洞而是因为它被太多人测过防护体系WAF、RASP、风控、统一鉴权网关叠了好几层任何可疑请求在到达业务代码之前就已经被拦掉。你花三天在主站上碰运气不如花三小时把一个边缘子域的攻击面梳理清楚。另一个常见误区是工具依赖症以为把 nuclei 的模板全跑一遍、把 xray 的被动扫描挂上就能出货。但模板只能匹配已知特征而 SRC 里真正值钱的是逻辑漏洞和业务鉴权缺陷——比如订单号可枚举“优惠券可叠加”“审批流可绕过这类问题没有任何一个扫描器能自动发现必须靠人工理解业务流程、站在开发者视角去推测这里有没有做服务端校验”。工具的作用是帮你把可达资产和可控输入快速铺开最后的判断仍然要靠人。工具负责广度人负责深度两者缺一不可。一、核心原理把攻击面画成一张图1.1 攻击面公式一个可被利用的漏洞本质上是三个集合的交集可利用漏洞 可达资产 ∩ 可控输入 ∩ 权限校验缺失可达资产域名、IP、端口、API、小程序、App、第三方 SDK 回连地址可控输入URL 参数、Header、Body 字段、文件名、跳转地址、WebSocket 消息权限校验缺失水平越权同角色跨用户、垂直越权低权限调高权限、未授权访问。绝大多数人只做了第一步的 30%就直接跳到扫漏洞等于闭着眼睛开枪。这三个集合每一个都值得展开可达资产是最外层的漏斗。它不只是域名列表还包括同一主域下的所有子域、同 C 段/同云厂商 IP、移动端 App 抓包后暴露的 API 域名、微信小程序的后端请求、公众号 H5、以及第三方登录/SDK 的回调地址。很多接口在浏览器里访问不到但在 App 或小程序里是活的——这就是资产与入口的差异。可控输入决定你能碰到什么。同样是GET /user/detail如果参数是服务端从 Session 里取的你没有可控点如果参数是?uid123可控点就出现了。挖掘时要习惯性地问自己这个请求里哪些字段是我能改的改了之后服务端会不会重新校验Header 里的X-User-Id、X-Forwarded-For、Referer往往是鉴权逻辑的软肋。权限校验缺失是最终能否成洞的关键。可达 可控只是前提只有当服务端信任了不该信任的输入或漏掉了归属校验漏洞才成立。这三者构成的交集思维能帮你在面对一堆接口时快速判断哪些值得深挖。1.2 边缘资产才是主战场一个成熟厂商的资产分层大致是层级典型形态防护强度出洞概率核心主站、核心 API 网关极高低业务活动页、子品牌站、小程序后端中中边缘测试环境、旧版系统、供应商系统、静态资源域低高边缘资产的价值在于它们往往由外包或不同团队维护认证体系不统一甚至直接暴露在公网且没有 WAF。一个test-xxx.com的子域可能就是整个项目最容易进的入口。为什么边缘资产这么脆原因有三其一生命周期管理缺失——测试环境上线后没人下线默认口令、调试接口一直开着其二团队边界模糊——外包交付的系统往往只保证功能可用安全配置靠默认值Swagger、Actuator、Druid 监控页经常裸奔其三资产台账不全——安全团队自己都不知道这些域名的存在自然不会纳入防护和巡检。因此实战中要特别关注这几类信号域名里带test、dev、uat、pre、demo、old、beta的标题里带管理后台“运维平台”监控的指纹里出现Swagger UI、Spring Boot Actuator、Nacos、Jenkins、Druid、Grafana的。这些关键词一旦命中优先级立刻拉到最高。此外别忽略历史解析记录——一个域名现在指向 CDN但它三个月前可能直接解析到一台没有 WAF 的源站 IP通过 SecurityTrails、VirusTotal、微步等平台的被动 DNS 数据往往能还原出真实 IP从而绕过 CDN 直连测试。二、资产收集从域名到接口清单2.1 子域名与存活探测被动收集优先不触发目标告警证书透明日志crt.sh、被动 DNS、搜索引擎语法是主力。下面是常用的流水线脚本#!/bin/bash# 用法: ./recon.sh example.com# 仅用于已授权目标domain$1mkdir-pout# 1) 被动子域名枚举subfinder-d$domain-all-silent-oout/subs_raw.txt# 2) 证书透明日志补充能挖到很多内网命名习惯的域名curl-shttps://crt.sh/?q%25.$domainoutputjson\|jq-r.[].name_value\|seds/\*\.//g|sort-uout/subs_raw.txtsort-uout/subs_raw.txt-oout/subs.txtecho[] 子域名数量:$(wc-lout/subs.txt)# 3) 存活 状态码 标题 指纹一次请求全拿到httpx-lout/subs.txt-silent-sc-title-tech-detect-cdn\-oout/alive.txt# 4) 端口扫描top 1000 足够全端口留给重点 IPnaabu-lout/subs.txt -top-ports1000-silent-oout/ports.txt关键点httpx输出的tech-detect字段是后续漏洞匹配的核心依据。看到Spring Boot、Swagger UI、Nacos、Jenkins这些关键词优先级立刻拉满。这段脚本背后的原理值得说清楚。subfinder走的是被动源聚合路线它本身不向目标发任何请求而是从几十个公开数据源证书日志、被动 DNS、搜索引擎、威胁情报里把子域名字典拼出来因此不会触发目标的 WAF 告警。而crt.sh查询的是证书透明日志Certificate Transparency Log——这是 CA 机构必须公开记录所有签发证书的机制任何人只要为*.example.com申请过证书其子域名就会永久留痕。很多公司给内网测试域名也签了证书于是dev-internal.example.com、gitlab-test.example.com这类命名习惯就全暴露了。实操中最常见的三个问题是子域名太多无从下手。解决办法是分层排序先按状态码过滤只留 200/401/403/500再按标题和指纹打标签最后把带敏感关键词的admin、test、api、manage排在最前。被动源覆盖不全。建议同时跑 subfinder、amasspassive 模式、OneForAll三者取并集因为它们的上游数据源重合度并不高。存活探测被 CDN 干扰。httpx -cdn会标记出哪些域名走 CDN这些域名直连测试意义不大真正要挖的是那些没有 CDN、直接回源的边缘域名。2.2 JS 文件被低估的接口金矿现代前后端分离架构下所有前端调用过的接口都会在 JS 里留下痕迹。很多人只看了首页 JS却忽略了懒加载的 chunk 文件。importre,sys,requestsfromurllib.parseimporturljoin# 匹配 JS 中的路径与接口字面量PATTERNre.compile(r[]((?:/|https?://)[A-Za-z0-9_\-./?%{}:]{4,140})[])deffetch(url,timeout10):try:rrequests.get(url,timeouttimeout,verifyFalse,headers{User-Agent:Mozilla/5.0})returnr.textifr.status_code200elseexceptException:returndefextract(js_url,target_domain):textfetch(js_url)hitsset()forminPATTERN.findall(text):# 只保留目标域及相对路径过滤第三方 CDNifm.startswith(http)andtarget_domainnotinm:continueifany(m.endswith(ext)forextin(.png,.jpg,.svg,.woff,.css)):continuehits.add(m)returnhitsif__name____main__:domainsys.argv[1]js_files[l.strip()forlinopen(out/js.txt)ifl.strip()]apisset()forjsinjs_files:apis|extract(js,domain)forpinsorted(apis):print(p)拿到接口清单后重点看三类/api/v1/internal/、/actuator/、/swagger-ui.html—— 未授权访问高发带数字 ID 的接口—— 水平越权高发export、download、batch类接口—— 逻辑漏洞与信息泄露高发。为什么 JS 是金矿因为现代前端用 Webpack/Vite 打包接口路径、参数名、甚至部分密钥都会以字符串字面量的形式被编译进产物。首页加载的往往只是app.js这个主入口真正的业务接口分散在chunk-vendors.js、1.a3f2.js、page-order.[hash].js这些懒加载分片里——它们只有当用户点到对应页面时才会被浏览器请求但文件名通常记录在主 chunk 的映射表里可以顺着提取出来。很多人只抓了首页 JS 就收工等于只挖了 10% 的接口。补充两个进阶技巧找 sourcemap如果产物里存在//# sourceMappingURLapp.js.map或者站点没关掉.map文件直接下载就能还原出近乎完整的源码接口、注释、内部字段一览无余。这是 SRC 里性价比极高的一个点但要注意——只读取、不落地敏感数据。搜硬编码密钥在 JS 里正则匹配AKIA、accessKey、appSecret、secret、token、Authorization: Bearer等关键词经常能挖到对象存储密钥、第三方 API Key。这类问题提交时要注意脱敏并说明密钥已泄露、建议立即轮换。另外提取接口时一定要把相对路径和绝对路径分开处理相对路径要拼上来源 JS 所在域的 base绝对路径要判断是否属于目标域第三方 CDN 的地址如https://cdn.xxx.com/lib.js要过滤掉否则接口清单会被噪音淹没。三、漏洞验证从可疑点到可提交的 PoC3.1 最小化验证原则发现可疑接口后不要批量跑。正确的做法是用 A 账号请求一次记录响应结构换成 B 账号或去掉 Cookie请求同一个 ID对比响应如果 B 能看到 A 的数据越权成立立刻停止只保留 1~2 条证据响应片段截图 / 请求响应报文不下载、不导出、不扩散。批量拉取数据不仅会触发风控告警还可能被认定为超出授权范围直接导致漏洞被忽略甚至账号被封。这条原则之所以重要是因为 SRC 审核的核心判断标准是你是否证明了危害同时把影响控制在最小。你拉取 1000 条订单和拉取 2 条订单证明的都是存在越权但前者在审核眼里是恶意利用后者是合规验证。很多新手明明挖到了真洞却因为拖库式验证被平台判定为违规得不偿失。记住验证是点到为止不是数据搬运。3.2 一个真实场景从 JS 到未授权越权某次授权测试中从app.xxx.com的 chunk JS 里提取到/api/v1/user/profile?uid10086 /api/v1/order/detail?orderId2023xxxx直接去掉 Cookie 请求profile接口返回401说明有认证。但把uid从自己的改成别人的仍然返回了对方手机号前三位与昵称——典型的认证有、鉴权无。这种参数级越权是 SRC 里最常见也最容易拿中危的场景。这个案例的典型性在于它完美对应了 1.1 节的攻击面公式接口可达JS 里泄露、输入可控uid是明文参数、鉴权缺失服务端只校验了是否登录没校验这个 uid 是不是你的。很多开发者会想当然地认为用户登录后只能看到自己的 uid于是只做了认证不做鉴权而这恰恰是越权漏洞的温床。类似的还有把userId放进 Header、把资源 ID 直接拼在 URL、分页接口的pageSize不设上限导致信息泄露等等。3.3 越权批量验证脚本带节流当你确认了越权模式需要小范围证明影响面时用下面这个脚本注意严格限速 只读 不落地importrequests,random,timefromconcurrent.futuresimportThreadPoolExecutor COOKIE_AsessionYOUR_LOW_PRIV_SESSION# 低权限账号URLhttps://api.example.com/api/v1/order/{id}HEADERS{Cookie:COOKIE_A,User-Agent:Mozilla/5.0}defcheck(rid):try:rrequests.get(URL.format(idrid),headersHEADERS,timeout8)# 只判断状态码与是否存在业务关键字段不保存响应正文ifr.status_code200andorderIdinr.text:return(rid,r.status_code,len(r.text))exceptExceptionase:return(rid,ERR,str(e)[:40])returnNone# 随机取样避免连续 ID 造成遍历嫌疑idsrandom.sample(range(200000,999999),50)withThreadPoolExecutor(max_workers3)aspool:# 并发压到 3forresinpool.map(check,ids):ifres:print(res)time.sleep(0.3)# 主动节流避免影响业务脚本输出的每一条200都是证据。验证到 3~5 条即可证明危害不必继续跑。这里的三个设计点值得强调random.sample是为了避免连续 ID 遍历——如果从 100001 顺序扫到 100050日志里就是明显的枚举行为风控秒级告警max_workers3是把并发压到极低避免对业务造成压力time.sleep(0.3)是主动节流。最后的输出只保留(id, status, length)三元组不落地任何响应正文这样即使被审计也能证明你只做了存在性验证而非数据窃取。四、报告与提交让审核一眼看懂4.1 报告结构模板一份被快速通过的报告通常包含以下要素【漏洞标题】xxx系统 /api/v1/order/detail 接口水平越权可读取他人订单 【漏洞类型】越权访问CWE-639 【危害等级】高危 / 中危按 SRC 规则 【影响范围】https://api.example.com 【复现步骤】 1. 使用账号 A138****0001登录获取 Cookie 2. 请求 GET /api/v1/order/detail?orderId10001返回 A 的订单 3. 将 orderId 修改为 10002属于账号 B其余不变重放 4. 响应 200返回账号 B 的收货人姓名、手机号、地址。 【请求报文】...(完整原始请求) 【响应报文】...(关键字段脱敏保留结构证明) 【危害说明】任意登录用户可遍历 orderId 获取全站订单涉及用户隐私数据泄露。 【修复建议】服务端基于当前登录态校验资源归属order.user_id session.user_id 并对 orderId 做不可预测化处理UUID / 加盐哈希。4.2 提高通过率的三个细节标题带接口和危害不要写某处存在越权证据链完整请求 响应 账号归属对比缺一不可危害描述克制不要写可导致全站数据泄露、影响千万用户审核最反感夸大如实描述影响面即可。再补充几点实操经验。第一复现步骤要可被审核独立复现——审核人员手里没有你的账号所以你要么提供测试账号要么用清晰的前后对比截图说明账号 A 拿到了账号 B 的数据。第二响应报文要脱敏但保留结构——手机号中间四位打码、身份证号只留头尾但字段名、层级、状态码必须完整让审核能判断这确实是敏感数据。第三修复建议要落到代码层面——加强鉴权这种空话没人看写清楚在OrderService.detail()里加if (order.getUserId() ! currentUser.getId()) throw new ForbiddenException()才有价值。一份好的报告本质上是让审核在 3 分钟内完成看懂 → 相信 → 定级三步。五、踩坑与优化建议坑一把扫描器结果直接提交。扫描器的Possible SQL Injection十有八九是误报提交后被忽略会拉低你的信誉分。所有提交必须有人工验证的 PoC。坑二忽略授权边界。很多 SRC 的授权范围只包含*.example.com但不包含其供应商系统、云存储桶、第三方 SaaS。越界测试一次可能直接封号。坑三重复率管理。提交前先搜索该 SRC 的历史漏洞公告和公开 writeup同一接口的同类问题大概率已被提交过。建议用接口路径、参数名、业务模块等关键词在平台漏洞库、Google、GitHub 上交叉检索确认无人提交后再动手。坑四只测一个参数就下结论。很多人发现uid越权后提交完就结束了。但同一个接口往往还有orderId、fileId、addressId等多个资源 ID同类问题应当合并成一份报告而不是拆成十条提交——后者会被判定为刷漏洞反而影响信誉。坑五忽略认证状态的变化。验证越权时一定要明确当前是登录态还是未登录态。同样是越权未登录可访问未授权访问的定级通常高于登录态的水平越权报告里要写清楚前置条件。优化建议建立自己的资产台账用表格记录每个目标的域名、指纹、测试进度、已提交漏洞避免重复劳动同时维护一份接口模式库把?id、?uid、?orderId这类高风险参数沉淀下来遇到新目标时优先套用。六、常见问题 FAQQ1没有授权能不能先测再补授权绝对不行。未授权测试在国内属于明确违法行为且 SRC 平台也不认可事后补票。正确顺序是先在 SRC 平台确认目标在授权范围内阅读其测试规范是否允许扫描、是否允许自动化再动手。Q2子域名收集了几千个怎么快速筛出高价值目标用状态码 指纹 关键词三层过滤先保留 200/401/403 的存活站再筛出含Swagger、Actuator、Nacos、Jenkins等指纹的最后用admin|test|api|manage|internal关键词排序。通常几十个目标里就能出 1~2 个高价值入口。Q3越权漏洞提交后总被标重复怎么办越权是重灾区重复率极高。提高命中率的关键是找到别人没测过的边缘接口——比如从 App 抓包、小程序、旧版 API 里提取的接口而不是主站首页那些人人都在测的接口。另外同一系统的越权点如果有多个优先提交影响面最大的那个。Q4验证时被 WAF 拦了怎么办先判断是误拦还是真拦。可以尝试调整请求频率、更换 User-Agent、去掉明显的扫描特征如sqlmap的默认 Header。但不要尝试绕过 WAF 去攻击——如果目标明确禁止绕过绕 WAF 本身就可能违规。遇到强 WAF 时更聪明的做法是转去测没有 WAF 的边缘资产。Q5报告提交后多久有反馈被忽略怎么办各平台不同通常 3~15 个工作日。如果被忽略先看审核理由若是无法复现就补充更清晰的证据链若是危害不足就重新评估影响面必要时升级为组合漏洞如越权 信息泄露。切忌反复提交同一份内容那只会消耗你的信誉分。以上流程的核心其实就是把运气变成方法用资产收集扩大分母用攻击面梳理聚焦分子用最小化验证控制风险用清晰报告完成闭环。更多硬核网安与AI工具包请扫码获取完整源码工具会过时但这套以攻击面为中心、以合规为边界的思维方式在任何目标上都适用。