标题: "挖漏洞一个月赚2万多，别被骗了！"

我入行安全测试这行快十个年头，前两年开始认真跑漏洞赏金这条路，见过不少新人被一句“挖漏洞月入两万”带进来，也确实见过有人真的做到月入两万，但看清楚，那不是常态，更不是起点。我说“别被骗了”，不是劝退，是想把真实情况摆到桌面上，让被标题吸引进来的人看清楚：这条路能走，但不是躺着捡钱。

这篇东西写给三类人：想靠漏洞赏金赚副业的技术爱好者、刚入行想找方向的安全新人、以及纯粹好奇这行收入真相的路人。我会把漏洞挖掘的真实流程、收入构成、学习路线、暗坑和骗局套路一次讲透，能踩的坑我都替你踩过了。

1. 内容整体设计与思路拆解

1.1 “月入两万”的真实构成是什么

先直接回答标题里的质疑：一个月赚两万多块钱，这在漏洞赏金圈确实存在，而且不是个例，但你要看这笔钱是怎么构成的。

真实情况是，靠漏洞赏金月入两万的人，几乎都不是靠“挖到几个高危漏洞”实现的。他们的收入结构通常是这样的：

• 60%到70%来自长期维护的私有项目（Private Program），也就是和某些平台、厂商建立了信任之后持续提交的高价值漏洞；
• 20%到30%来自公开平台的中低危漏洞积少成多，靠数量堆上来；
• 剩下的是偶尔撞到的大奖，比如某个核心系统的远程代码执行漏洞，一个就顶过去三个月的量。

我自己见过最典型的例子，某位朋友连续两个月收入超过两万，后来细聊下来发现他在两个私有项目里深耕了半年，甚至把目标系统的每次版本更新日志都翻了一遍。这种钱看着轻松，背后是长期的投入。

所以“一个月赚两万多”这句话本身没骗人，骗人的是它没说全。它没说这个人之前积累了多久，没说人家手里的项目权限和情报优势，更没说这一个月里他可能连续熬夜测了几十个接口。如果以为注册几个平台、跑一遍扫描器就能月入两万，那被骗的就不是眼镜，是心态。

1.2 为什么漏洞赏金是一碗“硬饭”

漏洞赏金和普通副业最大的区别在于：它没有稳定产出，但天花板很高。接外包、写脚本、做运维这些活儿，做完一单结一单，虽然单价有限，但至少确定性很强。漏洞赏金完全反过来——你可能连续几周一无所获，也可能在一晚上发现一个影响成千上万用户的高危漏洞。

这个特性决定了它不适合当作唯一的收入来源，尤其是新手。我见过不少新人把退路断了，全职扑上去，三个月没出高危，心态直接崩掉。我的建议永远是：有本职工作的情况下，先把漏洞赏金当副业跑，跑出稳定输出能力之后再谈“全职”。这不是保守，是这行的客观规律决定的。

另外一个很多人忽略的点：漏洞赏金不是纯粹的技术活儿，它更像是情报分析加上侦察能力的综合考验。同样的系统，老手能挖到漏洞，新手扫半天一无所获，差别不在于工具，而在于思路。攻击面分析、参数追踪、业务逻辑理解，这些才是决定收入的核心。

1.3 哪些人会在这条路上被骗

说“别被骗”，核心要防的是三种骗局：

第一种是卖课骗局。包装成“零基础三个月学会挖漏洞月入过万”，卖你几千块的课程，内容全是公开文档里能搜到的常识。不是说所有课程都是骗局，而是那些把结果吹成确定性的课程，基本都有问题。

第二种是钓鱼项目骗局。打着“我们平台有大客户资源，加入我们团队一起挖”的旗号，收了入群费或者押金之后，所谓的项目根本不存在，或者只是一堆公开的低质量目标，利润分成永远算不清。

第三种是“包高危”骗局。承诺交了钱就带你挖到高危漏洞，保证收益分成。这种是最离谱的，因为真正的高危漏洞挖掘没有人能保证产出，说是包出高危，实际上要么是在边缘测试灰色地带，要么就是纯粹诈骗。

这三种骗局利用了同一个心理——对“快速赚大钱”的渴望。技术可以学，思路可以练，唯独这种心态如果不调整，早晚会被人收割。

2. 核心细节解析与实操要点

2.1 漏洞赏金平台怎么选：公开平台与私有项目的权衡

想做漏洞赏金，平台选择直接决定你的单点产出效率。目前主流的公开平台包括国内外的几个大平台，各自特点差异明显。

我给新手的建议是：先在国内大厂的SRC练手，因为资产公开、规则清晰、审核响应相对快，哪怕是低危漏洞也能积累信心的正反馈。等攒了十几份报告，再上公开平台打全球项目。

