漏洞挖掘完整入门路线：从SRC基础到稳定提交漏洞赏金的实战指南

先说个实在话：漏洞挖掘这个方向，确实能赚钱，也确实有人靠它把生活费包圆了。但它绝不是那些速成课吹的“零基础三天赚零花”，它是一门需要系统学、守规矩、慢慢积累的手艺。我见过不少新人上来就问怎么黑网站，也见过踏踏实实学了半年、后来稳定拿到漏洞赏金的普通开发者。同样是挖漏洞，差别不在天赋，在有没有走对路。

这篇文章按我自己一路走下来的经验展开，把从入门到稳定提交漏洞的完整路径写清楚。适合几类人看：想靠技术赚点外快的开发者、安全专业的学生，以及刚接触厂商SRC却不知道怎么下手的自学者。我会少谈空理论，多讲能落地的步骤、思路和判断标准。

1. 先别急着学攻击：漏洞挖掘的赚钱逻辑和合法边界

1.1 漏洞是怎么变成钱的

漏洞挖掘的本质，是一个“找错—报告—修复—领赏”的循环。一家公司上线了网站、App、小程序，无论开发阶段测试多充分，线上总会有疏忽。比如某个接口只校验了登录状态，没校验用户身份，普通用户改一个参数就能查别人的订单，这就是典型的越权漏洞。发现这种问题的人，在厂商授权范围内把它提交给官方，官方确认后按危害程度支付赏金，整套流程就是漏洞赏金。

变现渠道目前主要是两条。一是厂商自建的SRC安全应急响应中心，直接对应它自家的产品，赏金相对平稳；二是第三方众测平台，聚合了多家企业的测试任务，按项目报价，机会更多但竞争也更激烈。新人往往纠结去哪边，我的建议是先选一个，把基础打牢，两边其实都有钱赚，重点是先把“能稳定发现漏洞”这一步走稳。

1.2 授权是生命线，这句话必须放在最前面

所有合法赏金都建立在“授权”二字上。厂商允许你测试的范围，会写在他的SRC首页或项目说明里，包括哪些域名、哪些业务、哪些时间段。超出这个范围，哪怕你是善意的，从严格意义上也属于未授权操作。这不是道德绑架，而是实实在在的自我保护。

圈子里有过一个非常典型的反面案例：A同学在某众测项目里，发现一个子域名允许测试，就顺着子域名的关联信息，连到了厂商一个没有授权的内部系统，顺手试了一下绕过，结果厂商直接进入维权流程。后来虽然没有造成破坏，配合调查免于更严重的追究，但这个方向的路基本就断了。所以我给自己定了一条硬规矩：每测一个项目前，把范围列表截图存档，测试过程中只动授权目标，绝不横向扩散。

1.3 认清你在这条路上能拿到什么

除了钱，漏洞挖掘还能带来三样东西。一是实战技术能力的快速提升，这种提升是日常工作很难给你的，因为你要同时理解业务逻辑、代码实现和基础设施。二是行业信用积累，一份高质量的报告比任何简历都更有说服力，审阅人看到你的名字就知道你靠谱。三是问题解决思维，你在测试中反复验证、推理的过程，本质上和开发调试、架构设计是同一种能力。

把这些想清楚，你就不容易被短期收益少、进度慢带偏，也更清楚自己为什么坚持做这件事。很多中途放弃的人，不是技术不行，是预期出了偏差，以为挖洞等于捡钱。

2. 环境准备：先把基本功按在地上摩擦

2.1 本地靶场：唯一可以随便打的地方

很多人一上来就想拿真实站点练手，这是大忌。正确做法是先在本地搭一个靶场环境。圈内常用的开源Web靶场，自带SQL注入、XSS、文件上传、命令注入等常见漏洞场景，配合本地服务环境，装起来不超过二十分钟。这类靶场的意义，就是提供一个可以随便折腾的试验田，任何操作都不会带来现实风险。

搭靶场的同时，强烈建议准备一台专门的虚拟机。为什么？因为漏洞利用过程中要改各种配置、装一堆工具，系统很可能被搞坏，虚拟机快照点一下就能恢复，不用从头配置。本地环境的稳定性，直接决定你练手的效率和心态。我自己的习惯是：装好干净系统做一份快照，装好靶场再做一个快照，玩坏就回退，几乎不花时间处理环境问题。

2.2 必须掌握的四项基础技能

想进这个门，不需要先精通网络工程，但下面四项技能避不开，建议按顺序掌握。

第一，HTTP/HTTPS基础。请求方法、请求头、响应状态码，至少要能看懂浏览器开发者工具里“网络”标签的内容。很多漏洞之所以发现不了，就是因为根本没看清请求头里藏了什么信息。

