漏洞提交、公益SRC平台、奖金，这三个词凑在一起，是不少人入行的第一动力。我自己当年也是靠一个公益SRC平台把“零基础”这三个字硬熬过去的：不会写代码，看不懂数据包，第一次交报告被驳回三次，第一次拿到奖励只有几十块，还是积分换的。所以这篇文章不打算给你灌鸡汤，也不打算把平台帮助文档抄一遍，而是把我从完全摸不着门到能稳定出报告的过程拆开讲：这门生意到底怎么运转，零基础该先补哪几块，第一次提交要怎么走完闭环，报告怎么写才不被秒退，以及那些没人明说、但踩过一次就记住的坑。

文中提到的平台，国内有好几家在跑类似的公益模式，下面统一用“公益SRC平台”指代，不针对具体某一家，规则细节各家有差异，以你注册后看到的官方文档为准。看完这篇，你应该能自己判断两件事：这条路适不适合我，适合的话第一步该做什么。

1. 先搞清楚这门生意的运转逻辑

1.1 厂商、平台、提交者三方各拿什么

公益SRC平台的本质是一个中间撮合层。厂商把自己的一部分业务系统登记进平台，形成一个“允许被测试”的资产范围；提交者在范围内找问题，把过程写成报告提交；平台负责审核、去重、定级，然后把有效报告转给厂商，厂商修复后回填状态，平台按定级结果发放积分或奖励。这条链路上没有一方是白干活的，理解各自的动机，你才知道自己该产出什么东西。

厂商的动机很直接：一个线上业务在上线前做过测试，但业务会改、接口会加、第三方组件会老化，总会有遗漏。与其等出问题后被被动处理，不如主动开一个口子，把外部视角引进来。修复一个刚被发现的隐患，成本通常远低于事后处置，这是它愿意付奖励的根本原因。平台的作用是把这种零散的“外部视角”标准化：统一收口、统一评级、统一披露节奏，避免提交者直接找到厂商造成混乱。

提交者拿到的回报分几种形态：积分、Ranking排名、现金奖励、证书或致谢。低危问题多数只有积分，中高危才有现金，这是行业普遍情况。你要早点接受这一点，否则很容易在提交了十几个“信息泄露”之后心态崩掉。

1.2 零基础要先建立的四个认知

第一个认知：找漏洞不是“变魔术”，是“找差异”。任何一个功能都有设计者预期的行为，实际表现和预期不一致的地方，就是问题的入口。你不需要背下几百种攻击手法，你需要的是养成一个习惯——每看到一个输入框、一个接口、一个按钮，先问一句“如果我不按它的规矩来，它会怎么反应”。

第二个认知：八成时间花在信息收集和排除上，真正“打进去”的那一刻很短。很多新手以为高手是手速快，其实是筛选快：他能迅速判断这个资产值不值得花两小时，而这个判断力来自大量无效尝试的积累。

第三个认知：报告质量直接决定你的收入，不是漏洞本身单独决定。同一个问题，A写成三行字，B写成带复现步骤、请求响应、影响链路、修复建议的完整文档，审核结论可能差一个等级。

第四个认知：收益曲线前期是平的。前三个月零收入非常正常，因为你在交学费——学费的形式是被驳回、被标记重复、被判定为非漏洞。这不是平台苛刻，是你在补齐别人已经交过的那部分。

1.3 平台规则里必须提前读透的三份文档

注册完账号第一件事不是去找目标，是读文档。每个公益SRC平台都有三份东西必须看：提交规范、评级标准、禁止行为清单。提交规范告诉你一份报告要包含哪些字段，缺一个字段就可能被判“信息不完整”直接退回；评级标准告诉你低危中危高危严重分别怎么界定，这决定了你的收入预期；禁止行为清单则划出了红线，比如禁止对非授权资产测试、禁止下载或留存真实数据、禁止使用自动化扫描对业务造成压力、禁止在修复前公开细节。

我见过太多人卡在第一步：报告写得挺用心，但没写“影响资产”和“复现环境”，审核员照着步骤复现不出来，只能退回。这不是运气问题，是没读规范。

不同平台的奖励结构大致可以参照下面这张表来理解，注意具体数值各家差异很大，这里只给形态，不给承诺：

