不少人私信问我想学网络安全实战但没有安全专业背景也没有人带应该从哪里开始我通常的回答是——SRC漏洞挖掘。它不像CTF那样要求你精通二进制逆向和深奥的密码学也不需要多么昂贵的设备只要你会用浏览器、会抓包、会读简单的HTTP请求就已经站在门槛边上了。这篇是SRC挖洞系列第2期专门聊聊正式上“战场”之前必须做好的准备。我见过太多新人其实不是栽在技术难度上而是栽在准备不足没搞清授权范围就急着扫端口结果漏洞没挖到账号先被平台封了也有人下了十几个工具却不知道拿到一个域名后第一步该干什么。这篇文章就是用来帮你把这些坑提前绕开。1. 为什么SRC挖洞值得成为新手的“安全实战第一站”1.1 从CTF到SRC中间缺的不是技术而是场景很多新人学安全的第一站是CTF竞赛但CTF里的题目是人为构造的考点明确、环境干净、答案唯一和真实互联网环境里的业务系统完全是两码事。SRC漏洞挖掘则不一样你面对的是真实运行的服务、真实的用户数据、真实的产品逻辑这要求你同时理解业务、代码逻辑、网络协议和运维配置。我常说CTF练的是“招式”SRC练的是“意识”。比如CTF里给你一个SQL注入你只需要把flag跑出来就行但在SRC里你需要判断这个注入点属于哪个业务模块、参数经过了什么处理、能读到哪些数据、会不会影响其他用户。同样是注入真实场景里对危害的评估和利用思路完全不同。SRC最吸引人的地方在于它把“发现问题-验证问题-提交报告-获得奖励”这条链路完整地跑了下来。你不仅能拿到积分、现金、荣誉更能在一次次提交和驳回中逐渐理解一个成熟厂商是怎么看待安全风险的。这种反馈闭环是刷题和看视频给不了的。1.2 SRC到底在挖什么漏洞类型与厂商诉求很多新人以为SRC就是找XSS、找SQL注入其实这只是很小一部分。厂商真正关心的是三类问题数据泄露风险、业务被滥用风险、可用性风险。对应到漏洞类型上最常见的是越权访问、逻辑漏洞、信息泄露、身份认证绕过、注入、XSS、CSRF、文件上传、SSRF、一些配置类问题。这里有一个观念需要扭转低危漏洞不代表没有价值。很多新手看不起反射型XSS觉得“不就是弹个窗吗”但在某些场景下一个反射型XSS结合后台管理地址就能变成存储型XSS甚至拿到管理员会话。更重要的是SRC平台会把低危漏洞的提交当作你安全能力的“信用积累”连续提交有效低危漏洞会提升你提交中高危报告时的可信度。所以新人不用一开始就盯着“能不能拿高危”先把整个流程跑通理解厂商眼中漏洞的价值判断标准比一上来就追求漏洞等级要重要得多。2. 动手前先想清楚三件事授权边界、平台规则、测试范围2.1 授权测试这条红线千万别碰SRC漏洞挖掘最核心的前提是“授权”。厂商在自己的应急响应中心里划出测试范围允许白帽子在特定域名、特定资产上进行安全测试这才叫SRC。你如果在没有授权的情况下拿别人的系统练手那是违法行为哪怕你的目的是“学习安全”也不行。很多新人有个误区觉得“我这不是在恶意破坏我只是发现了一个漏洞并提交了呀”。但法律看的是行为而不是动机未经授权的扫描、探测、测试都可能被认定为非法侵入或破坏计算机信息系统。这方面已经有过多起反例这里不展开但请记住这句话所有SRC测试都有明确范围超出范围一步都别做。实际操作中我建议你把“授权范围”打印出来或者放到一个随时能打开的笔记里。测试前逐个域名核对测试中如果发现某个资产不太确定是否在范围内宁可跳过也不要逞强。不要觉得“这个子域名和授权域名在同一台服务器上应该没事”IP和域名归属有时候十分复杂别给自己惹麻烦。2.2 平台规则怎么读测试范围、禁止事项、评分标准每家SRC平台的规则大同小异但细节差异很大。你需要重点阅读三类内容。第一是测试范围一般会明确列出允许测试的域名、APP或业务线甚至会用表格区分核心资产和普通资产。第二是禁止事项比如不允许进行超大流量DDoS、不允许社工测试、不允许批量下载用户数据、不允许涉及不可逆操作等这些都是硬性红线。第三是评分标准也就是不同漏洞等级对应的积分或奖金区间以及漏洞评级的具体逻辑。很多新人最喜欢问“这个漏洞算高危还是中危”其实答案就在评分标准里。比如同一个逻辑漏洞如果影响的是核心业务可能就是高危如果只是一个边缘功能可能只算低危。你要学会把自己当成审核员从厂商的角度去判断影响范围和危害程度而不是从“能不能薅羊毛”的角度去自我安慰。2.3 环境验证本地靶场和官方测试环境的区别很多新人想“零门槛上手”但本地靶场和真实SRC环境是有区别的。本地靶场比如各类开源的漏洞靶机能帮你练手感和技术细节但SRC平台的环境是真实生产系统或特别搭建的测试环境它们的网络结构、WAF、风控、数据隔离都要复杂得多。我的建议是在开始挖SRC之前先花一周时间把本地靶场常见漏洞类型刷一遍尤其是越权、SQL注入、XSS、文件上传这四类。你不需要做到精通利用但要熟悉它们的长相——在Burp Suite的请求包里看到什么特征可能对应什么漏洞。有了这层基础再去SRC平台练手你至少能看懂响应包和状态码而不是面对一堆未知参数一脸茫然。不要把本地靶场和SRC对立起来它们是递进关系不是替代关系。3. 零门槛准备清单账号、浏览器、工具链一次配齐3.1 账号准备与安全习惯先说账号。你需要注册SRC平台账号同时准备好一个用于接收通知的邮箱以及一个能方便联系你的即时通讯方式有些平台会通过微信或QQ群同步消息。注册时我建议用一个和自己真实身份关联的稳定账号因为SRC平台在提现、发放证书、邀请演讲等环节都需要核实身份不要用小号或匿名邮箱否则最后吃亏的是自己。安全习惯方面最重要的一点是不要在一个地方把所有重要密码设为同一个。很多安全从业者的账号本身就会成为攻击者的目标你如果连自己的密码管理都一团糟怎么让人相信你能发现安全问题建议至少用一套密码管理器并且开启多因素认证。另外抓包测试时可能会遇到真实存在的用户数据请严格遵守平台隐私要求绝不允许复制、下载、传播测试过程中看到的任何敏感数据。3.2 浏览器与抓包工具的初始配置零门槛上手的标准配置是Chrome或Firefox浏览器 Burp Suite Community版 Fiddler备选 一些方便的小插件。Burp Suite Community版对新人完全够用但刚装好时默认不支持HTTPS拦截需要导入证书并配置代理这部分很多教程都有但我想额外提醒两点。第一浏览器的代理设置最好用一个独立配置不要和系统全局代理混在一起。我习惯用Firefox的“代理设置”单独走本地127.0.0.1端口这样抓包时只影响浏览器流量不会把其他应用一起带到Burp里去。第二Burp Suite安装后把“Upstream Proxy”留空不要随便设置否则可能导致请求发不出去。另外建议关闭Java的自动更新弹窗免得测试到一半被系统更新打断。抓包工具是用来“观察”的不是用来“乱改”的。新人最容易犯的错误是看到请求就顺手改参数一脸兴奋地试了一堆奇怪的值结果要么请求被WAF拦截要么把自己的账号风控了。正确的姿势是先观察把请求的URL、方法、参数、Cookie、Referrer都看明白再动手改一个变量记录一次结果。3.3 信息收集常用的小工具清单这里给你一个极简的工具清单每个刻意不选“全家桶”只选能快速上手、命令行要求低的。用途工具说明子域名枚举在线子域名查询 oneforall 脚本先用在线工具了解资产再决定要不要做深度枚举HTTP请求测试Burp Suite / Fiddler拦截、重放、改包目录扫描dirsearch / ffuf字典要精选不要直接跑大字典指纹识别在线工具 / Wappalyzer插件识别CMS、框架、中间件常见端口服务探测Nmap只需要掌握常用参数别一把梭网页分析浏览器开发者工具看网络请求、控制台输出、存储信息在准备阶段重点不是把所有工具都装好而是把每个工具“能解决什么问题”记下来。比如遇到一个登录功能你该想的是“这个接口是否存在用户名枚举”而不是“我该用哪个工具扫描”。工具只是放大你的思路替代不了思路。4. 信息收集是挖洞的重头戏新手从这四件事开始4.1 域名资产梳理别把目标搞错拿到一个SRC目标后第一步是搞清楚这个厂商到底把哪些资产划进了你的测试范围。比如授权域名是example.com那你需要找到它的一级、二级甚至三级子域名但前提是这些子域名确实属于该厂商。这里有个常见坑很多子域名可能指向第三方云服务或者历史已废弃的资源如果你误测了第三方资产可能会影响第三方系统也会让厂商很尴尬。所以每发现一个子域名都先做基础的归属确认解析到哪个IP、对应什么备案信息前提是能看到、页面内容是否和企业品牌一致。不要看到域名前缀里带点厂商关键词就认为是它的。子域名枚举时可以先用在线接口交叉查询再用字典补充。跑出来结果后按照“主站业务系统、后台管理、测试环境、第三方托管、历史遗留”分类优先测试业务系统后台管理通常有更强的边界防护留给后续熟练了再说。4.2 指纹识别与常见端口服务确认了一组真实资产后先别急着扫描漏洞先看“这是什么技术栈”。打开首页看响应头里的Server字段看页面源码里的框架特征看URL里的文件后缀和路径命名再用指纹工具识别一下CMS或建站工具。这些信息决定了你后面往哪几个方向去测。如果厂商技术栈是Java系那可以留意FastJSON、Log4j、Shiro等组件的已知历史漏洞如果是PHP系重点看Laravel、ThinkPHP等框架的配置问题和已知CVE如果是前端偏重的应用那API接口和JWT令牌相关逻辑就要多关注。你不用背所有漏洞但要学会“看菜下饭”。端口扫描这一块我建议新人不要一上来就全端口扫描那容易被发现且触发告警。你可以先通过在线测绘搜索到目标开放端口或者只扫常见端口80、443、8080、8443、3306、6379等。只要发现一个数据库端口暴露在公网这往往就是一键中危的信息泄露问题比盲扫更有价值。4.3 目录扫描与功能点枚举目录扫描是为了找出那些没有出现在首页导航里的隐藏功能、备份文件、后台入口。新人最喜欢问“用什么字典”我的建议是先用2000条左右的精选字典配合状态码过滤先跑一遍常见的 admin、backup、test、config、.git、.svn 等目录和文件。但这里要特别提醒目录扫描只能帮你发现“可能存在什么”真正决定漏洞价值的是“这个文件能不能被访问到访问后有没有做权限校验”。比如扫出来一个/api/user/info接口直接无认证访问并且返回全量用户数据那这就是信息泄露越权的组合问题比专业漏洞更接地气。功能点枚举的意思是把你测试范围内的每一个页面交互都当成一个入口。登录、注册、找回密码、修改个人资料、上传头像、导出文件、查询订单所有这些功能都值得记录下来。每发现一个功能点就在笔记里列出参数、请求方法、是否需要认证、返回内容。前期这个记录很慢但后期价值巨大你会拥有一张属于自己的“业务攻击面地图”。4.4 身份越权与逻辑漏洞的入口观察信息收集阶段最应该顺手做的事就是测试“越权”。越权是指你作为普通用户能够访问其他用户的数据或执行某些管理操作。它通常不需要高深技术只需要分析请求里的ID、编号、Cookie字段然后简单替换数值。比如你登录自己的账号抓到一个获取个人订单详情的请求URL是/order/getOrder?id10086响应里返回的是自己的订单信息。你把 id 改成 10087如果直接返回了另一个人的订单这就是一个标准的越权漏洞。再比如你有一个普通用户账号尝试访问/admin/userList如果返回了管理端数据那就是权限绕过。测试这类漏洞时要非常克制不要在越权时去查看、修改别人的真实数据这会触发平台风控也可能导致隐私问题。正确做法是只验证“能否拿到响应”能够证明存在越权就立即停止然后截图记录影响而不是继续往深处遍历。把这一条刻在脑子里你是在做安全验证不是在薅数据。5. 新手友好漏洞类型按这个顺序练手效率最高5.1 越权与访问控制类漏洞越权类漏洞绝对是我推荐所有新手第一个完整吃透的类型。原因有两点第一它极易复现不需要复杂的注入语句只需要改参数第二它的危害很直观审核员看得懂报告也容易写。你可以在每个需要传ID、编号、文件名的请求里都试一下水平越权把自己换成别人再试一下垂直越权把普通用户换成管理员。需要注意的是现在很多平台已经有了全局的参数加密或签名机制你改个参数就会签名校验失败但这不代表没有越权可能还存在其他未加密接口去抓APP的请求或者观察某些历史接口。5.2 反射型XSS和存储型XSSXSS是入门必修但我建议不要只停留在弹窗证明。你可以思考这个XSS能否用来盗取Cookie、能否结合CSRF、能否打到管理后台、是否可以变成存储型。在SRC报告里一个“仅在控制台输出字符串”的self-XSS往往会被忽略但一个可以伪装成官方页面诱导用户点击的反射型XSS通常能评上中危。测试XSS时基本思路是找到输入点突破输出编码。比如搜索框、留言板、用户昵称、富文本编辑器。你可以先用无害的payload验证是否存在反射再尝试用各种编码绕WAF。这个过程非常锻炼对浏览器解析机制的理解是新手成长最快的技术点之一。5.3 信息泄露与配置错误这类漏洞对新手特别友好因为很多时候你不用攻击只需要“仔细看”。比如网页源码里注释掉的生产数据库地址JS文件里的硬编码密钥.git目录可访问备份文件可下载接口返回多余字段这些都是一提交就被确认的合法问题。我在检查任意一个站点时都会先按顺序过一遍看响应头Server、X-Powered-By、看HTML注释、看JS文件里的接口定义和密钥、看robots.txt、看常见备份文件名、试一下/server-status和/actuator端点。很多新人挖不到漏洞不是因为技术差而是因为看得不够细。5.4 逻辑漏洞改个参数就能绕过逻辑漏洞是SRC里最有趣的一类它通常没有任何注入但通过修改业务流程就能产生危害。比如修改支付金额、绕过验证码次数限制、篡改优惠券使用条件、跳过身份认证步骤、找回密码流程中通过修改响应包来重置他人账号。练逻辑漏洞的方法很简单把一个业务操作从头到尾走一遍抓下每一份请求思考每个步骤是否缺一不可是否客户端能控制服务端的判断。比如找回密码时服务端用请求里的某个字段标识当前步骤如果你把这个字段从“第一步已验证”改成“第三步已通过”可能就直接跳过了短信验证码校验。这类问题在现实中特别多也是思路价值高于技术的典型代表。6. 报告写不好等于白挖漏洞报告的结构与表述技巧6.1 一份好报告应该包含哪些模块我见过最可惜的一种情况是漏洞确实存在但白帽子提交的报告只有一句话“这里可以越权修改他人密码”没有数据包没有截图没有影响说明平台审核员根本无法判断严重程度最后只能忽略。写报告本质上是在“把你的技术发现翻译成厂商能认可的危害证明”。一份合格的报告至少要有这些模块漏洞标题注明URL和参数、漏洞类型和平台列表对应、漏洞等级自己的判断、漏洞描述业务背景和功能点说明、复现步骤按时间顺序写清楚每一步操作、复现请求和响应关键数据包截图或文本、影响证明能直观看到泄露了什么/绕过了什么、修复建议至少给出参考方向。6.2 复现步骤的写法让审核者像按说明书一样复现复现步骤是审核员判断漏洞真假的核心。你要假设审核员完全不了解你的测试思路只拿着你的报告一步步操作也能得到同样的结果。所以每一条步骤都要具体到“访问哪个URL”“在哪个输入框填写什么内容”“用什么账号的什么权限”“看到什么响应”。不要只放一张截图就完事截图必须能反映关键信息。比如证明越权时截图里要有两个用户的标识对比一个是你自己的订单号另外一个是访问后返回的他人订单号。证明XSS时截图里要能看到你输入的payload被执行的效果而不是只有一段源码。我自己的习惯是在本地用Markdown记录每一步关键数据包用文本粘贴加高亮截图用框线标出重点。最后检查一遍如果掩住所有文字只看截图审核员依然能看出问题存在这份报告就合格了。6.3 常见被忽略或被驳回的原因被忽视和驳回是SRC旅程中的常态特别是对新手。我总结了几个最高频的原因你可以对照自查。第一测试不充分只测了一个点就提交没有排除业务本身的功能设计第二影响范围描述夸大明明只能改自己账号的信息却写成“可以修改所有用户”第三使用的payload或测试行为明显影响他人如给他人发送大量验证码、修改他人真实数据这不仅会被驳回还可能被永久封禁第四报告排版混乱审核员没有耐心读第五并没有真正绕过安全校验只是客户端显示效果变化服务端实际没受影响。每次提交被驳回我建议你做一件事把驳回理由复制到一个专门的笔记里一个月以后回顾你会发现自己重复犯的错其实就那么几个。解决了这些你的报告质量会很快超过大多数新人。7. 从第一次提交到持续进步一些掏心窝的经验7.1 第一次挖洞建议从低危开始很多新人一上来就盯着高危、严重漏洞觉得只有拿到高奖金才算成功。但我的建议是第一次提交请主动从低危漏洞开始。原因很简单低危漏洞更容易验证成功成功提交一次能帮你建立对整个流程的正反馈也能让你知道平台审核员最在意的信息是什么。当你手动测了几个低危信息泄露或逻辑小问题后你会逐渐理解厂商对漏洞的评判口径。这时候再深入研究高危漏洞你会敏锐地察觉哪些地方更容易出问题而不是拿着一堆扫描器乱撞。7.2 被忽略/驳回是常态如何处理情绪任何人都会遇到被忽略或驳回的情况我也一样。刚接触SRC时我花了一晚上确认的漏洞提交后第二周被驳回理由是“WAF和业务层面已忽略该风险”。那晚上确实很挫败但后来我明白了一个道理SRC平台的目标不是奖励所有“技术正确”的安全问题而是奖励“对业务真正有威胁”的安全问题。所以被驳回时先不要急着跟审核员辩论先冷静下来看理由思考是不是自己把业务逻辑理解错了是不是漏洞利用需要的前提条件太苛刻是不是审核员认为影响面不够。如果确认报告本身没问题可以礼貌地在站内信里补充说明但不要反复纠缠。把驳回当作一次免费的代码审计机会收获远大于情绪上的纠结。7.3 建立自己的知识库和模板随着提交的经验增多你会逐渐发现自己对某些漏洞类型更敏感对某些业务的测试思路更顺手。这时候就可以开始建立自己的知识库了。我的建议是准备三个文档一个记录测试流程每次拿到目标后按什么顺序查什么一个记录漏洞报告模板把开头结尾套话固定下来一个记录业务逻辑漏洞的灵感库每次看到有意思的功能点就记录思考可能有什么风险。这套东西看起来笨重但坚持三个月后你挖洞的速度和报告的通过率都会有明显提升。更重要的是它会慢慢形成你作为安全测试人员的个人方法论。以后无论你去做渗透测试、安全开发还是应急响应这套方法论都会跟着你成为你职业道路上最重要的底子。说句实在话我现在回看自己第一次提交SRC时的准备工作确实觉得有很多可以做得更快、更好的地方但那种“原来这么简单”“原来这里也能出漏洞”的惊喜感到现在都还记得。网络安全这个领域入门最怕的不是没基础而是没人告诉你哪些事值得做、哪些坑不能踩。希望这一期准备工作清单能让你少走一段弯路早点在SRC平台提交出自己的第一份有效报告。