第二，Web前端基础。HTML和JavaScript不需要写出多漂亮的页面，但你要知道数据是怎么从页面发送到后端的，前端校验能不能被绕过，参数为什么会出现在URL或者请求体里。

第三，一门后端语言的基础。PHP、Java、Python都可以，我建议从Python入门，因为后面写脚本、跑自动化、分析数据都离不开它。

第四，数据库常识。知道SQL是什么，一条查询语句大概怎么执行，常见的表结构长什么样，就够了。注入类漏洞几乎都和SQL相关，没有这个底子，你在真实目标上只会对着工具发呆，不知道它返回的数据意味着什么。

2.3 准备一套够用的工具清单

工具不需要多，但每个都要会用。我自己的最小工具集包括：抓包代理用Burp这类主流工具，负责拦截、修改、重发请求；目录扫描用常见的字典扫描工具，找出隐藏的接口和文件；子域名收集用开源的收集脚本加一份质量高的字典，把目标周边信息摸全；浏览器建议准备两个，一个日常用，一个专门跑测试环境，避免配置互相干扰。

这里提醒一句：工具是放大你的能力，不是代替你的判断。很多新人跑完扫描器，拿到几百条结果，却不知道哪些是真漏洞，哪些是误报。原因就在于没有手工验证的能力。所以我的顺序始终是：先手工理解请求和响应，再上工具提速，最后手工确认结果。

3. 核心漏洞类型：最容易出赏金的五个方向

安全圈有句老话：百分之八十的漏洞，来自那几个经典类型。刚入门不需要每个领域都深钻，先把下面五类搞明白，你就能覆盖大部分提交场景。

3.1 信息泄露：最不起眼却最容易拿到赏金

很多赏金猎人的第一桶金，来自信息泄露。前端源代码注释里残留的测试接口、错误页面完整暴露的堆栈信息、云端对象存储开放了列表权限、版本控制仓库被公开拉取，这些都算信息泄露。它们单个看危害不大，却往往帮你找到后台地址、接口密钥、内网网段，从而让单一低危漏洞升级成中危甚至高危。

实操思路很明确：先做子域名收集，再对目标做目录扫描，把响应里带“password”“token”“debug”“test”等关键词的页面重点挑出来看。发现存储桶权限问题时，不要急着下载全部文件，先截图确认可列举，记录测试日志，然后立刻停止。你提交的是“证明存在风险”的证据，而不是把厂商数据打包带走。

3.2 越权漏洞：两个账号就能验证

越权是Web业务里最常见的逻辑漏洞，也是新手最应该优先掌握的。它分两种：水平越权，普通用户A能访问普通用户B的数据；垂直越权，低权限用户能干高权限用户的事。几乎所有带用户体系的业务，都值得花时间测一遍越权。

验证方法很朴素：注册两个账号，或用一个账号通过抓包工具修改请求里的ID参数、用户标识字段，看响应是否返回了不属于自己的数据。为什么这类漏洞这么多？因为很多开发只做了“登录校验”，没做“身份校验”。你登录了就能访问接口，但接口没判断这个ID是不是你的，改一下就能看到别人的内容。

这类漏洞的报告价值关键在于证据链完整。用账号A登录，正常请求返回自己的数据；把ID改成账号B的，返回了B的数据；两张截图一对比，危害一目了然，审阅人不会质疑。

3.3 注入类漏洞：理解原理比跑工具更重要

注入类漏洞的本质，是把用户输入当成代码去执行了。最常见的SQL注入，是后端把参数直接拼进了SQL语句；命令注入，是后端把参数拼进了系统命令。你想想，一个原本应该当数据处理的东西，结果被当成了程序逻辑执行，后果自然严重。

这里必须强调一个原则：工具可以帮你加速，但不能替代理解。不少人下载自动化注入工具直接跑，跑出一堆“扫出了漏洞”的结果，却说不清哪条能证明漏洞存在，哪条是误报。更好的学习路径是：先在本地靶场手工执行一遍注入，观察数据库返回怎么变化，再上工具验证。等你理解了返回差异背后的逻辑，真遇到验证不出来的情况，才知道是工具没识别对，还是参数位置不对。

实操中我自己验证SQL注入，最看重的是“闭合”这个概念。后端把参数拼进SQL语句，前面有单引号或括号，后面也有，你要做的是把当前的语句闭合掉，再决定后面跟什么。不懂闭合，工具给你的结果就是一堆黑盒反馈，你根本没法判断它有没有真正执行成功。