这里有个经验之谈：优先选那些“最近更新过资产范围的项目”。平台上有不少长期挂着的项目资产范围已经老掉牙了，所有公开的子域名都被挖穿了，你再去等于跟几百人抢骨头。反而是那些新上线或者刚扩展了范围的项目，目标资产新鲜，漏洞密度高，出成果的概率大得多。

2.2 攻击面侦察：决定成败的第一步

很多新手一上来就对着目标域名咔咔一顿扫描，这是最大的误区。漏洞挖掘不是扫描器游戏，真正拉开差距的是攻击面分析。

攻击面分析第一步是资产梳理。你不仅要看目标主域名，还要把子域名、IP段、移动端APP、小程序、第三方接口全摸出来。这一步常用的工具组合是子域名枚举加DNS记录分析，辅以证书透明度日志查询。我一般会把主域名、每个子域名的解析记录、Web服务指纹全部归档，画一张攻击面地图，再决定从哪儿入手。

第二步是技术栈识别。目标用的是什么中间件、什么框架、什么版本的组件，直接决定了哪些CVE可以利用。我见过不少系统用的是未升级的老版本框架，一个已知的公开漏洞就能打通，你根本不需要去挠头找什么零日漏洞。

第三步是功能点分析。通过注册一个合法账号进去逛一圈，把所有功能模块全部记下来，尤其是那些涉及文件上传、参数查询、密码重置、支付流程、权限切换的功能模块。漏洞往往不在你以为重要的模块里，而在边缘的、看起来不起眼的逻辑里。比如某个导出报表功能，参数里多了一个没有校验的字段，直接越权拿到了全部用户数据。

2.3 漏洞挖掘的核心思路：从扫描转向逻辑

思路转变是最关键的一步。新手和高手之间差的东西，本质上是好奇心和对业务逻辑的敏感度。

举个例子。一个典型的越权漏洞场景：系统有一个查看个人资料的接口，请求里带了用户ID参数。新手会把这个参数改一下试试，改成别人的ID，如果能返回别人的资料，就说挖到了一个越权漏洞。这个没错，但远远不够。

高手的做法是这样的：先正常走一遍业务流程，把所有请求记录下来。然后看每个请求的参数、Cookie、请求头，尤其关注那些隐藏参数、批量操作接口、分页参数。接着去思考“如果我是开发者，我会怎么实现这个功能”，通常开发者会在后端直接信任前端传来的某些值，比如角色标识、用户ID、文件路径，漏洞就藏在信任里。

我在测试某个模拟电商系统时，发现订单查询接口只校验了登录状态，没有校验数据归属。正常情况下这个接口只允许用户查看自己的订单，但我把订单ID参数改成另一个数字，直接返回了别人的订单详情，包括收货地址和手机号。这就是典型的水平越权，本质就是开发者默认“用户不会去改ID”。

这类逻辑漏洞占比很高，但扫描器几乎扫不出来。它要求你像一个测试工程师一样去理解业务流程，而不是像一个黑客一样去找漏洞特征。

2.4 报告撰写：漏洞价值的一半在报告里

很多人低估了报告的价值。同一个漏洞，两份不同的报告，审核员可能一份给出高危定级，另一份直接忽略。报告的核心目的是让审核员快速复现并理解影响范围。

一份合格的报告必须包含以下内容：

• 漏洞类型和影响资产：一句话说清楚是什么漏洞，出现在哪个URL或接口上；
• 复现步骤：从零开始、每一步都写清楚，最好带上请求包和响应包；
• 影响范围分析：说明这个漏洞能造成什么后果，能拿到什么数据，能控制什么操作；
• 修复建议：给出至少一个可落地的修复方案，比如参数校验、权限校验、过滤特殊字符等。

写报告有个常见误区：只贴截图不贴请求包。截图只能说明现象，请求包才是可以复现的凭证。有经验的审核员会直接看请求包里的关键参数，如果你连参数都没标注出来，他会觉得你连自己挖到了什么漏洞都没搞清楚。

另外，定级也很关键。报告提交之后，如果审核员第一次定的等级偏低，不要急着放弃，可以在补充说明里详细解释影响范围。我有个朋友曾经把一个XSS从低危申诉到高危，用的理由是这个XSS能打到管理员的Cookie，结合后台功能可以接管整个账号体系。影响范围一旦说清楚，定级自然会上去。

3. 实操过程与核心环节实现

3.1 从零开始：一套可复用的漏洞挖掘流程

为了让你更容易上手，我把自己的完整流程拆成一套步骤，每一步写清楚“做什么”和“为什么这么做”。