提示：把“我能不能拿到钱”换成“我这份报告能不能被复现”，你的通过率会有明显变化。

2. 上场之前要把地基打牢

2.1 授权边界这件事，怎么强调都不过分

漏洞提交这件事，唯一的护身符就是“授权”。平台的资产列表里写明了哪些域名、哪些子域、哪些端口在范围内，范围外的东西你连一个请求都不该发。这里有几个新手常忽略的细节：主域名在范围内，不代表它的所有子域名都在；子域在范围内，不代表它指向的第三方托管服务在范围内；一个页面能打开，不代表这个页面属于该厂商，很多业务会挂在合作方的域名下。

测试过程中如果意外看到真实用户数据，正确做法是立刻停止，只截取能证明问题存在的最小片段，对敏感字段打码，并在报告里明确写“仅验证返回结构，未下载、未留存任何数据”。这句话不是形式主义，它是区分“协助修复”和“越界”的分水岭。

还有一条经验：不要在业务高峰期做任何可能产生大量请求的操作。手工点几下和脚本跑几千次，对业务的影响完全不同，后者很容易被判定为对业务造成干扰。

2.2 工具选型：先用顺手的，别一上来堆一车

零基础最容易犯的错，是先把网上流传的工具包全下载一遍，结果一个都不会用。我的建议是分三层来配：

抓包代理工具的选型上，重点看三个能力：能不能方便地重放请求、能不能保存请求历史、能不能对请求做批量对比。至于界面好不好看，真不重要。笔记工具建议就用最普通的表格，字段固定为：资产地址、发现时间、问题类型、请求方法、关键参数、当前状态。这张表会伴随你整个入门期，后面复盘全靠它。

另外准备两个普通注册账号和一个独立邮箱。很多问题需要两个身份交叉验证，只有一个账号你会发现寸步难行。

2.3 三个月的学习路径，按周拆给你

第一个月只做一件事：看懂一次完整的请求响应。打开开发者工具，随便找一个带表单的页面，提交一次，然后在网络面板里找到那条请求，逐字段看清楚：请求行写了什么、请求头带了什么、请求体的参数名和值是什么、返回的状态码和内容是什么。然后把其中一个参数改掉再发一次，观察返回变化。这个动作重复两周，你对“数据是怎么在浏览器和服务器之间流动的”就有实感了。

第二个月开始碰接口。养成看前端脚本的习惯，很多接口地址、参数名、权限判断逻辑就写在脚本文件里。找到接口之后，用抓包工具重放，尝试改参数、改身份标识、去掉某个字段、加上某个字段，观察哪些改动会让返回结果发生变化。变化就是线索。

第三个月按问题类型逐个攻。一次只研究一类，比如这一周只看权限类问题，下一周只看信息返回类问题。集中攻一类的好处是，你能快速建立这一类问题的“模式识别”，看到相似结构就有直觉。贪多嚼不烂，什么都看一遍等于什么都没学会。

练习环境不用愁，自己在本机搭一套简单的练习系统就行，网上有大量公开的练习靶场可以本地部署。在练习环境里把动作练成肌肉记忆，再去真实资产上做，效率和成功率完全是两个量级。

注意：练习环境里可以随便折腾，真实资产上必须“最小验证”。这两者的操作尺度不能混。

3. 第一次提交的完整闭环怎么走

3.1 目标选择：新手该挑什么样的资产

选目标的核心原则是“竞争小、结构简单、能快速拿到反馈”。公益SRC平台上，大厂核心业务的值守强度很高，你花两周找到的东西，很可能已经被别人提交过几十次，撞重复的概率极大。新手更合适的入口是中小厂商的边缘业务：活动页、招聘页、老版本系统、企业内部使用的对外入口、小程序背后的接口。

判断一个资产值不值得投入，我有几个粗糙但好用的标准：页面样式明显老旧、功能入口藏得深、没有统一的登录体系、接口返回里带着调试信息、访问速度慢且偶尔报错。这些特征背后往往对应着“长期没人维护”，而没人维护的地方，问题密度通常更高。

另外一个反直觉的建议：别一上来就盯着“高危”。高危意味着高竞争，新手拼不过。先从低危做起，练的是流程、写报告的手感、和审核沟通的节奏。等到你连续五份报告都被顺利通过，再去碰需要链条组合的复杂问题。

