梦双月SRC漏洞挖掘最近几年热度一直不减，隔三差五就有人问我"从哪开始""怎么找漏洞""为什么我提交的漏洞总是被忽略"。我把这两年实际挖洞、审报告、带新人的经验重新整理一遍，尽量把思路和手法讲透。这篇不打算讲那些空话，直接说人话，从零基础到能独立挖洞的路径我都会覆盖到，包括选目标、信息收集、漏洞判断、报告提交、避坑经验。内容会比较长，建议收藏后分段看。
1. 先搞清楚SRC的规则再动手
1.1 SRC到底是什么？它和渗透测试有什么关系
SRC是Security Response Center的缩写，翻译过来是安全应急响应中心，本质是企业对外公开的漏洞收集平台。企业把自家的域名、App、小程序、公众号等资产挂出来，安全研究员在授权范围内做测试，发现漏洞后走平台提交，企业验证确认后给积分、奖金或实物奖励。
很多人把SRC和渗透测试混为一谈，其实差别不小。渗透测试是双方签好合同、划好范围、约定时间的一次性测试，目标是全面体检；SRC是持续开放、按漏洞付费的众测模式，目标是在授权资产里找出高危问题。你不需要对一个系统做完整渗透，而是找到足够有价值的漏洞即可提交。核心价值是"拿结果说话"，一个高质量漏洞胜过十次无效扫描。
SRC适合三类人：在校学生想积累实战经验，乙方工程师想提升漏洞发现能力，转行做安全的业余爱好者想攒简历项目。它的门槛其实不高，会基本的HTTP原理、抓包、看JS代码，就能起步。
1.2 授权范围与雷区：哪些能打哪些不能碰
刚开始挖洞的人最容易栽跟头的地方，就是没看清授权范围。SRC平台每个项目页都会写明测试范围，常见格式是：
- 域名列表：允许测试的域名及其子域名
- 规定路径：仅允许测试特定目录
- 限制条件：禁止测试某些系统、某些数据操作
我见过不少新手把目标域名的旁站、关联域名一起测了，结果不在授权范围内，直接被判违规。甚至有人顺手测了内部系统、云服务器、合作方系统，这种行为在被定性为越权之后是很麻烦的，轻则取消奖励，重则永久拉黑。
合规底线必须刻在脑子里：不在列表里的资产一概不碰，不允许的测试手法坚决不用，不进行破坏性操作，不下载和传播业务数据。遇到洞只能验证、截屏、写报告，绝不能利用漏洞做任何数据导出或修改操作。发现涉及数据量大的漏洞时，先及时报案，做验证后马上停止并提交，别想着"多看一眼没事"，出了事就晚了。
1.3 漏洞定级与奖励：怎么算高危，怎么算低危
不同SRC平台的定级标准会有差异，但大体遵循行业通用模型，我整理了一个比较常见的参考表：
| 级别 | 典型场景 | 大致奖励范围 |
|---|---|---|
| 严重 | 直接获取服务器权限、核心数据库泄露、RCE、大量用户敏感信息泄露 | 数千到数万元 |
| 高危 | SQL注入、越权访问他人数据、大范围存储XSS、SSRF可读取云元数据 | 一千到数千元 |
| 中危 | 反射XSS、CSRF、部分信息泄露、低危越权 | 数百到一千元 |
| 低危 | 轻微信息泄露、点击劫持、URL跳转 | 数十到数百元 |
判断漏洞价值有一个核心原则：看影响面和数据敏感度。同样一个反射XSS，挂在企业主站和挂在活动落地页，积分可能差很多。另外现在很多平台开始关注逻辑漏洞和供应链风险，这些方向竞争少、单价高，值得深入研究。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 目标选择与信息收集是成败关键
2.1 选目标：去哪找容易出洞的业务
同样花一个晚上，有人能挖到高危，有人毛都测不出来，很多时候是目标选错了。选目标不是随便挑一个域名就开始扫，而是要有策略。
优先选择刚上线的新业务。新系统开发时间短、测试不充分，逻辑漏洞和越权一抓一个准。判断方法是看平台公告、"近期更新"栏，或者凭经验嗅出旧站改版、菜单上新。新系统通常使用的是新框架，配置错误也比较多。
优先选边缘资产。很多企业重点防护核心电商和主站，但对营销活动页、运营后台、客服系统、内部工具投入不够。这些系统往往与主站共享用户体系或数据库，突破一个点就能扩大战果。关注子域名中带有test、dev、demo、admin、oa、erp、crm字样的系统，这类系统出现敏感信息泄露的概率很高。
优先选数据价值高的业务。金融、电商、社交类SRC的单漏洞价值普遍高于普通企业，因为涉及资金和用户隐私。如果一个企业的业务同时涉及支付、订单、用户资料，那么挖到SQL注入或者越权的价值要翻倍。
2.2 信息收集的完整链条：域名、IP、端口、指纹
信息收集决定你能发现多少攻击面，这个环节我一般拆成四步：
第一步是资产收集。从SRC给的根域名出发，用子域名收集工具把相关域名全部拉出来。日常我常用的方式组合是：subfinder做被动收集、amass做接口枚举（这个工具跑起来比较慢，适合挂机跑）、oneforall把字典爆破和被动收集合并起来处理。再加上通过证书透明度日志查询的方式，这里用的是crt.sh网站的思路，把证书历史记录里出现过的域名一并整理出来。
第二步是IP反查和归属确认。拿到域名列表后，通过DNS解析找到对应IP，再用IP反查域名确认是否属于目标企业。这一步很关键，因为不少企业用了CDN或云负载，直接扫IP可能扫到第三方服务商，扫出问题也不能提交，白费力气。通过历史DNS记录和ICP备案信息能辅助判断资产归属。
第三步是端口和服务识别。使用nmap扫描常见端口，重点关注几个方向：22端口看SSH版本和弱口令爆破可能性、3306和6379等数据库端口是否误暴露、8080和8443端口是不是管理后台或API、9200是不是Elasticsearch、10050是不是Zabbix Agent。服务版本号拿到后，就可以去对应漏洞库查已知漏洞。
第四步是Web指纹识别。指纹识别决定你后续用什么思路去测。一个站用的什么语言、什么框架、什么中间件、有没有CDN/WAF，都对测试手法有直接影响。工具上可以选择Ehole、Wappalyzer或者在线fingerprint数据库辅助识别。看到ThinkPHP就先测已知RCE链，看到Spring就关注SpEL表达式注入和Actuator泄露，看到Shiro就试反序列化，这些都是可以条件反射的。
2.3 JS文件与API接口：被忽略的信息金矿
零基础挖洞最容易忽略的突破口就是JS文件。现在前后端分离架构普及，大量逻辑都写在接口调用里，而这些接口的信息就藏在JS文件里。
打开浏览器开发者工具，切到Sources面板，把目标网站的JS文件挨个翻一遍，你会发现很多有趣的东西：API接口路径、加密算法的入口函数、硬编码的密钥和Token、管理员接口、内网IP地址、OSS Bucket地址。我挖到过不少越权漏洞，就是因为在某个管理后台的JS里发现了可用的内网测试接口，再配合Cookie参数做替换验证。
API接口找到之后，用Burp Suite或者直接浏览器访问一遍，观察返回的数据结构。很多开发者会在接口返回里塞额外信息，比如把用户手机号、身份证号一起返回。只要发现数据里存在超出预期的敏感字段，就是一个可提交的信息泄露漏洞。
后端接口的安全测试重点放在：有没有鉴权、参数能不能篡改、返回信息量是否过大、是否存在批量操作的URL。很多接口用数字ID做标识，直接改ID就能访问别人的数据，这类问题经常出现在App的接口和微信小程序的云函数里。
2.4 网络空间测绘与被动信息收集
主动扫描容易被封IP，被动信息收集能有效降低暴露风险。建议注册使用网络空间测绘工具，国内常用平台有FOFA、Quake，国外有Shodan、Censys。可以直接用关键词搜索目标企业名、特征banner、特定图标哈希来快速定位资产。
常用测绘语法范例：
domain="example.com"拉出该主域下所有子域名icon_hash="xxxxxxxx"找到使用相同图标的所有站点title="后台管理" && body="example.com"找目标企业的后台入口protocol="mysql" && ip="x.x.x.x"定位数据库服务
测绘工具的价值在于：一是发现你传统信息收集没覆盖到的暴露面，比如某台被遗忘的测试服务器；二是给出端口和组件版本，帮助判断是否存在已知漏洞；三是能够快速对比资产指纹，帮你找到目标企业在云端开的所有实例。
另外搜索引擎和被动的信息收集也值得做。在搜索引擎里搜索site:example.com 后台、site:example.com 密码，以及使用GitHub搜索目标域名相关代码中是否暴露了密钥或Token，经常有意外收获。
3. 常见漏洞类型的实战挖掘思路
3.1 注入类漏洞：SQL注入的发现与判断
SQL注入在SRC平台里的地位依然很高，因为一旦确认，危害清晰、评级稳定。挖掘思路不是上来就堆sqlmap，而是要手工先判断。
判断注入点的常规流程：找到所有带有参数的HTTP请求，参数来源包括URL查询字段、POST表单、JSON数据体、Cookie。在这些参数后面分别尝试单引号、双引号、括号、反引号，观察响应是否有变化。如果输入单引号后页面报错或者返回内容为空，就把它标记为可疑点。
更高效的判断方式是看报错信息。如果数据库报错直接回显到页面上，比如You have an error in your SQL syntax，说明数据库错误信息没有被屏蔽，直接走报错注入。如果页面没有报错，就用布尔盲注，用1' AND '1'='1和1' AND '1'='2对比返回内容差异。还可以尝试时间盲注，使用if(condition,sleep(3),0)这类方式，看响应时间是否延迟。
确认注入类型之后，再考虑用工具进一步提取数据。sqlmap的用法不多讲，重点是命令要带全：sqlmap -u "http://target/page?id=1" --batch --dbs。跑之前一定要记住，在SRC环境下做数据提取属于敏感操作，只做验证即可，不要拖库，不要导表。
针对WAF绕过需要补充一点思路。现在很多目标站点装了WAF，简单payload直接被拦。处理方式是先分析拦截特征：是拦截关键字还是拦截特殊字符，然后尝试大小写混合、注释符分割、编码变换、等价函数替换。比如union select换成UNION/**/SELECT或者union all select。我不建议在SRC场景下花大量时间对抗WAF，点到为止，确认漏洞存在即可提交，绕过思路可以在自己搭的靶场里练。
3.2 跨站脚本与前端风险：XSS的实战场景
XSS在SRC里的地位比较微妙：基础分不高，但存储型XSS如果打在核心业务页面上，危害就很大。不过我自己在挖掘时仍然会认真测，因为XSS的验证成本低、通过率高，适合新手攒积分。
XSS挖掘的重点场景：
- 搜索框、评论框、留言板这类用户可输入内容的地方，测存储型XSS
- URL参数直接回显在页面中的位置，测反射型XSS
- 前端框架根据URL hash渲染内容的场景，测DOM XSS
- JSONP接口的callback参数，测XSS
- 文件上传后文件名或文件内容被前端渲染的场景，测文件型XSS
一个靠谱的验证流程是：先用普通字符串测试输入是否被转义。比如提交"><svg onload=alert(1)>，观察返回的HTML源码。如果尖括号和引号没有被编码，就说明可以注入HTML。再根据上下文调整payload，插入到属性里就要先闭合引号，插入到script标签里就直接写JavaScript代码。最终确认能执行JavaScript，就可以截图提交了。
需要注意，主流SRC平台都对XSS做了细分：普通反射型XSS可能只算低危，但如果在登录页面、支付页面实现XSS，利用价值高很多，评级也会上升。另外，利用XSS构造钓鱼页、窃取用户敏感信息，这类POC演示内容不要在报告里展开写，描述危害时点到为止。
3.3 越权与IDOR：最容易批量出高危的方向
越权漏洞是现在很多SRC平台漏洞数量最多的类别，原因很简单：开发只做了登录校验，没做权限校验。越权分两种，水平越权是同级别用户之间的越权，垂直越权是低权限用户访问高权限功能。
IDOR（不安全的直接对象引用）是水平越权的基础形态。典型场景：一个获取订单详情的接口，请求路径是/api/order/getOrder?orderId=123456。我用自己的账号登录，把orderId改成别人的订单号，如果接口返回了别人的订单信息，那就是一个IDOR。这类问题大量存在于个人中心、订单查询、文件下载、消息查看、发票管理等业务模块。
测试越权的关键步骤：
- 准备两个测试账号，一个当受害者、一个当攻击者
- 用受害者账号登录，记录下所有的ID参数和返回数据
- 换攻击者账号，访问同一个接口，把ID替换成受害者ID
- 如果返回了受害者数据，说明存在水平越权
垂直越权的测试思路类似：用普通用户登录，找管理员功能的接口，直接访问管理员接口看是否有权限拦截。很多后台没有做严格的角色校验，普通用户直接访问/admin/list就能拿到管理数据。这类漏洞在中国企业里比例很高，值得多花时间。
批量测试越权有一个偷懒但有效的办法：抓取正常请求后，使用Burp Suite的对比功能，把GET请求中所有的数字ID参数全部替换为其他值，批量发送并对比响应长度。响应长度明显不同的，往往就是越权点。
3.4 文件上传与下载：绕过校验的几种思路
文件上传漏洞这几年收敛了不少，但总有系统存在能被绕过的校验逻辑。上传功能的目标价值在于，如果成功上传了WebShell并执行，直接就是严重漏洞。
绕过的思路主要有这么几类：一是扩展名绕过，比如大小写混写、双写扩展名、加入可解析扩展名如php5、phtml；二是Content-Type绕过，把application/x-php改成image/jpeg；三是文件头绕过，在脚本文件前面加上GIF89a等图片头；四是解析漏洞利用，利用IIS或Nginx配置错误让图片文件被当作脚本解析；五是在文件名中加入Null字节截断等历史手法。
但我必须强调一点：在SRC项目中，上传漏洞只要证明可以写入文件并访问到该文件即可，不要继续上传完整WebShell、不要连接执行命令。截图证明写入成功就够了，继续利用反而会触发平台风控。
文件下载漏洞更常见，也更安全。搜索系统中是否存在文件名或路径参数，比如filename=、filepath=、path=、download=，试着替换路径为../../../../etc/passwd看能否读取系统文件。能做目录穿越验证的站点已经很少了，但通过这种方式读取源代码配置文件、数据库备份文件，是不少高危漏洞的来源。发现这类漏洞后立即停止操作，只读取一两个关键文件证明风险即可。
3.5 逻辑漏洞：支付、优惠券、验证码的典型案例
逻辑漏洞不需要高深的技术，但需要脑洞，是零基础选手逆袭高手的赛道。因为逻辑漏洞没法用扫描器发现，只能靠人工反复捋业务流程。
支付逻辑是最经典的考察方向。常见手法包括：修改支付金额、修改商品数量、修改优惠券使用条件、利用竞态条件重复领取优惠。几年前有个经典案例是某电商平台，下单时把价格参数改成0.01元，后端没有重新计算价格，直接按前端传值扣款，愣是被一批人刷了几百单。
优惠券逻辑同样是重灾区。测试时可以关注：同一张优惠券能不能重复使用、优惠券在什么条件下被作废、新用户专享券能不能用老用户账号领取、邀请奖励机制能不能通过批量注册来薅。
验证码逻辑也很有意思。重点关注：验证码有效期是否过长、验证码是否可预测、验证码是否可复用、短信轰炸接口是否做了频率限制。短信轰炸属于中低危但通过率很高，因为危害明确、复现简单。
做逻辑漏洞测试前，务必先看清SRC平台的授权条款中是否允许进行这类验证，特别是涉及资金操作的测试，有的SRC平台会划出红线，禁止修改金额或使用批量小号。遵守平台规则永远是第一位。
4. 从发现到提交：完整实操流程
4.1 一个典型漏洞的发现过程：从入口到验证
用一个我印象很深的案例来说明完整流程。
当时某SRC平台新增了一个子模块，是面向内部员工的考勤系统，域名是attendance.example.com。先做子域名收集时发现了它，接着做指纹识别，发现是Spring Boot框架，Actuator端口对外开放，通过/actuator/env拿到了部分配置信息，但没有数据库密码等敏感值，只算低危。我没有立即提交，而是继续翻JS文件，找到一组管理员接口。
使用普通测试账号登录后，把请求中的角色参数role: 0改成role: 1，再访问管理员接口/api/admin/list，居然直接获取了员工列表，里面包括手机号和身份证号。这个漏洞我定为高危，因为普通员工可以查看全量敏感信息。整个过程没有使用任何扫描器，基本靠人工观察和改包。
这个案例想说明的事很简单：信息收集的广度决定你发现目标的能力，JS分析和接口观察决定你突破目标的能力。漏洞往往藏在一个小细节里，而这个小细节就藏在JS文件或某个不起眼的参数里。
4.2 Burp Suite配置与常用操作
Burp Suite是SRC挖掘里的核心工具，不会用Burp，很多漏洞都测不了。对于零基础读者，我建议从社区版开始就够用了，但真正做到高效挖掘，还是需要专业版配合插件。
基础配置这里说几个关键动作。设置代理：浏览器或系统代理指向127.0.0.1:8080，Burp默认端口就是8080。安装CA证书：访问http://burp下载CA证书，导入到系统信任区，否则无法解密HTTPS流量。配置好之后，浏览器访问任意网站，Burp的HTTP History里就能看到所有请求。
挖掘时最常用的功能模块：
- Proxy：拦截和修改请求，改包就在这里面做
- Repeater：重放请求，手工测试参数用的最多，快捷键Ctrl+R
- Intruder：批量爆破和参数遍历，可用于简单的IDOR批量遍历
- Decoder：URL编码、Base64解码、十六进制转换，处理数据用
- Comparer：响应内容对比，辅助判断两种输入的区别
我平日的组合操作是：浏览器访问时开启代理，看到可疑请求就右键发送到Repeater，在Repeater里修改参数、观察响应。需要批量验证时，把请求发送到Intruder，设置好变量和字典，运行一遍看状态码和响应长度。整个过程不复杂，多练几次就形成肌肉记忆了。
4.3 漏洞报告怎么写：一次通过审核的要素
写报告是SRC挖掘中最被低估的环节。我见过很多漏洞明明存在，却因为报告表达不清被审核忽略或者被判低危。报告质量直接影响漏洞评级和奖励，值得花时间去打磨。
一份合格报告的核心要素是：能够让审核人员在一分钟内理解漏洞、复现漏洞并确认危害。
报告结构建议这样组织：
- 漏洞标题：写明漏洞类型、影响模块、危害程度。例如"分诊系统越权访问接口导致全量患者信息泄露"，一看就懂
- 漏洞详情：描述漏洞位置、触发条件、利用思路，简单说明测试过程中的关键步骤
- 复现步骤：分步骤列清楚，注明使用的是哪个账号、修改了哪个参数、访问了哪个URL。代码级别的请求包要贴出来，不能只发截图
- 影响说明：说明可能被谁利用、会造成什么后果，比如"任何登录用户可以查看任意用户的订单信息，导致个人数据泄露"
- 修复建议：给出方向性建议，比如"对接口做严格权限校验，禁止客户端传入角色参数"
容易被忽略的细节：复现请求里要把Cookie或Token脱敏处理，不要把账号密码写在报告里；截图要清晰，重点位置要用红框标注；文本信息不要截图，要复制成文字，方便审核人员复制测试。
报告遵循冷静克制的原则，不要夸张渲染，不要写"可能造成毁灭性打击"这类话。客观描述，专业表达。
5. 常见问题与避坑指南
5.1 零基础新手最容易犯的错
新手期踩的坑我基本都踩过，整理出来几个高频问题。
第一是学了一堆理论但不知道怎么动手。理论看得多、实战少，是因为缺乏靶场练习。可以先在自建的本地靶机上练手，常见的靶场有DVWA、Pikachu、Sqli-labs。在本地把这些靶场的漏洞类型全部打一遍，再上SRC实战，会顺很多。
第二是拿到目标就乱扫。上来就开扫描器对目标一顿扫，不仅容易被封IP，还可能扫出一堆无关信息，真正的人工分析反而没做。正确方式是先人工浏览一遍站点，把业务逻辑和功能点都摸清楚，再决定用什么工具辅助测试。
第三是不重视报告。漏洞发现了，截图也截了，但报告写得很模糊，审核人员看不懂，只能忽略。报告能力是挖洞能力的一部分，建议没事多看看SRC平台上的优秀报告案例，模仿它们的写法。
第四是越打越贪。测出一个漏洞后，想继续深挖更多漏洞，一直测到深夜，结果人疲惫了、操作变形了，点错几个按钮就可能越权访问了不该访问的数据。合理规划测试时长，发现高价值漏洞后及时收手提交。
5.2 漏洞被忽略或被驳回了怎么办
提交漏洞被忽略或驳回，是很容易打击积极性的事，但大多数情况是报告本身的问题。常见原因是：
- 漏洞描述不清晰，审核没看懂
- 复现步骤不完整，审核按步骤复现不了
- 危害评估不准确，判定为无实际影响
- 测试目标不在SRC授权范围内
- 该问题已经被其他人提交过
处理方式先别急着申诉。把报告重新读一遍，站在审核人员的角度思考：如果我是个完全没接触过这个系统的人，能按你的步骤复现吗？大多数时候是自己确实没写清楚。
如果确认是审核误判或者评级不合理，再去走申诉流程。申诉时保持礼貌，补充更详尽的证据，比如额外的数据包、更清晰的演示视频，说明为什么这个漏洞达到某个危害等级。合理沟通，大部分SRC审核员是讲道理的。
5.3 被平台拉黑的几种常见行为
SRC平台最不能容忍的行为我是认真整理过的，新手更需要提前知道：
- 未授权测试：测试授权范围之外的资产
- 批量注册账号：用脚本批量注册大量测试账号，扰乱业务
- 爆破行为：对登录接口进行大规模密码爆破，影响正常用户
- 恶意提交：反复提交重复或误报漏洞，浪费审核资源
- 数据下载：利用漏洞大量下载业务数据
- 一洞多投：同一个漏洞在不同平台重复提交套取奖励
被拉黑之后，在这个企业的漏洞平台几乎就是永久除名，而且安全圈内口碑也会受影响。合规操作是长期玩下去的基础。
5.4 挖洞心态与时间分配
挖洞是一件反馈周期不稳定的事，可能连续几天颗粒无收，也可能一夜之间发现两三个高危。保持稳定的心态比技术提升更难。
我的经验是把时间分配做拆分：每周固定几个晚上做信息收集和目标梳理，周末集中做深度测试。日常碎片时间可以看看漏洞推送、看看新公开的CVE和POC，积累攻击手法的敏锐度。
不建议报着"今晚必须挖到高危"的心态去测试，反而容易盯着一个点死磕，忽略了其他攻击面。更合适的心态是"今晚把这个目标的功能点全部过一遍"，只要过程做到位，结果自然会出现。很多人问为什么挖洞高手效率高，表面看是运气好，其实是因为他们目标多、思路清晰、动作规范，漏洞出现的概率自然就高了。
6. 学习路线与长期进阶
6.1 从零基础到实战的学习路径
零基础入门SRC，学习路径可以从五个阶段去走，我把每个阶段的重点写出来。
第一阶段：打牢Web基础。学HTTP协议、浏览器开发者工具、Cookie和Session机制、同源策略、HTML/CSS/JavaScript基础。推荐资源是MDN Web开发文档和《图解HTTP》，不用背，理解了就可以。
第二阶段：掌握漏洞原理。把OWASP Top 10逐个过一遍，了解每个漏洞的产生原因、利用方式、修复方案。配合本地靶场做实验是这一阶段最好的方式，以Sqli-labs和Pikachu为主。每打完一个漏洞类型，尝试用自己的话总结一遍，再写笔记。
第三阶段：上手Burp Suite。学习代理配置、拦截请求、修改参数、重放请求、批量操作。这个阶段不需要懂太深，会用Repeater和Intruder做基础测试即可。
第四阶段：实战SRC新手目标。选一个SRC项目先看报告规范，再选几个低危漏洞类型如XSS、URL跳转、信息泄露入手。新手期不要太追求高危，先把提交流程和报告写法跑通。
第五阶段：专项深入。选择一个方向深耕，比如专注越权漏洞、专注逻辑漏洞、专注供应链漏洞。每个方向都有独特的知识体系和技巧，深度比广度更值钱。
6.2 复盘、写笔记与个人知识库
很多挖洞选手成长慢，不是因为不努力，而是因为不复盘。每次测试完，不管有没有漏洞，都应该花十分钟做一次复盘。
复盘的内容包括三类：这次用了什么思路，哪些思路有效、哪些无效；目标系统的架构和薄弱点是什么，有没有共性；提交的漏洞为什么过审、为什么被驳回，审核关注点在哪。
写笔记的核心是形成自己的知识库，我建议用支持Markdown的工具来做。按漏洞类型建目录，比如SQL注入、越权、逻辑漏洞，每个目录下记录案例、请求包、payload、绕过技巧。几个月后回头翻，就能看到自己完整的成长轨迹。
个人知识库比任何培训班都有价值，因为它记录了你的思考过程和踩坑经历，这是别人无法复制的东西。
6.3 从SRC到安全从业者的进阶思路
SRC挖洞不只是挣零花钱，也是通往安全从业者的重要跳板。很多公司招聘安全工程师时，会特别看重候选人在SRC平台的排名和漏洞成果，这比任何证书都有说服力。
如果想走这条路，建议提前做几件事：定期参加排名前列的平台活动，积累积分和排名；把自己提交的高质量漏洞整理成安全文章，发表在博客或安全社区，建立个人影响力；关注安全厂商和大型互联网公司的招聘要求，针对性地补充知识。
SRC的价值在于它提供了一个低门槛、高回报的实战环境。在这里你接触的是真实业务、真实代码、真实防御体系，这些经验是任何模拟环境都替代不了的。做安全最怕的就是纸上谈兵，而SRC正好是打破这个局面的最好途径。
最后再分享一个我个人的小习惯：每次开展新目标测试前，我会先用十分钟把当天要测的功能点、可能的漏洞类型和测试步骤写在纸上，测试完成后用十分钟做复盘。这个方法虽然简单，但让我少走了很多弯路，也避免了反复做无用功。SRC这条路没有捷径，但有方法，剩下的就交给时间和耐心了。