第一步：选择目标。如果你是新手，先选一个业务逻辑简单、功能模块清晰的小型目标，不要一上来就挑战大型电商系统或者社交平台的后台。小型目标的优点是攻击面小、容易吃透，适合训练完整的方法论。

第二步：资产梳理。将目标的所有子域名、IP、相关域名全部收集起来。使用子域名枚举工具跑一遍，再去证书透明度平台交叉验证一遍，最后用接口来分析解析结果。做完这一步，你会得到一张完整的资产清单。这里要补充一句：合法授权是第一前提，所有测试必须在平台明确允许的范围内进行，超出范围就是违法，没有任何商量余地。

第三步：指纹识别和漏洞探测。对每个Web资产做指纹识别，确定使用什么框架、什么中间件、什么版本。有了版本信息，你可以先在公开漏洞库里面查一下有没有已知漏洞，如果有，构造对应的验证请求去测试。这一步不需要深入原理，照着公开的PoC改改参数就能验证。但要注意：只做验证，不做利用。验证和利用之间有一条严格的红线——验证是证明漏洞存在，利用是获取数据或控制权限。前者叫测试，后者叫攻击，法律性质完全不同。

第四步：业务逻辑测试。注册一个普通账号，把目标的所有功能点用一遍，抓包记录每个请求。然后针对每个请求思考三个问题：这个参数能不能改？改了之后后端校验不校验？这个功能应该属于哪个角色，当前角色能不能访问？这三个问题是业务逻辑漏洞的核心方法论。

第五步：提交报告和复测。漏洞确认后，提交详细报告，和审核员保持沟通，及时补充他们需要的信息。修复完成之后再做一次复测，确认漏洞确实被修复。

3.2 一个完整案例：某商城系统的越权漏洞挖掘实录

我把一次完整的挖洞过程记录下来，用案例来说明整个流程怎么落地。

目标是一个模拟某商城商家的后台系统，功能包含商品管理、订单管理、用户管理、数据报表导出。拿到系统后，我先把商家后台的几个主要接口全部抓下来，逐个观察请求参数。

有一个接口引起了我的注意：订单导出的接口，参数里包含一个“shopId”（店铺ID）。正常逻辑下，当前商家登录后，后端会根据登录态返回当前店铺的订单数据，前端传的shopId理论上应该只等于自己店铺的ID。但问题是，后端有没有校验这个shopId和当前登录用户之间的绑定关系？

我的测试方式是：先用自己的店铺账号正常触发一次订单导出，抓包拿到请求地址，然后把shopId改成另一个数字（随便找一个可能的店铺ID）。响应结果直接返回了其他店铺的订单数据，包括交易金额、买家姓名、收货地址、联系电话。这是一个典型的水平越权漏洞，危害等级直接拉满。

这个漏洞的复现步骤非常简单，不需要任何工具，只要会抓包改参就能测出来。它反映出的核心问题是：开发者在设计接口时默认请求参数可信，没有在后端单独做归属校验。很多大型系统都有类似的问题，尤其在管理后台和报表导出这类边缘功能上。

从我的经验看，一个漏洞的价值不仅在于技术难度，更在于数据危害。拿到商家订单数据意味着可以精准掌握每一笔交易，这类数据通常会被定到高危或严重等级。

3.3 工具选择：哪些值得花时间配置

工具不是越多越好，而是越顺手越好。我自己的工具集精简到以下这些，各个都有明确用途。

首先是Burp Suite，这是Web安全测试的核心工具。最常用的功能是拦截代理、重放请求和自定义正则匹配规则。我习惯把Burp的代理和浏览器配合使用，所有流量都过一遍Burp，方便随时重放修改参数。另外一个常用功能是匹配和替换规则，可以自动修改请求头和参数，省去手动修改的过程。

其次是子域名枚举工具，我用的比较多的是Amass和subfinder，配合证书透明度平台做交叉验证。还有一个很实用的小技巧：用搜索引擎语法去搜目标域名的子域名和路径，经常能发现一些没有记录在DNS里的测试环境和内部地址。

然后是目录扫描工具，我用的是类似于dirsearch的开源工具。扫描目录的主要目的是发现隐藏的配置备份、未授权访问的接口和后台入口。但要注意：不要只扫默认字典。我会根据目标的技术栈定制字典，比如看到目标用的是某一款主流框架，就加入框架对应的默认路径和备份文件名。

最后是公开漏洞库和PoC集合，用它们来验证目标组件是否受到已知CVE的影响。需要特别提醒：利用公开PoC远程打目标，一定要确认目标是否在授权范围内，未经授权的一切探测行为都是非法的，这句提醒我必须反复强调。