3.4 XSS、CSRF、SSRF：三类Web经典问题

这三类漏洞可以放在一起学，因为它们都和“请求”有关。XSS是攻击者往页面里注入了前端脚本，利用的是浏览器对网站的信任；CSRF是攻击者诱导受害者发起非本意请求，利用的是服务器对浏览器身份的信任；SSRF是服务器端发起了攻击者控制的请求，利用的是内网服务对外层访问的不设防。

入门阶段，XSS先在本地靶场练习弹窗验证就好，真实环境不要做破坏性操作，更不要拿真实用户的会话去做持久型验证。CSRF一般需要讲清楚影响场景，比如改密码、改邮箱类的CSRF，价值比点赞类的要高得多。SSRF的价值在于探测内网信息，但检测时必须控制深度：能证明可访问内网某个地址就够，继续向内网渗透是绝对禁区。

3.5 文件上传与验证绕过

文件上传漏洞一般出现在头像、附件、导入功能点。核心问题是后端只校验了文件后缀或Content-Type，没校验文件内容，导致攻击者上传了可执行脚本。验证时，在本地靶场熟悉常见的扩展名、内容校验绕过方式，真实环境里做到“证明可上传非预期类型文件”即可，绝对不要上传真实可执行的恶意文件去拿下权限。那一步跨出去，性质就完全变了。

4. 漏洞提交：从发现到领赏的最后一公里

4.1 报告模板：这样写通过的几率最高

发现漏洞只完成一半，另一半在报告里。一份专业报告至少包含：漏洞标题、测试地址、测试时间、漏洞类型、危害等级、复现步骤、修复建议、截图证据。

标题要让审阅者一眼看懂要害，比如“XX接口存在水平越权漏洞，可遍历任意用户订单”，而不是“某个系统有bug”。复现步骤要能无脑执行，我一般分步写清：准备什么账号、打开哪个页面、抓包改哪个参数、看到什么结果。截图要带时间戳和地址栏，关键返回数据用红框标出。

举个例子，我提交过一份越权报告，标题写“某平台用户信息接口水平越权，可遍历任意用户手机号”，复现步骤写得很短：

• 用测试账号A登录，抓包访问个人信息接口，记录正常返回。
• 将请求中的用户ID参数从A的ID改为B的ID，重新发送。
• 返回包中包含B的姓名、手机号、收货地址，截图与请求时间一并附上。

这四步写清楚，基本没有审阅人需要追问的地方。这样写不只是帮审阅人省时间，更是保护自己——你证明了自己只做了验证性测试，没有多余的越界动作。

4.2 危害等级判断：影响范围决定单价

同样一类问题，影响范围不同，赏金完全不同。一个只影响测试域名的反射型XSS，和一个能遍历线上用户订单的越权漏洞，赏金可能相差十倍。提交前先判断两点：第一，这个功能在业务里占什么位置，是核心账务、用户隐私，还是一个边缘页面；第二，漏洞能影响多少用户，能不能批量操作、遍历数据。

新手常见的失误，是把高危报成低危，或反过来把低危吹成高危。前者损失收入，后者损害信任。不要只看漏洞类型下结论，要看实际业务场景。能批量操作、能波及敏感数据、能影响账户的地方，哪怕类型很老，也是重点目标。

4.3 “内部已知”与重复提交：先查再报

标题里提到的“内部已知”，是我真真切切踩过的坑。很多厂商收到报告后会回复“该漏洞内部已知，正在修复中”，如果漏洞是内部先记录过的，这次提交很可能不计入赏金。这意味着两件事。

第一，提交前先查厂商公告和漏洞通告列表，有些已知问题不值得再提。第二，提交要趁早，同一个漏洞你晚几个小时，可能就有人抢先报告了。我自己养成一个习惯：发现一个点，证据整理好，当天就提交，绝不拖过夜。

如果厂商回复“内部已知”，别太在意。这是行业常态，不代表你能力不行。把这次测试的思考路径记下来，换个目标继续。同时注意，重复提交通常不发赏金，但有些平台会记录活跃贡献，用于后续的评级和邀请。

4.4 报告被驳回之后，还有一次补救机会

第一次提交被驳回，很多人会沮丧，其实驳回意见里藏着大量信息。我把常见的驳回原因整理成了表格，方便你对照自查：

我处理驳回的习惯是：把驳回意见存档，每个季度翻一遍，你会发现自己的低级失误在快速减少。

5. 从入门到精通的进阶路线：三阶段走法

5.1 阶段一：能稳定提交有效漏洞

