1. 项目概述：从零到一，挖到你的第一个SRC漏洞

很多刚接触Web安全的朋友，心里都憋着一股劲，看着别人在漏洞响应平台（SRC）上提交漏洞、获得认可甚至奖金，自己却不知从何下手。网上的教程要么太散，要么太深，看完还是云里雾里。今天，我就以一个过来人的身份，和你聊聊，一个安全“小白”如何用最直接、最有效的方法，挖到人生中第一个SRC漏洞。这不是一套复杂的理论，而是一条被无数新手验证过的、可复现的实战路径。我们的目标很明确：绕过繁杂的理论，聚焦于那些在真实厂商业务中最常见、也最容易出成果的漏洞类型，通过系统的信息收集和针对性的测试，拿到属于你的第一个“战果”。这个过程不仅能帮你建立信心，更是理解真实世界安全攻防的绝佳起点。

2. 核心思路与心态准备：别想一口吃成胖子

在动手之前，我们先统一思想。对于新手而言，最大的敌人往往不是技术，而是焦躁的心态和错误的方法。

2.1 目标选择：放弃“高精尖”，拥抱“基础款”

新手最容易犯的错误，就是去挑战那些大型、复杂、安全性极高的核心业务系统，或者执着于挖掘像远程代码执行（RCE）这类的高危漏洞。这就像刚学会游泳就去横渡长江，失败是必然的。

正确的策略是：

1. 瞄准中小型厂商或大型厂商的非核心业务：大型互联网公司（如BAT）的核心主站，安全防护体系非常完善，自动化漏洞扫描、WAF（Web应用防火墙）、RASP（运行时应用自我保护）层层设防，新手去测试犹如以卵击石。相反，一些正在发展中的公司、或者大公司旗下的子品牌、新业务线、合作伙伴页面、后台管理系统登录入口等，往往是安全建设的薄弱环节。
2. 专注于中低危漏洞：你的第一个目标不应该是“惊天动地”的零日漏洞。信息泄露、越权访问、简单的跨站脚本（XSS）、短信/邮箱轰炸、逻辑漏洞（如验证码绕过、订单金额篡改）才是你的“主战场”。这些漏洞原理相对简单，出现频率高，且同样被各大SRC平台收录并给予奖励。挖到它们，同样能证明你的能力。
3. 理解SRC规则：在测试任何目标之前，必须、务必、一定要仔细阅读该SRC的漏洞提交范围、测试规范、免责声明。严禁对未授权的系统进行破坏性测试（如SQL注入尝试拖库、暴力破解导致账号锁定）。合规测试是底线。

2.2 工具准备：工欲善其事，必先利其器

你不需要一个装满昂贵“神器”的工具箱。对于入门，以下几类免费、高效的工具足矣：

信息收集类：

• 子域名发现：OneForAll,Subfinder,Amass。目标是尽可能全面地找出目标的所有关联域名和子域名，扩大攻击面。
• 端口与服务扫描：Nmap。识别开放端口，判断运行的服务（如Web服务、数据库、中间件），这是后续测试的基础。
• 目录与文件扫描：Dirsearch,Gobuster,ffuf。用于发现隐藏的目录、备份文件、配置文件（如.git,.bak,admin.php），这些地方常常是信息泄露的重灾区。
• 网络空间搜索引擎：Fofa,Shodan,ZoomEye。通过特征语法（如title=“后台管理”、body=“login”）快速定位目标的相关资产，效率极高。

漏洞探测与利用类：

• 浏览器与代理工具：Chrome/Firefox开发者工具是你的眼睛和手。Burp Suite Community版（社区版）是核心中的核心，它集成了代理、爬虫、重放、漏洞扫描（虽有限制）等功能，是手动测试的瑞士军刀。
• 漏洞扫描器（辅助）：AWVS、Nessus等商业扫描器固然强大，但对新手不友好且可能违规。我们可以使用一些轻量级或专项扫描器作为补充思路，但绝不能依赖。例如XSStrike用于检测反射型XSS，SQLmap用于验证可能的SQL注入点（务必在授权或本地测试环境使用）。

辅助与效率工具：

• 笔记软件：如Obsidian,Notion或简单的文本文件。详细记录每一个测试目标的资产列表、测试过的功能点、发现的疑点、测试的Payload和结果。好记性不如烂笔头，这是构建你个人知识库的关键。
• 密码本/字典：收集或自己整理常用的用户名、密码、目录名、参数名字典。高质量的字典能极大提升目录爆破和弱口令测试的成功率。

注意：工具是辅助，思维才是主导。切勿陷入“工具论”，以为有了工具就能自动挖洞。工具只是帮你完成了重复和繁琐的工作，分析和判断永远需要人脑来完成。