3.4 漏洞定级和奖励标准：一个透明拆解

很多新手搞不清楚“一个漏洞到底能赚多少钱”，我按行业惯例给你做个大致拆解。不同平台和厂商的奖励政策不同，但一般可以参考下面的框架：

• 低危漏洞，几十到几百块钱，比如低危的XSS或者轻微的配置信息泄露。这类漏洞的奖励主要靠量，一个月攒上十几个低危，也有小几百到上千的收入；
• 中危漏洞，几百到两三千块钱，比如存储型XSS、部分信息泄露、不涉及核心数据的中等越权。这类漏洞比较吃思路，通常每周能稳定出几个中危就已经是不错的水平；
• 高危漏洞，几千到上万块钱，比如批量越权、SQL注入拖库、任意文件读取、远程代码执行等。高危和严重级别的漏洞才是月入两万的核心支撑；
• 严重漏洞，通常上不封顶，比如核心系统直接RCE（远程代码执行），登录后拿到服务器权限，或者核心数据库直接泄露。这类漏洞一个就能让当月收入达标，但出现的概率低得多。

我在某个平台连续测试两个月，记录下来的数据是这样的：第一个月挖到13个漏洞，其中9个低危、3个中危、1个高危，总计收入大约5000块；第二个月运气好，在某大型平台挖到一个严重级别的RCE链，直接进账2万多。这就是为什么说“月入两万确实存在，但它是非线性的”——前一个月的15个漏洞加起来，还不如第二个月一个漏洞的收入高。

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

4.1 新手高频问题速查表

我把这几年回答最多的问题整理成一张速查表，基本都是新手会卡住的地方。

4.2 我踩过的坑：三个典型教训

第一个教训是扫描器依赖症。我刚开始做漏洞赏金时，最喜欢做的事情就是把扫描器挂上，然后去看结果。那段时间产出极低，因为扫描器报告里80%都是误报，剩下的20%里大部分是重复发现，我真正需要做的是逐个人工确认，但那样时间成本极大。后来我转变思路，把扫描器当成辅助手段，把主要精力放在业务逻辑测试上，产出明显提高。

第二个教训是忽略低危漏洞。有一段时间，我只看高危以上的漏洞，觉得低危不值得写报告。后来和几个审核员聊天，才知道很多平台的低危漏洞也有积分积累，而且低危漏洞对于新手建立正反馈很重要。更关键的是，低危漏洞往往意味着某个业务模块存在逻辑缺陷，顺着低危往下挖，经常能发现同一个模块下的中危和高危。

第三个教训是在一个目标上死磕太久。有一次我在某个系统上连续测了一个多星期，所有能想到的方向都测了一遍，没有任何有价值的发现。后来我复盘发现，那个系统的安全加固做得非常好，前端和后端都做了严格的校验，继续死磕只是在浪费时间。正确做法是设定一个测试周期上限，比如单目标不超过三天，没有进展就换目标。这个时间管理策略能够帮你在同样时间内覆盖更多的攻击面。

4.3 识别漏洞赏金圈骗局的底层逻辑

文章最后再补充一个容易被忽视的识别点：真正的漏洞赏金圈子，没有人会主动拉你入群、没有人会承诺“包月入过万”、没有人会卖你“独家漏洞线索”。这些东西都违背漏洞赏金的基本逻辑——真正有价值的挖掘能力只来自大量的测试实践，而不是任何内部消息。

合规红线也要在这里说清楚：整个漏洞赏金工作必须在合法授权框架内进行。国内外的正规漏洞平台，都会在项目页面上标明允许测试的资产范围、禁止测试的行为、以及报告提交的规则。超出范围的一律不能碰，未经授权的测试属于违法行为，轻则封号，重则承担法律责任。这不是恐吓，是每个从业者必须遵守的底线。那些吹嘘“拿来就测，什么都能挖”的人，不是在教你技术，是在拉你下水。

愿意沉下心来做这件事的人，我的建议是先设定一个小目标：三个月内，连续在公开平台提交不低于20份有效的漏洞报告。这20份报告会让你真正理解爬虫和爆破之间的区别，理解参数篡改和业务逻辑之间的关系，理解为什么有些高手扫一个接口就能判断出它有没有漏洞。等你跑完这20份，再回头看看那些“月入两万”的宣传，心里自然会有答案。

最后分享一个我自己的习惯：每次提交完一份报告，不管定级高低，我都会花十分钟记录一下这次的测试过程、遇到的问题和突破点。积累到一百份的时候翻回去看，你会看到一条明显的成长曲线，那种实打实的进步感，比任何夸大宣传都真实得多。