3.2 信息收集的具体做法

信息收集不是漫无目的地扫，它是有明确问题导向的。你要回答四个问题：这个厂商有哪些对外资产、这些资产分别跑着什么技术栈、每个资产上有哪些功能入口、这些入口接收什么参数。

整个过程要落表，不要靠脑子记。我自己的表里除了基础字段，还会加一列“可疑程度”，用高中低标一下，测完就更新。一天下来你可能有三十条记录，第二天打开表就知道该从哪条开始，而不是重新翻一遍。

3.3 四类低门槛问题的验证思路

权限类问题是最适合新手的。核心动作就一个：用A账号登录，拿到属于A的一条数据访问地址，然后换成B账号的身份去访问同一条地址，看能不能拿到A的数据。水平和垂直两个方向都试一遍。判断是否有效，看的是“返回内容是不是另一个身份的数据”，而不是“页面有没有报错”。很多系统会返回一个空的成功页面，这不算问题。

信息返回类问题靠对比。同一个接口，正常请求返回的字段里是不是多出了不该给前端的东西，比如内部编号、手机号、地址、备注字段。这类问题最容易误报，判断标准是“这个字段是否属于敏感信息，且当前身份本不该看到”。返回一个内部自增ID，往往不算；返回一整套联系方式，就算。

逻辑缺陷类问题靠“不按流程走”。正常下单要点三步，你试试直接跳到第三步；正常领取一次，你试试重复提交；正常数量是1到10，你试试提交0或者负数。判断标准是“业务结果是否发生了不该发生的变化”，比如额度增加了、状态被跳过了、限制被绕过了。

前端校验类问题最好认。页面上的按钮点不动、下拉框里没有某个选项、输入框限定了长度——这些限制如果只发生在浏览器里，那服务端大概率没做同样的检查。验证方法是把请求拦下来，直接改参数重发，看服务端认不认。

这四类问题占了我入门期八成以上的有效提交，不需要复杂工具，需要的是耐心和重复。

提示：任何一次验证，只要出现了“返回了超出预期的数据”或“状态发生了不该发生的变化”，立刻停止，截最小证明，不要继续深入。

3.4 验证、取证与最小化原则

验证的目标不是“把危害做到最大”，而是“证明危害存在”。这两者的区别，新手经常搞混。前者会让你越界，后者才是职业做法。比如一个接口能返回别人的信息，你验证一条就够了，不需要写循环把整页数据取下来；比如一个上传入口没有限制类型，你传一个无害的文本文件证明校验缺失就够了，不需要传任何有实际影响的内容。

取证要包含这几样东西：完整的请求地址、请求方法、关键参数原文、返回内容的关键片段、操作时间、使用的身份标识。截图时把账号标识、令牌、手机号这些打码，但保留能证明问题的字段。如果步骤比较长，录一段屏幕视频比十张截图更有说服力，审核员最怕的就是“步骤写了八条，但第几条到第几条之间断了”。

还有一个细节：把你测试时用的账号和密码写进报告，或者提供一个专门用于复现的测试身份。很多报告被退回的原因是“需要登录，无法复现”。

3.5 一份能让审核员少问三句的报告长什么样

报告不需要文采，需要的是“任何人照着做都能重现”。我用的模板大概是这个结构：

## 漏洞标题 [资产名称] + [功能点] + [问题类型]，一句话说清是什么 ## 影响资产 完整地址（含参数），标注所属业务 ## 问题类型 权限类 / 信息返回类 / 逻辑缺陷类 / 前端校验缺失 ## 复现步骤 1. 使用账号 A 登录，访问 xxx 2. 拦截请求 xxx，将参数 xxx 修改为 xxx 3. 重放请求，观察返回内容中出现 xxx ## 关键请求与响应 请求方法与地址、关键请求头、请求体（敏感值已脱敏） 响应状态码与关键返回片段 ## 影响说明 该问题可导致 [谁] 在 [什么条件下] 获取/修改 [什么范围] 的数据， 实际业务影响是 [具体描述，不夸大] ## 修复建议 服务端补充身份与归属校验；对返回字段做白名单过滤； 对操作频率与数量做服务端限制 ## 附件 截图 / 录屏 / 请求原文