3. 标准化实战流程：五步挖洞法

下面，我将一个完整的、可循环的挖洞流程拆解为五个步骤。你可以把每一次测试都看作一次执行这个流程的循环。

3.1 第一步：深度信息收集——你的侦察兵

信息收集的广度与深度，直接决定了你后续测试的成果上限。这里的目标是绘制一张尽可能详细的“目标地图”。

1. 确定主域名：从SRC平台选择你的目标厂商，获得其主域名（例如example.com）。
2. 子域名枚举：使用OneForAll等工具，结合证书透明度日志、搜索引擎等手段，尽可能多地收集子域名。
   • dev.example.com(开发环境)
   • admin.example.com(可能的后台)
   • test.example.com(测试环境)
   • oa.example.com(办公系统)
   • api.example.com(接口服务)
   • mobile.example.com(移动端)
   • vpn.example.com(VPN入口，仅观察，勿测试)
3. 端口与服务探测：对发现的重要子域名或IP，使用Nmap进行端口扫描。重点关注：
   • 80/443(HTTP/HTTPS， Web服务)
   • 8080/8443(常见Web代理或服务端口)
   • 21/22(FTP/SSH， 可能存在弱口令或匿名访问)
   • 3306(MySQL数据库)
   • 6379(Redis数据库， 未授权访问漏洞高发)
   • 9200(Elasticsearch， 未授权访问)
4. Web资产指纹识别：对开放的Web服务，识别其使用的技术栈。
   • 前端框架：Vue.js, React, Angular。查看页面源码、网络请求，或使用Wappalyzer浏览器插件。
   • 后端语言：PHP, Java, Python, .NET。通过URL后缀（.php,.jsp,.do）、Cookie特征（如JSESSIONID）、HTTP响应头（如X-Powered-By: PHP/7.2）判断。
   • 中间件/服务器：Nginx, Apache, Tomcat, IIS。查看HTTP响应头中的Server字段。
   • 第三方组件：特定的JS库、编辑器（如UEditor）、图表组件等，这些往往有公开的已知漏洞。
5. 目录与文件爆破：对关键的Web站点（尤其是后台登录页、API接口站）使用Dirsearch进行目录扫描。字典要包含通用字典和针对技术栈的专项字典（如spring-boot.txt,php.txt）。
6. 历史漏洞与公开信息搜集：在搜索引擎、GitHub、网盘搜索中搜索site:example.com password,site:example.com “api key”,example.com 泄露等关键词，寻找意外泄露的敏感信息。同时查看该厂商历史上是否披露过漏洞，其业务系统可能沿用旧的不安全模式。

实操心得：信息收集不是一次性工作。在测试过程中，新发现的某个参数、某个JS文件里的注释，都可能引出一个新的子域名或接口，需要随时回头补充到你的资产地图中。我习惯用一个Excel表格或思维导图来管理所有资产，并标注其状态（未测试/测试中/已测试）。

3.2 第二步：漏洞扫描与人工审计——机器与人的结合

在拥有资产清单后，我们开始进行初步的漏洞筛选。

1. 被动扫描：配置好Burp Suite代理，让你的浏览器流量全部经过Burp。然后，像正常用户一样去浏览目标网站的所有功能点：注册、登录、搜索、查看个人资料、下单、上传头像、修改信息等等。Burp会完整地记录下所有的HTTP请求，其Target->Site map会自动为你构建网站结构图。
2. 主动爬取：使用Burp自带的Spider功能对目标进行爬取，以发现更多隐藏的链接和参数。对于需要登录的站点，可以先手动登录，然后Burp会获取到你的会话Cookie进行认证爬取。
3. 自动化扫描（谨慎使用）：将Burp抓取到的站点地图，发送到Intruder或Scanner（社区版功能有限）进行一些基础的测试，如检查缺失的HTTP安全头、简单的SSL配置问题等。切勿使用自动化扫描器对目标进行大规模的注入、爆破测试，这极易触发WAF警报甚至导致IP被封禁，且不符合SRC规定。
4. 人工审计关键点：这是核心。你需要像侦探一样，仔细审查Burp捕获的每一个请求和响应，尤其是：
   • 请求参数：GET/POST参数、Cookie、Headers（特别是自定义Header）。思考每个参数的作用，是否可以篡改？
   • 响应内容：HTTP状态码（403、500错误可能透露信息）、响应体（是否包含敏感信息、调试信息、堆栈跟踪）、HTTP头（Server,X-Powered-By,Access-Control-Allow-Origin是否配置不当）。

3.3 第三步：聚焦高频漏洞类型——新手福利区