这个阶段的目标不是挖出惊天大洞，而是让“提交漏洞的有效比例超过七成”。方法是盯住一类漏洞，找一个安全响应渠道完善的目标，在授权范围内反复测试。每测一个点都要复盘：为什么我没想到这个参数？还差哪些信息收集？把这个循环走二十遍，基本就能摆脱新手的生疏感。

我在这个阶段最受益的动作，是给自己建漏洞测试清单。每次遇到新类型的洞，就把测试方法、关键参数、绕过思路记下来。几个月后你会发现，很多新系统上的问题，其实都在老笔记里见过类似影子。

5.2 阶段二：聚焦细分方向，进入众测实战

入门之后，不要再东一榔头西一棒。建议结合你的兴趣和技术栈，选一个细分方向深钻。有人专攻支付流程，有人专攻企业管理后台的越权，有人专攻小程序接口。细分方向有明显优势：当你对某个业务逻辑足够熟悉，你能发现别人发现不了的逻辑漏洞，这类漏洞的赏金往往最高。

这个阶段可以开始接触第三方众测平台的实战项目，从评分低、范围小、目标经典的项目练起，逐步提高难度。同时培养写自动化小脚本的习惯，比如写个十几行的请求脚本，读取接口参数列表，自动替换请求里的ID，再比较响应内容差异。不需要多复杂，能把重复劳动替换掉就够了。注意自动化脚本也要控制频率，瞬间高频请求既容易被打上异常标签，也可能误伤目标业务。

5.3 阶段三：代码审计与漏洞研究

往更高层级走的近路，是代码审计。拿到一套开源项目的代码，通过阅读源码找漏洞，比纯黑盒测试多了一层确定性。审计入门，可以从常见框架的应用项目入手，先看它们的补丁记录：哪个版本修了什么漏洞，对照修复位置思考原漏洞怎么利用。拆过二三十个补丁后，你对漏洞成因的理解会上一个台阶。

到了这个层级，日常生活费级的赏金已经不是主要目标，重点变成积累行业影响力。定期写漏洞分析文章、参与平台组织的排行榜、在授权范围内做深度研究，都能帮你建立长期价值。这条路没有终点，但每一步都能看得见成长。

6. 常见问题与避坑实录

6.1 新手的十大典型失误

我梳理了带人过程中最常见的失误，你可以对照自查：

1. 不读SRC规则，没确认测试范围就开始瞎试。
2. 工具跑出一堆结果，分不清真漏洞和误报。
3. 验证漏洞时越做越多，从“验证”滑向“利用”。
4. 报告太口语化，步骤缺失，审阅人复现不出来。
5. 截图不带上请求地址和时间，仲裁时很难自证。
6. 遇到“内部已知”就放弃，不总结原因。
7. 只测技术类型，不测业务逻辑。
8. 提交前不查重复，白忙一场。
9. 轻视低危漏洞，总想一口吃个胖子。
10. 本地靶场都没玩明白，就急着冲真实目标。

这十条看着简单，能全部做到的，已经不多了。

6.2 合规红线的自检清单

每次测试结束、提交报告前，我都会过一遍下面这个清单。

授权范围确认了吗？只测了授权的域名和业务吗？没有下载或删除目标数据吗？没有使用自动化工具做超大规模请求吗？没有访问或截取超范围内容吗？所有操作都有日志和截图留证吗？

任何一项不确定，我都会在报告里主动说明，而不是藏着。合规不仅是对平台负责，更是对自己负责。安全行业的口碑，就是靠这些细节堆出来的。

6.3 心态和习惯：决定你能走多远

最后聊点实在的体会，技术之外，有三个习惯让我受益最大。

第一，耐心比技术重要。测一个接口，试了一百个参数没反应，第一百零一个才灵光一现，这才是常态。烦躁的时候，恰恰是最容易错过机会的时候。

第二，写笔记是复利工具。我从第一天起就维护自己的测试笔记，记录接口规律、参数套路、鉴权方式、绕过手法。后来发现，很多新目标的核心点，都在旧笔记里能找到影子。

第三，别把全部精力押在挖洞赚钱上。挖洞更好的定位，是放大你的技术能力、帮你建立行业信任的一部分。真正长期值钱的，是你对系统本质的理解。赏金可以带来正反馈，但别让它变成你唯一的驱动力。

最后再分享一个小技巧：进一个新的SRC平台，先把它的历史漏洞公告通读一遍。厂商修复完漏洞，往往会在附近留下可以被探测的痕迹，那些痕迹很多时候就是下一个漏洞的线索。我就是靠这个习惯，拿到了不少有效报告。希望这篇内容帮你指了方向，剩下的路，还得靠你自己一个个请求、一张张截图走出来。