这两年做SRC漏洞挖掘的人明显多了和四五年前最大的区别在于厂商的攻击面收缩得越来越快传统漏洞越来越少但单位漏洞的含金量却在上升一个高危漏洞换来的赏金往往能顶以前两三个通配级别的问题。这篇东西与其说是一份教程不如说是我自己把2024到2025年踩过的坑、捡过的漏、复盘过的高危漏洞重新梳理了一遍顺带把2026年依然能打的攻击方式和挖掘思路整理出来给你一个可以直接照着做的框架。如果你刚开始碰SRC建议先把合规的部分读熟如果你已经挖了一阵子但老是卡在高危边缘可以直接跳到越权和SSRF那两节那是我个人觉得性价比最高的两个方向。1. 先搞清楚SRC到底在挖什么1.1 SRC不是一个平台是一套规则体系很多人把SRC理解为“补天”或者“漏洞盒子”这类众测平台其实严格讲SRC是厂商自己的安全应急响应中心比如很多互联网公司都有自己的漏洞收集入口也叫企业SRC。众测平台只是把厂商的需求打包分发给你但最终漏洞的价值评判、赏金发放、漏洞定级还是由厂商的安全团队说了算。所以你在哪挖、挖到谁家的资产远比你用什么工具重要得多。2026年的SRC现状是主流大厂的直接奖励越来越规范化重复漏洞秒拒越来越严格平台开始倾向“有效性验证”而非“报个Bug就完事”。这意味着如果你不能讲清楚漏洞的实际影响路径哪怕原理上确实存在风险也很容易被忽略。反过来一个新上线的业务、一次并购引入的旧系统、一个没人维护的子域往往才是高危漏洞的温床而不是那些被成千上万人扫过的主站。1.2 2026年SRC的新攻击面在哪里传统上大家一说SRC就是SQL注入、XSS、弱口令。这些当然还有但2026年真正贡献高危漏洞的往往是下面几类场景接口优先的架构大量业务是前后端分离的后端API直接暴露在公网权限校验却写在前端或者网关卡上。你只需要绕过前端入口直接调用内部接口水平越权分分钟出现。供应链复用组件厂商买了一套第三方OA或者客服系统二次开发后漏洞照旧但域名是厂商自己的于是这些第三方组件直接成为SRC高危漏洞的提款机。大模型应用接入越来越多的站点接入AI问答、智能客服、文档摘要这些功能背后往往是把用户输入拼进Prompt后请求到模型服务传统Web的攻击手法在这套链路里能衍生出提示词注入、敏感数据泄漏、SSRF等一整个攻击链。所以现在的SRC挖掘已经不能只看Web参数、SQL语句、上传文件这些老思路了。它要求你理解业务流转理解数据在哪、谁有权访问、边界在哪条链路上被破坏。这就是为什么信息收集能力在2026年比任何单个漏洞利用技巧都更重要。2. 常见攻击方式全景拆解你必须掌握的武器库2.1 信息收集漏洞挖掘的地基信息收集听起来不性感但它决定你的漏洞产出效率。我个人的经验是高危漏洞大部分来自你没见过的边缘资产而不是官网首页。收集的核心不是“扫到多少子域”而是“把域名、IP、开放端口、Web服务、指纹、旁站、托管源全部关联成一张资产地图”。常用的手段包括子域收集证书透明度、搜索引擎语法、历史DNS记录、JS文件中的硬编码域名。别以为子域挖掘就是跑字典很多时候厂商的测试环境和正式环境共用域名前缀只是端口不同。Web指纹识别看到一套系统后先用指纹识别工具确认它是什么CMS、什么框架、哪个版本。指纹一旦匹配上已知漏洞接下来就是低垂果实。端口服务梳理别只盯80和443MySQL 3306、Redis 6379、Docker API 2375、Zabbix 10051这类端口出现在公网上往往直接是高危配置问题。信息收集的“为什么”也很简单你只有拿到足够大的攻击面才能从中筛选出防守弱的目标。就像一栋大楼正门有好几个保安你绕到消防通道发现门没锁这才叫有效测试。SRC测试同理主站做不了的就看旁站旁站做不了的就看老版本接口总有一层防线是松的。2.2 注入类攻击从SQL到命令注入的典型链路SQL注入在2026年依然是高危榜单常客只是发生位置从传统的登录框、搜索框转移到了API参数、排序字段、数据导出功能甚至HTTP请求头。不要把SQL注入想复杂了它本质上就是程序把用户输入直接拼进SQL语句里执行你只要找到那个拼接点判断数据库类型就能一步步把数据读出来。但2026年挖SQL注入我建议换一套思路优先测JSON接口很多后端会直接把JSON字段里的值拼进查询比普通表单更容易出问题。多关注“排序”“筛选”“批量操作”这些不起眼的参数大厂安全工程师盯登录点盯得太紧排序参数往往漏。报错信息是宝一个能回显数据库版本错误的接口能帮你省掉至少一半的注入判断时间。除了SQL注入命令注入比如ping功能里拼接命令、表达式注入比如EL表达式、模板注入在2026年也值得关注。尤其是自研的运维平台、自动化测试工具这类系统往往有在线执行命令的场景参数过滤却不严格。2.3 业务逻辑漏洞比技术漏洞更扎心的软肋业务逻辑漏洞指的是代码本身没有明显语法或框架缺陷但业务流程设计有问题导致用户可以非预期地操作。典型的例子是密码重置接口只校验手机验证码是否匹配不校验验证码是否过期、是否已经被使用过于是你可以复用一条旧验证短信完成一次完整的密码重置。这类漏洞在SRC里非常吃香因为厂商自己也知道这是业务层面的问题不像注入类漏洞那样要修很多地方业务逻辑漏洞往往改一两行代码就能堵上。加上它没法靠扫瞄器发现每次出现都算有效报告所以是2026年性价比极高的挖掘方向。逻辑漏洞的挖掘没有固定模板但有几个高频场景可以重点盯支付流程改价格、改数量、改优惠券、越权使用他人优惠券。验证码流程爆破、回显、过期后再用、空值绕过。权限流程先低权限用户提交操作再抓包替换成高权限用户的Cookie。状态流程重复提交、并发提交、中间态跳过。我在SRC平台提交过一个案例某商城领券接口没有校验活动状态通过并发请求可以在活动未开始前把券领完虽然不算RCE那种级别但最后定级是中危因为影响了活动资源。这类问题的魅力在于它不需要你精通汇编或者底层协议只要你愿意像真实用户一样把流程走一遍再动点“歪心思”就能发现。2.4 越权漏洞高危漏洞里的常青树越权又叫IDOR不安全的直接对象引用是我个人认为2026年SRC里最值得优先攻克的高危漏洞类型。它的本质是系统只验证了“你是登录用户”没有验证“你是不是这个资源的主人”。于是你只要把URL里的ID换一换就能读别人的订单、改别人的资料、删除别人的文件。越权分两种水平越权同级别用户之间的越权比如普通用户A访问普通用户B的订单。垂直越权低权限用户访问高权限功能比如普通用户调用管理员接口。为什么越权在2026年大量存在因为很多企业把接口层和前端页面彻底分离后后端只认会话不认权限前端页面没有展示某个入口后端接口却依然开放。你只需用抓包工具观察到某个接口再自行构造请求就能跨越前端限制。越权挖掘的正确姿势是注册两个测试账号A、B全程用A账号操作抓包后把请求里的用户ID、订单号、资源ID替换成B账号的如果响应里出现了B的数据漏洞成立。这个思路学起来只要十分钟但能覆盖大量SRC的高危漏洞提交窗口。2.5 前端与XSS类攻击从弹窗到存储型劫持XSS在SRC里的地位这两年有些下降低危、忽略的情况变多了。但在特定场景下XSS依然能直接拉满危害典型的就是存储型XSS打管理员Cookie、在后台管理页面注入脚本实现钓鱼。SRC只看危害不看招式如果你的XSS能读取后台数据、修改配置它就不再是“一个弹窗”那么简单。2026年挖XSS我不建议再往主站搜索框里塞payload而是把重心放在这几个地方文件上传导致的SVG/HTML渲染型XSS导出文件时的文件名注入富文本编辑器的过滤绕过JSONP接口的callback参数注入顺带提一个看起来奇怪但很实际的思路有些站点的响应内容会被第三方监控系统抓取如果在URL参数里注入XSS payload而页面把参数值打印在title里那么监控系统打开的页面就是受害者这种“盲打”虽然不能直接弹窗给你看但能通过外带请求拿到后台地址信息。XSS的关键不是“证明可执行JavaScript”而是“证明这个执行点能触达什么敏感数据”。3. 高危漏洞挖掘实战流程一条能复制的漏洞流水线3.1 划定测试边界授权和Scope是命根子不管你是挖单一厂商的SRC还是通过众测平台接单拿到项目后的第一件事永远是读清范围。这听起来像废话但我见过太多人在交了漏洞报告后被判无效原因就一个资产不属于该SRC的范围。Scope信息通常包括根域名列表IP段小程序/App的包名明确排除的资产比如第三方托管系统、合作方系统在边界外测试哪怕发现了真漏洞厂商也只会礼貌地回复“感谢关注但此资产不属于本项目范围”。严重的甚至会因为扫描行为影响第三方系统而被追究。所以每次测试前把Scope里的资产整理成一个清单后续所有步骤都只在这个清单上操作这是对你自己最大的保护。3.2 从信息收集到资产测绘的实操步骤我建议每个人把自己的信息收集流程沉淀成一套“半自动化”的动作每次接新项目都能直接套用。第一步收集根域名下所有子域。用自己的脚本跑一遍证书透明日志、DNS历史记录、搜索引擎收录把结果汇总后用Ping或者DNS解析确认哪些IP是活的。第二步对存活IP做端口扫描和Web服务指纹识别。端口扫描要慢速、全端口别只扫前1000个端口。第三步对Web服务做目录扫描。重点看备份文件、测试路径、上传目录、API文档入口这些高价值目录。第四步从收集到的JS文件里提取接口路径、AccessKey、OSS Bucket、内网域名。这一步经常能捡到意外惊喜。第五步把所有URL、接口、指纹、端口、旁站汇总成一张资产表按“是否存在已知漏洞组件”“是否为核心业务”“是否暴露敏感端口”排序再决定先测哪个。这五步做完通常半天时间就过去了。但投入产出比非常高因为后续所有漏洞利用都建立在这张资产表上。3.3 从理论验证到危害确认漏洞利用的边界感找到一个疑似漏洞后我的习惯是先小范围验证再尝试提升危害但绝不跨过“证明危害”这条线。验证SQL注入优先使用时间盲注或布尔盲注只构造无害的payload比如判断当前数据库名长度而不是直接导出全表。验证越权拿自己的A账号去访问自己的B账号数据这就是最好、最安全的证明。验证文件上传上传一张无害的jpg或者txt文件确认是否回到可访问的URL即可不尝试上传webshell。验证SSRF让服务器请求我们自己可控的地址比如一个DNSLog域名确认出网能力后打住。不去探测云元数据不扫描内网。很多新手栽跟头不是漏洞找得不对而是验证动作太大。SRC的本质是“证明一个可以被修复的安全问题”不是“证明你能把厂商打死”。一旦把目标站点的数据外泄或者系统搞挂了轻则报告被判无效重则被认为是恶意攻击这个边界一定要守住。3.4 写一份能拿高赏金的漏洞报告漏洞挖掘能力只占50%剩下50%是报告表达能力。一份好的SRC报告要让厂商安全工程师拿着它能轻松复现、快速定位、准确修复。我个人的报告模板是这样漏洞标题包含资产位置、漏洞类型、危害等级关键词比如“某站用户信息接口存在水平越权可遍历任意用户订单”。漏洞描述用三句话讲清楚漏洞发生在哪个功能点、参数是什么、为什么存在。复现步骤用数字序号列出每一步最好带上截图和请求包不要只放一个URL。证明影响给出实际看到的数据打码说明攻击者能做什么事情。修复建议从开发角度给出补丁思路不要只甩一句“加强鉴权”而是指出具体应该在哪里校验权限、加什么条件。报告写得好厂商安全团队对你的信任度会显著提高后续你的中低危漏洞也更不容易被忽略。这和我上面讲的逻辑一致——SRC本质上是一个协作机制你的目标是帮厂商发现问题而不是炫技。4. 高危漏洞的重点突击方向别再漫无目的地扫了4.1 越权与IDOR最容易出高危也最容易忽略我统计过自己在某众测平台的提交记录越权类漏洞占高危提交量的三分之一。原因是这类漏洞与业务逻辑深度绑定自动扫描器难以发现厂商自查覆盖率也低。越权的三个重点排查位置订单、发票、物流查询类接口用户资料、收货地址、优惠券管理文件下载/预览功能中带文件路径或文件ID的接口越权的关键测试习惯是不要只替换URL路径里的ID还要替换请求体、Cookie、Referer里的标识。很多系统把用户标识放在一个加密参数里表面看没有越权但有些参数是“用户可控”的替换掉就变了身份。4.2 SSRF及其转化高危漏洞里的难度黑洞SSRF服务端请求伪造指的是服务端替用户发起了一个网络请求而目标地址可以由用户指定。最常见的触发点是图片抓取、URL转码、PDF生成、Webhook回调。如果你传一个内网地址或者云元数据地址进去服务端真的去请求了那就出问题了。SSRF挖掘的核心说穿了就是回答两个问题服务器会不会访问我指定的URL访问之后结果会不会回显给我如果都不回显可以考虑用DNSLog验证请求是否到达如果回显直接查看响应内容判断能读到什么。在2026年很多SSRF点被加了SSRF防护比如限制内网IP。但绕过思路比防护规则多IPv6映射、十进制IP、URL重定向、DNS解析到内网……这套攻防会一直持续下去。4.3 文件上传绕过比想象中多得多的高危口文件上传漏洞在SRC里属于“老牌高危点”。特点是利用条件不一定高但一旦getshell就是直接打穿服务器。2026年的文件上传重点已经不在Content-Type绕过了而是以下三条线路白名单绕过允许上传jpg、png但服务器解析时支持图片马解析配置问题Nginx CGI解析、Apache多后缀解析内容检测绕过增加图片头、二次渲染绕过更常见的是厂商限制了Web根目录上传但忽略了对象存储Bucket的上传。一个可以任意上传文件的Bucket配合后续访问URL的未授权访问就是一条完整的高危链。4.4 反序列化与RCE类漏洞高风险高门槛反序列化漏洞特别是在Java、PHP体系里带来的直接结果往往是RCE远程代码执行。SRC里挖到这种漏洞赏金通常直接拉满。但门槛也摆在那里需要你对目标框架的漏洞利用链有深入研究比如Fastjson、Shiro、Log4j的利用特征。我的建议是如果你刚开始挖SRC不必强行死磕反序列化但要做两件事把指纹识别做扎实一旦在信息收集阶段看到目标系统暴露了已知反序列化组件版本立刻去查公开漏洞库看有没有现成的漏洞利用链可以参考。常态化关注公开漏洞情报新的反序列化漏洞出现后第一时间去Scope里搜一遍相同组件这个窗口期的漏洞最好挖。不要觉得这条路径太“运气”。事实上SRC里大量高赏金漏洞就是靠组件版本与公开漏洞的匹配打出来的。这属于“信息差”带来的机会谁跟情报跟得快谁就能吃到肉。5. 常见问题与排查技巧把踩过的坑都给你列出来5.1 测试环节中最容易翻车的地方我复盘了这几年自己做SRC时翻过的车挑几个最有代表性的说扫描器太激进触发厂商封禁IP。对策是限制扫描并发和速率优先用被动扫描把主动扫描控制到最低限度。测试数据污染了生产环境。你插入一条测试订单结果被真实用户看到了或者把优惠券发给了自己以外的账号。对策是只在测试账号、测试环境里做写操作读操作也尽量用无副作用的方式。误把厂商忽略的Bug当成漏洞提交导致信任度降低。对策是提交前做至少两次复现并对照SRC的已有规则确认不算重复。路径穿越和越权的边界没分清。有些目录穿越看似能读敏感文件但那个文件本身就是公开的这种情况下报告会被打回为“无实际影响”。5.2 实战中总结的几条独家技巧这些技巧是我自己从实际项目中沉淀出来的不一定写在任何文档里但确实经常帮我打开突破口抓包后先搜“userId”、“uid”、“customer_id”这类参数名如果出现了多半存在水平越权的机会。拿到一个Web系统第一时间看它的API文档入口比如Swagger UI、Knife4j、OpenAPI JSON这些文档会直接告诉你有哪些接口、需要什么参数省去大量逆向时间。遇到登录框别急着暴力破解先点“忘记密码”看流程里有没有验证码绕过、短信轰炸、响应包返回验证码这类问题。内网资产经常藏在“js/conf.js”这类文件里把JS文件内容全文拉下来搜索IP段、域名、Bucket地址经常比目录扫描收获更大。新上线业务比老业务更容易出问题。关注厂商SRC公告里的“新功能上线”、“服务变更”第一时间去测往往能吃到红利期。厂商修复漏洞后不要立刻放弃。看看是否只是简单加了个参数过滤很多过滤绕一次就能绕过去同一个漏洞点可能再次有效。5.3 报告被忽略之后怎么办提交漏洞后最尴尬的情况不是被判重复而是被忽略、长时间无回复。这时候我的做法是第一时间检查报告是否把复现步骤写清楚了如果描述含糊马上在工单里补充实验数据。如果是明显可稳定复现的高危问题但厂商态度冷淡可以在平台申诉渠道提交补充说明附带更完整的危害证明。不要在报告里写情绪化的话安全工程师也是人客观、专业、可协作的姿态反而更容易让漏洞被认真评估。说实话被忽略的问题大多数时候不是厂商不认而是你的报告让厂商无法高效验证。所以与其纠结厂商的态度不如把报告写得滴水不漏。最后说点实在话SRC漏洞挖掘这几年变化真的很快早几年靠一个Nmap扫描结果加一个弱口令就能交报告的时代已经过去了。现在能持续出高危漏洞的人靠的是三件事对外部攻击面的完整掌握、对漏洞原理的深度理解、对报告质量的严苛要求。我个人从2024年到现在最深的体会是不要痴迷于“一招鲜”也不要天天追着新工具跑。Nuclei、Xray这些工具确实能提高效率但漏洞真正的价值在于你对目标业务的理解程度。你越清楚一个系统里哪里藏着核心数据、权限边界在哪里、哪条链路可以被绕过你越容易找到别人看不到的高危点。2026年的SRC比拼的不再是“一天跑多少个目标”而是“能不能在正确的目标上用正确的方法打出有实际影响的漏洞”。希望这篇东西能帮你少走一些弯路至少在下一份漏洞报告里能让你少几分钟的犹豫多几分把握。