基于人工审计，我们可以对以下几类“新手友好型”漏洞进行针对性测试。

3.3.1 信息泄露漏洞

这是最简单也最常见的一类。你的眼睛就是最好的扫描器。

• 敏感文件泄露：检查是否可以通过直接访问下载到.git目录、.svn目录、.DS_Store文件、WEB-INF/web.xml文件、各类备份文件（.bak,.swp,.old）。这些文件可能包含源码、配置信息甚至数据库密码。
• 错误信息泄露：触发程序的错误（如输入非法参数），看返回的报错信息是否暴露了数据库结构、服务器路径、SQL语句、API密钥等。
• 目录遍历/目录列表：尝试修改参数中的文件路径，如download.php?file=../../../../etc/passwd。或者某些目录未禁用索引功能，直接列出了文件列表。
• 接口信息泄露：前端JS文件、安卓APP的APK包反编译后，可能硬编码了API密钥、内部接口地址、甚至账号密码。
• CORS错误配置：检查Access-Control-Allow-Origin头是否被设置为*或包含不受信的域名，这可能导致用户数据被恶意网站窃取。

3.3.2 业务逻辑漏洞

这类漏洞完全依赖你对业务的理解和脑洞，机器很难发现。

• 越权访问：
  • 水平越权：用户A能否通过修改参数（如用户ID、订单号）访问到用户B的数据？例如，请求GET /api/user/info?uid=10086， 将uid改为10087。
  • 垂直越权：普通用户能否访问管理员的功能接口？例如，普通用户登录后，直接尝试访问/admin/deleteUser.php这个链接。
• 验证码绕过：
  • 前端校验：验证码仅在页面JS中校验，提交到服务器时未二次验证。
  • 重复使用：同一个验证码可以多次使用。
  • 空值或万能码：提交空验证码或特定字符串（如0000）可通过验证。
  • 验证码与手机/邮箱未绑定：输入任意手机号获取验证码，然后用这个验证码去验证另一个手机号。
• 订单/支付逻辑漏洞：
  • 商品价格篡改：在提交订单的最后一步，拦截HTTP请求，修改total_price、quantity等参数为负数或极小值。
  • 无限优惠券：领取优惠券的接口，是否可以通过重放请求（Replay）无限领取？
  • 库存溢出：购买数量设置为一个极大的数（如999999），可能导致库存逻辑错误，甚至以极低价格购买。

3.3.3 输入输出验证漏洞

• 反射型XSS（最容易挖）：在所有的搜索框、URL参数、表单填写处，尝试输入一些基本的XSS测试Payload，如 ``， 然后观察该输入是否原样出现在页面HTML中。
  • 测试技巧：不要一上来就用 ``， 先用一个唯一字符串（如testxss123）测试输入点是否可控且回显。确认后，再逐步尝试更复杂的Payload。注意观察输出位置是在HTML标签内、属性内还是脚本内，这决定了最终的Payload构造。
• 短信/邮箱轰炸：在注册、找回密码等需要发送验证码的功能点，拦截发送验证码的请求，并重放（Replay）数百上千次。检查服务器端是否对同一手机号/邮箱在短时间内有次数限制，是否对IP有限制。

3.4 第四步：漏洞验证与报告编写——临门一脚

当你发现一个可疑点时，不要急于下结论。需要严谨地验证其危害和可复现性。

1. 复现漏洞：清除浏览器缓存、使用无痕模式、甚至更换网络和浏览器，按照你发现的步骤，重新操作一遍，确保漏洞稳定复现。
2. 评估危害：这个漏洞能造成什么实际影响？是泄露单个用户信息，还是所有用户数据？是让攻击者免费获得商品，还是能控制服务器？客观评估危害等级（可参考CVSS评分标准或该SRC的自定义标准）。
3. 编写报告：一份清晰的漏洞报告是你能力的体现，也直接影响审核结果。
   • 标题：简明扼要，如“XX系统后台管理页面存在未授权访问漏洞”。
   • 漏洞等级：根据SRC规则自评（如中危、低危）。
   • 漏洞详情：
     • 漏洞URL：完整的漏洞地址。
     • 漏洞参数：触发漏洞的具体参数。
     • 漏洞Payload：你输入的测试数据。
     • 复现步骤： step1, step2, step3... 像教程一样详细，让审核人员能一键复现。
     • 请求与响应：附上Burp抓取到的原始HTTP请求和响应包（可适当脱敏）。
     • 漏洞证明：截图或录屏，清晰地展示漏洞触发前后的对比。
   • 修复建议：提出你的修复方案，这能体现你的专业性。例如，对于越权，建议“在服务端对当前登录用户的权限与请求的资源所有者进行强制校验”。