这个模板里，我认为最值钱的是“影响说明”那一段。它决定了审核员怎么定级。写的时候要具体到业务，不要写“可能导致信息泄露”这种空话，要写“任意登录用户可通过修改订单编号查看他人订单的收货信息，包括姓名、电话、地址”。同时也不要夸大，把“能看到一个字段”写成“可获取全站数据”，一旦被核实不成立，轻则降级，重则影响账号信用。

4. 审核、定级与奖励的那些门道

4.1 报告被打回的六种典型原因

第一次提交被退回是常态，我前五份报告退回四份。把常见原因整理出来，你能少走很多弯路：

这里面最值得说的是“非漏洞”。新手常把“返回了一个内部编号”“错误页显示了框架名”“登录失败提示用户名不存在”当成问题提交。这些在多数平台的评级标准里属于加固建议，不构成有效漏洞。判断办法很简单：把自己放到厂商的位置上问一句“我会为这个专门发一次版本吗”，如果答案是“顺手改改”，那它多半不算。

4.2 定级逻辑：同一类问题为什么评级不同

平台定级看的是四个维度：影响范围、利用门槛、是否需要交互、数据敏感程度。同样是越权，能越权看一条自己的测试数据，和能越权看全部用户的订单，评级差好几个档。同样是逻辑缺陷，需要精心构造条件才能触发，和随便点两下就能重复领取，也不是一个级别。

想把定级往上提，靠的不是形容词，是证据。你要能把“影响链路”讲完整：谁能利用、需要什么前提、能拿到什么、影响多少人。这个链路讲得越清楚，审核员判断起来越省力，你的报告就越容易被认真对待。

反过来说，最忌讳的是“为了提级而编造链路”。比如把一个需要管理员权限才能触发的问题，描述成“任意用户可利用”，一旦审核方核实前提不成立，这份报告很可能被直接判为无效，甚至影响你后续提交的信任度。

4.3 有异议怎么沟通

对定级有异议很正常，尤其是你觉得影响被低估的时候。沟通的正确姿势是：先自查，再补材料，最后一次性说清。自查是看自己的报告是不是漏了关键证据；补材料是把复现步骤、影响范围的补充证明附上；一次性说清是把观点集中在一段话里，别来回拉扯。

沟通时的语气很重要。审核员一天要看几十上百份报告，客气、简洁、就事论事的沟通效率最高。反过来，在评论区反复争论、拿别的平台的定级来比较，基本不会有好结果。我自己的经验是，凡是能靠补一段证据解决的问题，都不要靠争论解决。

5. 常见问题速查与效率提升

5.1 新手高频问题速查表

5.2 从碰运气到有方法：三个能立刻用的习惯

第一个习惯是建“资产台账”。所有测过的资产、测过哪些功能、结论是什么，全部记下来。这件事的价值在于，你不会重复劳动，而且当你学会新手法之后，可以回头把旧资产再过一遍，往往能翻出之前漏掉的东西。我的台账里有一列叫“待复测”，攒到十几条就集中过一轮。

第二个习惯是只攻一类问题，攻到形成条件反射为止。比如这个月只看权限，看到任何带用户标识的参数都下意识想换一下。这种专注带来的效率提升，比同时学五种手法高得多。

第三个习惯是每次被驳回都写复盘。被驳回不可怕，可怕的是同一个原因被驳回五次。复盘只写三行：被驳回的原因是什么、我漏了什么、下次怎么避免。写完就翻篇，不要陷在情绪里。

关于心态，说句实在的：这条路前期投入产出比很低，你会花很多时间在无效资产上，会看到别人晒出的高额奖励而自己颗粒无收。但它的复利效应也真实存在——你的判断力、对系统结构的理解、写文档的能力，都是可以迁移的。我在入门期练出来的那套“先把现象描述清楚、再讲影响、最后给建议”的表达方式，后来在完全不同的工作场景里一直用得上。

最后一个小心得：别急着证明自己厉害，先证明自己靠谱。审核员记住一个提交者，往往不是因为他找到多惊人的问题，而是因为他的报告永远清楚、永远能复现、永远不夸大。这种信用积累起来之后，你后续提交的报告会被更认真地对待，这比任何技巧都管用。