企业官网建设流程全解析

这两年做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和443，MySQL 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挖掘的核心，说穿了就是回答两个问题：

1. 服务器会不会访问我指定的URL？
2. 访问之后，结果会不会回显给我？

如果都不回显，可以考虑用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，比拼的不再是“一天跑多少个目标”，而是“能不能在正确的目标上，用正确的方法，打出有实际影响的漏洞”。希望这篇东西能帮你少走一些弯路，至少在下一份漏洞报告里，能让你少几分钟的犹豫，多几分把握。