3.5 第五步：总结与迭代——形成正向循环

无论本次测试是否成功挖到漏洞，都必须进行总结。

• 成功了：复盘整个发现过程，是哪一步的信息收集提供了线索？测试的思维路径是什么？这个漏洞模式是否在其他功能点也存在？将其沉淀为自己的“漏洞模式库”。
• 失败了：分析原因。是目标太硬？还是测试不够细致？有没有漏掉某些功能点（如忘记测试忘记密码功能）？调整策略，选择下一个目标或换个角度重新审视当前目标。

4. 新手专属实战案例拆解

为了让思路更具体，我们模拟一个完整的、针对“某电商平台子站”的测试流程。

目标：shop.example.com（假设为某大型厂商新上线的电商子站）

第一步：信息收集

• 子域名扫描发现：shop.example.com,m.shop.example.com,api.shop.example.com。
• 端口扫描：shop.example.com开放 80, 443。
• 指纹识别：前端是Vue.js， 后端API返回头有X-Powered-By: Express， 是Node.js技术栈。
• 目录扫描：发现/admin目录返回403，/api目录存在，/uploads目录开放。

第二步：人工浏览与抓包

• 注册账号，登录，浏览商品，加入购物车，进入个人中心。
• Burp记录下所有请求，发现关键API接口：
  • GET /api/user/profile(获取当前用户信息)
  • POST /api/cart/add(添加购物车)
  • GET /api/order/list?userId=12345(获取订单列表)
  • GET /api/admin/users(获取所有用户列表， 但访问返回403)

第三步：针对性测试

1. 测试越权（最优先）：

   • 访问GET /api/admin/users， 返回{"code": 403, "msg": "Forbidden"}。这很正常。
   • 查看GET /api/user/profile的响应，发现返回了完整的用户对象，其中包含一个"role": "user"字段。
   • 猜想：后端可能是通过判断用户对象的role字段是否为admin来做权限校验。
   • 测试：拦截GET /api/user/profile的响应，将"role": "user"修改为"role": "admin"， 然后让请求继续（Burp的Intercept->Forward）。再次访问GET /api/admin/users。
   • 结果：成功返回了所有用户的敏感信息列表！发现一个垂直越权漏洞。原因是后端信任了前端传来的用户角色信息，未在服务端进行二次校验。

2. 测试XSS：

   • 在商品搜索框输入testxss123， 搜索后，页面显示“搜索‘testxss123’的结果”。
   • 确认输入回显在HTML标签内。构造Payload：``。
   • 提交搜索，成功弹出警告框。发现一个反射型XSS漏洞。

3. 测试信息泄露：

   • 尝试访问http://shop.example.com/.git/config， 返回403。
   • 尝试访问http://api.shop.example.com/apidoc（猜测可能有API文档）， 返回了一个包含所有接口定义和示例密钥的Swagger UI页面！发现一个敏感信息泄露漏洞。

第四步：编写报告以越权漏洞为例，报告核心部分如下：

• 漏洞标题：XX电商平台API接口权限校验缺陷导致垂直越权
• 漏洞等级：中危
• 漏洞URL：http://api.shop.example.com/api/admin/users
• 复现步骤：
  1. 使用普通用户账号（如user:password）登录系统。
  2. 使用Burp Suite代理浏览器流量。
  3. 访问个人中心，Burp会捕获GET /api/user/profile请求。
  4. 在Burp中，将对该请求的响应体中的"role": "user"修改为"role": "admin"， 并Forward。
  5. 随后在浏览器中访问http://api.shop.example.com/api/admin/users。
  6. 页面成功返回所有用户的详细信息列表（附截图）。
• 请求/响应包：（附上修改前后的原始数据包）
• 修复建议：后端在处理/api/admin/users等敏感接口时，不应依赖前端上传的用户身份信息。应在服务端会话（Session）或Token中存储用户角色，并在每个接口的控制器层进行强制权限校验。

5. 常见问题与避坑指南

在实际操作中，你会遇到各种各样的问题。这里总结一些典型的“坑”和解决方案。

最后的个人体会：挖洞就像解谜，耐心和细致远比炫技重要。我的第一个漏洞就是一个简单的目录遍历，但它给了我巨大的信心。不要害怕目标看起来“太简单”，真正的漏洞往往就藏在那些看似平常的功能背后。养成随时记录、随时思考“这里是否可能有问题”的习惯，这个思维模式的价值，远超过任何一个单独的漏洞。从今天起，选一个合适的SRC，按照这个流程踏出第一步，你离自己的第一个漏洞就已经非常近了。