1. 先聊清楚这个副业的真实门槛和回报周期很多人问我SRC漏洞挖掘到底能不能当成副业来做是不是真的像网上说的那样“零基础、上手快、一挖就几千块”。我把话放前面SRC漏洞挖掘确实适合作为技术型副业但它不是“捡钱”的副业而是“积累型”的副业。我见过最快的人接触漏洞挖掘三个月就提交了第一个高危漏洞也见过很多人学了两周扫了一圈目录没结果就放弃了。差距不在天赋而在对“门槛”的理解。先说结论性的东西SRC平台本身是面向个人的注册账号、阅读授权范围、测试目标资产这套流程没有前置学历或证书要求这是它“门槛低”的原因。但漏洞挖掘的底层能力——Web工作原理、HTTP协议交互、前后端代码阅读、常见漏洞类型的成因与利用条件——是需要系统补齐的。零基础的意思不是“零准备直接上”而是“从零开始准备路径清晰可见”。从投入产出比来看我的经验是前3个月基本是纯投入期能挖到中低危漏洞已经算不错6个月左右开始进入稳定输出期月均几百到几千元是有可能的坚持一年以上的有人能做到月入五位数但那是少数。这个副业真正的价值在于每一次测试都在训练你的逻辑思维和信息搜集能力这种能力的积累是可持续增值的。还有一点很多人忽略SRC不只是“补天”或“教育行业平台”那几家。大型厂商自建SRC比如各互联网大厂的安全应急响应中心、行业SRC、国家级的CNVD漏洞平台都是提交入口。不同平台的审核偏好、奖励标准、处理周期差别很大这本身就是一门信息功课。我建议新手上路前先把主流的5-8个SRC平台的规则和奖励制度通读一遍不要一上来就埋头扫描。1.1 为什么人人都说“门槛低”但多数人三个月就放弃因为“能提交漏洞”和“能稳定挖到漏洞”是两回事。注册一个SRC账号十分钟就能完成但提交一个被确认有效、且定级不低的漏洞背后需要的是一条完整的知识链。我拆一下这条链第一环理解Web应用的请求与响应模型知道浏览器发给服务器的数据长什么样服务器返回的数据又意味着什么。第二环掌握常见漏洞的“触发点”比如参数进入数据库查询可能造成SQL注入文件上传接口缺少类型校验可能造成恶意文件上传越权接口没校验对象归属就可能造成水平越权。第三环能读懂目标业务的业务逻辑否则你扫到一堆接口也不知道哪个有漏洞价值。第四环会写漏洞报告能把复现步骤、影响范围、危害证明表达清楚。很多人卡在第三环。他们学了一堆漏洞原理去真实SRC平台一看发现目标是一个成熟的商业系统不像靶场那样把漏洞摆在明面上于是不知道怎么下手。这就是“门槛低但放弃率高”的根本原因——漏洞挖掘不是套公式而是理解业务后的“找茬”过程。1.2 SRC规则里藏着的信息差奖金额度与审核偏好同样是高危漏洞在不同平台的收益可能差一个量级。以我看到的公开奖励数据为例整理成表格方便对比平台类型典型漏洞等级奖励区间参考审核特点大型厂商SRC严重/高危数千至数万元重视影响范围RCE和核心数据泄露定级高教育行业SRC高危/中危数百至数千元对越权、信息泄露比较敏感审核相对快综合众测平台按项目定价数百至数千元每个项目规则不同需逐一阅读CNVD等国家平台原创漏洞证明 / 积分无直接现金奖励主要用于证明能力和获取编号值得注意的信息差有两个。第一很多平台有“新人奖励”“首漏洞奖励”机制新注册账号头几次有效提交往往有额外加分或现金激励这是新手不该浪费的窗口期。第二审核的口味差异很大有的平台对SQL注入、XSS这类常见漏洞已经“免疫”低危的反射型XSS可能直接被忽略但如果是业务逻辑漏洞比如订单金额篡改、验证码绕过、水平越权反而可能定到中高危。所以入门阶段与其死磕技术难度高的漏洞类型不如先吃透目标平台的“漏洞偏好”。授权范围也要反复确认。一个SRC域名后面那句“测试范围包括但不限于”直接影响你哪些能测、哪些不能测。我之前遇到过新人在厂商SRC的子域名上做目录爆破结果那个子域名是第三方部署的不在授权范围内最后不仅漏洞被驳回账号还被做了警告处理。测试前读授权范围是比学技术更优先的事。2. 零基础起步技术栈准备到什么程度才算“够用”聊完预期管理进入正题。零基础要准备的技术栈我按“必须懂”“需要懂”“选择性懂”三个层级来讲避免新手掉进“把每个知识点都学透才敢动手”的陷阱。2.1 必须懂HTTP协议、请求响应与浏览器开发者工具漏洞挖掘的对象是Web应用而Web应用的交互基础是HTTP协议。你不必背下RFC文档但必须理解一次完整的HTTP请求由哪些部分组成请求行方法路径协议版本、请求头Host、User-Agent、Cookie、Content-Type等、请求体POST提交的参数。同理响应包里的状态码、响应头、响应体每一部分都可能成为漏洞线索。我建议的练习方法是用浏览器打开任意一个网站按F12进入开发者工具切到Network面板刷新页面一条一条看请求和响应。重点看几点哪些接口是动态请求还是静态资源请求头里有没有奇怪的字段登录后Cookie发生了什么变化。坚持看一周你对Web请求的理解会超过很多“背了三个月原理但没看过真实流量”的人。在此基础上安装并熟悉一款抓包工具。Burp Suite是社区使用最广的免费版足够入门使用如果不想装Java环境也可以用浏览器插件或Fiddler替代。核心能力就一个能截断请求、修改参数、重放请求。这三项能力会贯穿你之后所有漏洞挖掘工作。2.2 需要懂前后端代码的“阅读理解”能力零基础不需要一上来就学完整的前端工程化但要有能力读懂一段JavaScript代码或一段后端查询逻辑从而判断漏洞点在哪里。具体来说前端看懂HTML表单元素与JavaScript的事件处理逻辑知道哪些参数是前端拼出来提交给后端的哪些参数藏在Cookie或localStorage里。后端至少认识一种后端语言的“参数接收—逻辑处理—数据存储”的基本写法。推荐从PHP或Python入门因为网上漏洞分析文章里这两种语言出现频率最高你读得懂别人写的分析才能转化为自己的思路。数据库理解SQL查询的基本语法尤其是SELECT、WHERE、拼接字符串和注释符号的含义。这是SQL注入理解的基础。这套知识不需要报课B站和各大安全社区有很多免费视频配合一个真实项目边看边拆效率远高于啃书本。我的建议是找一个开源项目比如一个简单的博客系统本地部署起来然后打开代码对着业务功能看用户注册时参数怎么走进来的、登录验证在哪里做的、发表文章后数据怎么存的。这个过程不需要写代码只看代码和对照请求数据包坚持一到两周“代码阅读能力”就有质的提升。2.3 靶场训练从“看得懂”到“挖得到”的过渡不建议直接拿真实SRC当练习场先过靶场这一关。靶场的意义在于它的漏洞是确定的、环境是可控的你可以验证自己的每一步判断是否正确。我推荐这条训练路径DVWADamn Vulnerable Web Application适合完全没概念的新手它把SQL注入、XSS、文件上传等漏洞按难度分级从low到impossible逐级挑战。sqli-labs专攻SQL注入的靶场80多关由浅入深每关背后都有对应的注入手法。把里面的关卡刷三遍以上你对SQL注入的理解会超过大多数“看过文章但没练过”的人。Pikachu靶场覆盖面比较全除了注入和XSS还有越权、SSRF、文件包含等逻辑型漏洞适合建立全局视野。VulHub或本地搭建的综合环境模拟真实业务系统难度接近SRC实战适合在正式去平台提交前做“模拟考”。训练节奏上我的经验是“慢就是快”。不要追求一天刷十关而要确保每一关你都能回答三个问题漏洞为什么会存在触发它需要什么条件如果要修复代码应该怎么写能回答清楚这三个问题说明你是真的理解了这个漏洞而不是碰巧试出了结果。3. 信息收集是漏洞挖掘的隐形分水岭如果你去问那些“一天提交三四个漏洞”的人他们的共同点往往不是“漏洞知识更丰富”而是信息收集做得更深、更细、更系统。漏洞不会凭空出现它藏在某一个域名、某一个接口、某一个参数后面你的信息收集决定你能看到多大的攻击面。3.1 资产测绘从根域名到边缘资产的线索链路SRC平台的授权通常以域名或IP段为范围但目标公司实际暴露在互联网上的资产往往远超授权列表里的几个主域名。子域名、测试环境、旧版本系统、第三方部署的接口这些边缘资产常常存在防护薄弱、无人维护的情况反而更容易出现漏洞。我常用的资产收集路径根域名确定后先做子域名收集。工具层面可以用OneForAll、subfinder这类开源工具也可以直接查证书透明度日志crt.sh把目标域名输进去能看到它签过哪些证书证书里包含的子域名非常全。对收集到的每个子域名先看它是否解析到独立IP再判断是否属于同一公司。有些SRC平台的授权范围只覆盖主站域名不覆盖子域名或者只覆盖特定后缀这一步必须人工核对。对确定在范围内的资产用指纹识别工具或手动查看确定它的Web框架、中间件版本、前端框架类型。指纹识别的意义在于已知框架版本对应着已知漏洞列表这等于直接给你划出了漏洞挖掘的范围。3.2 目录枚举与历史泄露两个容易被低估的信息源目录枚举也叫目录扫描用字典去请求目标站点的常见目录和文件路径试图找出未在页面导航中出现的管理后台、备份文件、测试接口或源码包。常用的工具有dirsearch、gobuster字典可以选用dirsearch默认字典加上自己收集的“高价值路径字典”比如 /actuator、/.git、/swagger-ui.html、/api/v1/ 这类路径。但我必须特别强调目录枚举是噪音最大的信息收集方式。一个大型站点可能有几万条路径其中99%要么是404要么是无意义的静态资源。新手扫了半小时看着满屏结果很容易陷入“不知道下一步该看哪条”的困境。我的经验是优先看状态码为200且路径中包含admin、api、upload、test、backup、config、swagger、git等关键字的条目这些路径背后往往藏着敏感信息或未授权接口。另一个信息源是“历史泄露”。用搜索引擎或一些公开的互联网资产测绘平台搜索目标域名的敏感信息经常能发现程序员把配置文件和密钥提交到了公开代码托管平台。这类泄露如果直接关联到目标在SRC授权范围内的资产是可以作为有效漏洞提交的而且通常能定到中高危。3.3 信息收集的笔记习惯让每一次测试可复用我见过最可惜的情况是一个测试者花了两天收集了上百个子域名和目录条目但没做记录第三天开始测试时连昨天扫到哪都忘了又重新扫一遍。漏洞挖掘不是“一次性思维劳动”而是“系统化的信息作战”笔记就是你自己的情报系统。我的个人习惯是每个目标建一个表格资产URL指纹/技术栈开放端口是否存在已知漏洞备注http://abc.example.com/adminSpring Boot 2.x443, 22Actuator未授权待深入http://api.example.com/swagger-ui.htmlSwagger UI443API接口文档泄露待测试每次测试后把已经测过的路径、参数、结论记录下来下次直接在笔记基础上推进不仅效率翻倍还能避免对同一目标重复提交漏洞重复提交在SRC平台是会被忽略的还可能影响信誉。4. 漏洞分析的落地方法论从拿到目标到锁定漏洞点很多人最大的困惑是信息收集做完了站在目标面前下一步该做什么这里我分享一套自己打磨过很多次的“从入口到交叉利用”分析流程它不是某个漏洞的固定打法而是一整套适合SRC实战的思维方式。4.1 先把目标拆成一张功能地图不要打开一个网站就开始扫描。先人工走一遍这个站点的核心功能用清单方式记录每个功能入口用户体系注册、登录、找回密码、修改密码、个人资料编辑、头像上传、注销账号。内容体系发布文章/动态、评论、点赞、收藏、搜索、附件上传和下载。交易体系如果有下单、支付、查询订单、申请退款、发票管理。后台管理如果能探测到数据列表查询、用户管理、配置修改、日志查看、系统监控。这张功能地图就是你的攻击面清单。一个成熟的Web应用每个功能入口背后都连着数据库查询、文件读写、权限校验、金额计算等敏感操作任何一个环节出现疏漏都可能形成漏洞。4.2 用数据流的眼光追踪每一个参数功能地图建好之后选择一个入口进行“数据流追踪”。以“找回密码”功能为例你要追几条线用户在表单里输入手机号/邮箱这个值被提交到哪个接口参数名是什么服务端收到参数后是直接拼接SQL去查用户表还是走了参数化查询通过修改参数值观察响应变化可以判断是否存在注入。验证码是存在服务端Session里还是放在前端Cookie里如果放在Cookie里修改验证码值后提交看能不能绕过校验。重置密码的链接有没有带tokentoken是绑定用户的还是随机生成的如果token只存在于URL中且用户id可以篡改就可能存在垂直越权。追踪数据流时我要重点看三类东西参数值改了之后响应是否变化、请求重放是否仍有效、不同用户之间的数据是否可互换。这三个观察点基本覆盖了注入、逻辑绕过、越权三类最常见漏洞的判定条件。4.3 逻辑漏洞是零基础最容易出成绩的赛道相比SQL注入和XSS这类需要一定技术积累的漏洞类型越权和业务逻辑漏洞与“编程思维”的关联更紧密也更适配新手快速出成绩原因在于这类漏洞的测试方式简单直接但需要测试者对业务有足够理解而业务理解恰恰是很多人不重视、但你可以做深的部分。水平越权的典型表现两个普通用户A和BA登录后修改URL中的用户id或订单id就能查看或操作B的数据。测试方法很简单注册两个账号登录A账号获取某个订单详情链接退出后用B账号去请求同一个链接如果返回了A的订单数据水平越权就存在。漏洞报告的危害描述可以写“任意用户订单信息泄露可批量遍历”。垂直越权的典型表现普通用户或者未登录用户可以访问管理员接口。测试关注点在于后台接口在不在前端路由里、接口请求有没有校验当前用户角色、修改请求头里的角色字段能不能蒙混过关。这类漏洞在很多老旧系统里非常常见定级通常在中危以上。逻辑漏洞的测试思路不是“越复杂越好”而是“把业务规则挨个推翻试试”。验证码可绕过支付金额能不能改成负数下单—支付—发货的流程能不能跳过某一步优惠券能不能重复使用每一个问题背后都可能是你的第一个有效漏洞。5. 常见漏洞类型的实战手法拆解前面讲的是思路这一章落到具体漏洞类型的手法。我没有把OWASP Top 10全列一遍而是挑SRC实战中出漏洞频率最高、新手最容易上手验证的几类逐个说明判定链路。5.1 SQL注入从报错到盲注的完整判定链路SQL注入的本质是用户输入被拼接进SQL查询语句破坏了原有语法结构。测试时先找“查询类”功能入口搜索、筛选、详情、排序然后把参数值从正常值改成一个英文单引号提交后观察响应如果返回数据库报错信息如“SQL syntax error”说明参数可能拼进了SQL语句注入点大概率存在。如果页面没有变化尝试加注释符-- 或 #看能不能闭合语句再观察响应差异。如果页面正常返回和不正常返回的差异不明显用时间判断输入AND SLEEP(5)或AND DBMS_PIPE.RECEIVE_MESSAGE(‘a’,5)这类带延时的语句看响应时间是否加了5秒左右。延时生效说明条件语句被执行了存在时间盲注。测试SQL注入时我强烈建议注意三点。第一优先测试POST参数和Cookie参数不要只盯着URL上的GET参数很多系统的SQL注入点其实藏在POST请求体里。第二能用逻辑判断就别急着上延时语句延时测试会拖慢整个测试节奏也容易被WAF拦截。第三报告里描述危害时说要“可获取数据库中敏感数据”就够了不要在SRC平台里实际拖库或批量读取数据这是职业道德问题也是平台规则红线。5.2 XSS反射型、存储型与DOM型的触发差异XSS的核心是“前端把用户输入当成了代码执行”。测试时找所有“输入后内容会显示在页面上”的入口搜索框、评论区、昵称、留言板等。输入一段测试标记比如img src1 onerroralert(1)提交后看页面是否弹窗。弹了说明执行了。三类XSS要分清楚反射型输入随请求发送随响应直接返回并被浏览器执行一般出现在搜索框、参数回显这类场景危害相对低需要诱导用户点击构造的链接。存储型输入被存进数据库任何用户访问相关页面都会触发危害高典型场景是个人资料修改处的XSS管理后台只要有人查看等于拿到了后台的会话权限。DOM型漏洞不在服务端响应里而是前端JavaScript代码对URL或输入内容进行了不安全处理这类XSS更难发现但危害完全取决于DOM操作逻辑。给新手的建议先从反射型和存储型入手找到后可提交“中危”漏洞重点描述“可在目标站点执行任意JavaScript获取用户Cookie或进行钓鱼攻击”。DOM型XSS排查需要一定的前端功底可以放到进阶阶段。5.3 SSRF与文件上传两条高价值漏洞的闭合条件SSRF服务端请求伪造的本质是服务端接收用户传入的URL参数后代替用户向该URL发起请求且没有做内网限制。常见触发点图片加载/下载功能、URL分享预览功能、Webhook配置功能、PDF生成功能。测试方法把URL参数改成http://127.0.0.1:8080/或http://内网IP/看响应中是否出现内网服务的特征内容。文件上传漏洞在SRC中同样常见且影响范围大。测试关注点后缀名校验直接把 .php/.jsp/.asp 后缀改成大小写混合.PhP或双重后缀.php.jpg看是否绕过。Content-Type校验修改请求头的Content-Type字段或者在合法后缀文件中加入一句话木马内容看是否被拦截。文件存储路径泄露上传成功后服务端返回的路径是否包含可预测的目录结构如果是就可能被直接访问。文件上传类漏洞一旦能成功上传可执行脚本定级通常在“严重”但也正因为危害高平台审核格外严格。我的建议是测试时只证明“可以上传非预期文件”即可不要上传真正的木马拿到权限后做更多操作否则不仅漏洞报告难以通过还可能惹上不必要的麻烦。6. 漏洞报告怎么写才更容易通过审核并拿到奖励挖到漏洞只算完成了一半。很多新手提交的漏洞被忽略原因不是漏洞不存在而是报告写得不够清楚、不够有说服力。一个好的漏洞报告要让审核人员在五分钟内完全复现你的测试过程并认可危害。6.1 报告结构五要素一个都不能少一份高效通过审核的报告我建议包含以下五块漏洞标题格式一般是“目标URL漏洞类型危害概要”例如“XX系统后台接口存在水平越权漏洞可遍历查看任意用户订单”。漏洞描述用两到三句话说明该漏洞属于什么类型、为什么会存在比如“接口未校验订单归属参数导致任意用户可越权访问他人订单数据”不要只粘贴数据包。复现步骤分步骤写出完整操作过程每一步最好带上截图或关键请求响应包。要具体到“点击哪个按钮”“修改哪个参数值”“提交后返回什么内容”。影响范围说明攻击者能利用这个漏洞做什么能影响多少用户或多少数据尽量量化。修复建议给出至少一条可落地的修复建议比如“在查询订单接口中加入当前登录用户ID与订单归属的强校验”这会让审核人员觉得你的报告是经过思考的不是碰运气试出来的。写报告时最容易犯的错是“只贴包不解释”。贴一个巨大的HTTP响应包但没有任何文字说明审核人员根本看不懂。我的习惯是响应包只截取关键字段并用加粗或标注说明我要证明的是什么。6.2 定级判断与审核争议处理提交前自己先做一个定级预估避免报告定级与平台审核差距过大导致争议。一般来说漏洞类型常见定级关键判断依据SQL注入/命令执行/RCE严重能否直接获取数据库数据或系统权限水平越权/批量数据泄露高危是否涉及核心业务数据和用户隐私存储型XSS中危-高危触发是否需要管理端查看传播范围多大反射型XSS/低危信息泄露低危-中危对业务的影响程度目录枚举/指纹泄露低危或忽略平台审核普遍不看重单纯的信息暴露如果审核人员驳回了你的漏洞不要急着吵。先重新检查你的复现步骤是否在授权范围内、是否真的影响公开用户、是否存在被修复的版本差异。有些驳回是因为审核人员在你测试后修复了漏洞或更新了版本这种时候补充说明“我测试的版本是哪个时间点”往往可以申诉成功。但如果有一次确实属于误报老实认了比反复申诉消耗自己的信誉强得多。7. 副业路上的隐蔽坑与长期心态管理最后聊几个很少有人明说、但我认为比技术更重要的坑。这些坑一旦踩中轻则浪费几个月时间重则让自己与整个行业渐行渐远。7.1 授权边界再强调一遍SRC平台给了你测试范围不等于范围内的所有系统都可以用任何方式测试。SQL注入测试时进行延时注入可能导致目标业务卡顿严重的会影响真实用户访问目录爆破发大量请求可能导致目标WAF告警甚至触发对源站的封禁。你在SRC平台测试本质上是平台和厂商信任你而不是你拥有“无限开火权”。我见过因为周末对某目标做高强度扫描导致线上故障账号直接被平台封禁的真实案例。测试前绕开核心生产环境、控制扫描频率、避开业务高峰期这些是基本的职业素养。7.2 自动化工具的“偷懒陷阱”很多新人迷信“扫一下就能出漏洞”花大量时间配置自动化扫描器指望一键出报告。我的看法是自动化工具是效率放大器不是漏洞挖掘机。没错它的确能覆盖到人工容易遗漏的路径但它产生的误报和噪音同样海量。真正有效的节奏是信息收集阶段多用自动化漏洞分析阶段以人工为主、工具为辅。拿到一个目标先人工走一遍功能地图圈出可疑点再针对可疑点用工具辅助验证这样既不浪费工具的覆盖面也不丢失人对业务逻辑的判断力。7.3 时间投入与心态调节漏洞挖掘是一项需要长期保持“手感”的技能但它毕竟是个副业不要让它在你的生活里占据全部时间。我给自己定的节奏是每周固定三到四个晚上投入两小时剩下的时间用来阅读新披露的漏洞分析文章、复现最近出现的公开漏洞。遇到连续一两周挖不到漏洞的瓶颈期不要死磕换个目标、换个漏洞类型、或者去靶场刷刷手感效果往往比硬扛好。回望整体的路径零基础入门SRC漏洞挖掘真正重要的是建立一套“理解业务—信息收集—功能拆解—数据流追踪—验证利用—报告输出”的完整闭环。技术是支撑这套闭环的工具但不是闭环本身。只要沿着这个闭环持续训练第一次挖到有效漏洞只是时间问题。接下来要做的就是打开第一个靶场开始你的第一轮请求与响应的仔细端详。