白帽子初体验：三�?SRC 实战教会我的�?· 阿哲实验�?/title> <meta name="description" content="三周、三个SRC项目、三家完全不同的公司从资产发现到前端JS反编译，从API鉴权绕过到CORS配置缺陷，一个白帽新手的完整实战记录�?> <link rel="icon" href="../assets/favicon.svg"> <link rel="stylesheet" href="../assets/css/style.css"> <script type='module' src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "888be984399c44b9ae8eefb4e3487775"}'></script> </head> <body> <div class="orbs" aria-hidden="true"><div class="orb orb-1"></div><div class="orb orb-2"></div><div class="orb orb-3"></div></div> <div id="site-header" data-active="post-src-experience"></div> <article class="article"> <a class="back" href="../posts.html"><span>�?/span> 返回文章列表</a> <h1>白帽子初体验：三�?SRC 实战教会我的�?/h1> <div class="meta"> <span class="pill green">安全</span> <span>📅 2026-08-21</span> <span>�?阅读�?14 分钟</span> </div> <div class="article-body"> <p>注册白帽子快一年了，一直没正经交过漏洞不是不想，是总觉得「自己还不够格」——直到上个月，我对自己说：别等了，动手吧�?/p> <p>三周时间，我跑了三个项目：一家金融科技公司、一家物联网硬件厂商、一个视频平台三家公司，三种完全不同的安全成熟度，三种截然不同的测试体验这篇文章是这二十一天的完整复盘——踩过的坑、用过的方法、以及最重要的，那些 SRC 不会在公开文�里告诉你的潜规则�?/p> <h2>开篇：从注册到实战</h2> <p>一切开始得很简单：�?漏洞盒子注册白帽子身份，签署 SRC 保密协议，然后从已授权的测试目标列表里挑了三家看上去「能啃得动」的�?/p> <p>选目标有讲究——我挑了三个行业跨度大的，想在最短时间内接触最多的技术栈金融科技大概率有严格的合规要求，IoT 厂商的安全投入通常偏弱，视频平台则介于两者之间事实证明，这个判断基本准确�?/p> <p>拿到授权后，我先建了一个项目文件夹、一个笔记文档、一个方法论 checklist，然后才去扫端口每测一个点就勾掉一项，发现新思路就追加到 checklist 里这个习惯在后来的项目中救了我很多次�?/p> <blockquote>SRC 测试更像一场信息搜集的持久战，谁的信息更全，谁的胜算更大�?/blockquote> <h2>资产发现方法�?/h2> <p>我的资产发现流程分为四步，按顺序执行，每一步产出的结果作为下一步的输入�?/p> <table> <tr><th>步骤</th><th>工具</th><th>产出</th></tr> <tr><td>1. 子域名枚举（被动�?/td><td>Subfinder, 证书透明度日�?/td><td>原始域名列表</td></tr> <tr><td>2. DNS 解析与筛�?/td><td>MassDNS + 自定义解析脚�?/td><td>可解析域名列�?/td></tr> <tr><td>3. HTTP 存活探测</td><td>httpx</td><td>存活 Web 资产列表</td></tr> <tr><td>4. 截图与指纹识�?/td><td>gowitness + 自定义指纹库</td><td>可视化资产地�?/td></tr> </table> <p>手动跑一遍这些步骤很费时，于是我写了一�?<strong>pentest-recon.cjs</strong> 脚本把它们串起来�?/p> <pre><code>// pentest-recon.cjs �?自动化资产发现流水线 // 用法: node pentest-recon.cjs target.com const { execSync } = require('child_process'); const fs = require('fs'); const target = process.argv[2]; const dir = `./recon/${target}`; fs.mkdirSync(dir, { recursive: true }); // 1. 被动子域名枚�?console.log('[1/4] 被动子域名搜�?..'); execSync(`subfinder -d ${target} -o ${dir}/subdomains.txt`); // 2. DNS 解析 console.log('[2/4] DNS 解析...'); execSync(`massdns -r lists/resolvers.txt -t A ${dir}/subdomains.txt -o S > ${dir}/resolved.txt`); // 3. HTTP 存活探测 console.log('[3/4] 存活探测...'); execSync(`cat ${dir}/resolved.txt | awk '{print $1}' | httpx -silent -o ${dir}/alive.txt`); // 4. 截图 console.log('[4/4] 截图...'); execSync(`gowitness file -f ${dir}/alive.txt -P ${dir}/screenshots`); console.log('�?完成，结果在 ' + dir);</code></pre> <p>自动化之后，我的工作模式变成了：跑脚本的时候去喝杯咖啡，回来对着截图和资产列表开始真正的分析重复劳动交给机器，脑力留给需要判断力的地方——这是我这三周最大的效率提升�?/p> <blockquote>自动化的价值，是让你在真正需要判断力的时候精力充沛�?/blockquote> <h2>技术栈指纹识别</h2> <p>拿到存活资产后，下一步是搞清楚对面跑的是什么你连对面用的什么技术都不知道，怎么找漏洞？</p> <p>我的指纹识别三板斧：</p> <ul> <li><strong>Server 响应�?/strong>：Tengine、OpenResty、Apache、Nginx，一眼就能看出个大概Tengine 通常意味着阿里云系的部署，OpenResty 则暗示可能是 Lua 自定义网关�?/li> <li><strong>前端 JS �?/strong>：umi.js�?MB �?chunk 是标志性特征）、Nuxt.js（页面源码里�?<code>__NUXT__</code> JSON）、Vue SPA�?code>#app</code> + vendor 包）�?/li> <li><strong>配置中心</strong>：Apollo 配置中心可以通过 <code>releaseKey</code> 的格式特征识别出来�?/li> <li><strong>WAF 指纹</strong>：Alibaba Cloud WAF 会在 Cookie 里留�?<code>acw_tc</code>；自定义 WAF 则可能返�?412 Precondition Failed�?/li> </ul> <p>三家项目的技术栈对比如下�?/p> <table> <tr><th>维度</th><th>金融科技</th><th>IoT 厂商</th><th>视频平台</th></tr> <tr><td>Web 服务�?/td><td>Tengine</td><td>Nginx</td><td>OpenResty</td></tr> <tr><td>前端框架</td><td>umi.js (4MB)</td><td>Vue SPA</td><td>Nuxt.js</td></tr> <tr><td>后端语言</td><td>Java (Spring)</td><td>PHP</td><td>Go</td></tr> <tr><td>配置中心</td><td>Apollo</td><td>�?/td><td>自研</td></tr> <tr><td>WAF</td><td>Alibaba Cloud WAF</td><td>�?/td><td>自定�?WAF (412)</td></tr> <tr><td>Cloud Provider</td><td>阿里�?/td><td>腾讯�?/td><td>混合�?/td></tr> <tr><td>登录方式</td><td>短信 + 密码</td><td>手机�?+ 验证�?/td><td>OAuth + WBI 签名</td></tr> </table> <p>看到这个表的时候，我心里对三个项目的安全水位已经有了个大概的判断金融科技有合规压力，但业务复杂容易留漏洞；IoT 厂商技术栈简单，但安全投入最少；视频平台技术栈最复杂，WAF 是自研的——说明他们真有安全团队在维护�?/p> <h2>前端 JS 反编译的意外收获</h2> <p>这是我这三周学到的最重要的方法，没有之一�?/p> <p>现代前端应用打包出来�?JS 文件，尤其是 SPA，几乎包含了整个前端应用的「地图」：路由路径、API 端点、内部域名、甚至有时候硬编码的密钥和注释�?/p> <p>我的做法很简单：</p> <ul> <li>从浏览器开发者工具里找到�?JS bundle（通常�?<code>umi.js</code>�?code>app.js</code>�?code>main.*.js</code> 这种�?/li> <li>下载下来，用 <code>grep</code> 搜索关键模式�?code>/api/</code>�?code>route</code>�?code>internal</code>�?code>test</code>�?code>dev</code>�?code>pre</code>�?code>.com</code>�?code>.cn</code></li> <li>把匹配到的结果整理成资产清单</li> </ul> <p>金融科技项目的前�?JS 里，我翻到了一个支付系统的路由模式——代码里定义了一系列 <code>routeXXX</code> 格式的支付路由路径，虽然不是直接漏洞，但让我对业务逻辑有了全局视图�?/p> <p>IoT 厂商的项目才是真正的金矿一�?4MB �?umi.js 文件里，我找到了 <strong>8 个内部环境域�?/strong>�?/p> <pre><code># �?umi.js 提取的内部域�?api-dev.xxx.com # 开发环�?API api-test.xxx.com # 测试环境 API api-pre.xxx.com # 预发布环�?API api-internal.xxx.com # 内部 API admin.xxx.com # 管理后台 admin-dev.xxx.com # 开发管理后�?mqtt-dev.xxx.com # MQTT 开发服务器 oss-internal.xxx.com # 内部对象存储</code></pre> <p>最让我惊讶的是�?strong>预发布环�?api-pre.xxx.com 公网可访�?/strong>，而且和生产环境运行着同样的代码和数据库——只是数据量少一些这相当于一个完整的「影子系统」暴露在公网上，没有任何额外的访问控制�?/p> <p>但是，这里有个重要的教训：JS 包里的信息越多，说明这家公司的安全成熟度越低反过来，视频平台的 JS 包经过混淆，路由全是 hash 模式，API 端点做了动态拼接——他们显然知道前�?JS 是信息泄露的重灾区，做了针对性的防护�?/p> <blockquote>JS bundle 是信息泄露的富矿，但它的存在本身就是一面镜子——照出这家公司对安全的认知水平�?/blockquote> <h2>API 鉴权�?CORS</h2> <p>资产摸清了，技术栈知道了，接下来是真正的测试环节�?/p> <h3>支付 API 鉴权绕过</h3> <p>金融科技项目里，我发现一个支付状态的查询接口，不加任何身份凭证，直接 POST 请求就能返回业务数据返回的 <code>result: 0</code> 表示业务成功——不�?401、不�?403，是业务层面的成功这意味着支付流水号如果可预测或可遍历，就能批量获取交易信息�?/p> <p>这个漏洞，是我唯一一个拿到确认排期的�?/p> <h3>CORS 配置缺陷</h3> <p>在金融科技�?IoT 项目上，我都发现�?CORS 配置问题�?/p> <pre><code>Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true</code></pre> <p>通配�?+ 允许凭据，这是教科书级别�?CORS 配置错误但问题是——我能拿它做什么？</p> <p>理想情况下，配合一个已登录用户访问恶意页面，攻击者可以跨域读取敏感数据但�?SRC 的语境下，你只证明了「CORS 配置有问题」，却没有证明「谁能通过这个漏洞受到什么实际损失」SRC 审核团队给我的回复很明确�?strong>没有完整的攻击链，CORS 配置缺陷单独不予受理�?/strong></p> <div class="pit"> <div class="pit-card"> <b><span class="no">�?1</span>CORS 通配符单独提�?�?被拒</b> <p>即使 <code>Access-Control-Allow-Origin: *</code> �?<code>credentials: true</code> 同时存在，SRC 要求你证明这能造成实际危害需要找到具体的用户敏感数据接口，配�?CSRF �?XSS 构成完整攻击链�?/p> <p class="fix">�?教训：CORS 漏洞要和其他漏洞组合提交，单独提交会被拒�?/p> </div> <div class="pit-card"> <b><span class="no">�?2</span>DNS 内部 IP 泄露 �?被拒</b> <p>�?IoT 项目�?DNS 记录里发现内�?IP 地址段，单独提交后同样被拒SRC 认为内部 IP 泄露本身不构成可衡量的安全风险，除非能证明攻击者可以利用这�?IP 做进一步渗透�?/p> <p class="fix">�?教训：信息泄露类漏洞需要附带攻击路径，证明这些信息如何被利用�?/p> </div> <div class="pit-card"> <b><span class="no">�?3</span>预发布环境暴�?�?被拒</b> <p>预发布环境可被公网访问，理论上可以获取未发布的业务数据和测试账号但 SRC 认为预发布环境的数据是脱敏或非真实的，不构成用户数据泄露风险�?/p> <p class="fix">�?教训：预发布环境暴露通常被归为「低危」甚至「无风险」，除非你能证明生产数据也在上面�?/p> </div> </div> <p>这三个坑让我明白了一个残酷的事实：SRC 真正考核的是「能不能证明漏洞有价值」同样一个洞，能直接造成用户数据泄露或资金损失的，和「理论上可能被利用」的，在 SRC 的眼里是两种完全不同的东西�?/p> <blockquote>SRC 审核团队不关心技术上的「可能性」，只关心业务上的「必然性」翻译成人话：得证明这玩意儿真的能让人丢钱或丢数据�?/blockquote> <h2>安全成熟度横向对�?/h2> <p>三家公司的安全水位差异巨大，我把它们放在一起对比，结论非常直观�?/p> <table> <tr><th>维度</th><th>金融科技</th><th>IoT 厂商</th><th>视频平台</th></tr> <tr><td>安全成熟�?/td><td>中等</td><td>�?/td><td>�?/td></tr> <tr><td>WAF</td><td>�?WAF（基础规则�?/td><td>�?/td><td>自研 WAF�?12 拦截�?/td></tr> <tr><td>API 鉴权</td><td>部分接口无鉴�?/td><td>基本鉴权均有</td><td>WBI 签名 + 严格鉴权</td></tr> <tr><td>CORS</td><td>通配�?+ 凭据</td><td>通配�?+ 凭据</td><td>严格白名�?/td></tr> <tr><td>前端安全</td><td>未混淆，含内部路�?/td><td>未混淆，含全部内部域�?/td><td>混淆 + hash 路由 + 动态拼�?/td></tr> <tr><td>Cookie 安全</td><td>部分 HTTPOnly</td><td>�?HTTPOnly</td><td>�?HTTPOnly + SameSite</td></tr> <tr><td>速率限制</td><td>较弱</td><td>�?/td><td>严格（单 IP 限频�?/td></tr> <tr><td>测试结果</td><td>发现 1 个中危（已确认）</td><td>发现多个信息泄露，部分被�?/td><td>无发�?/td></tr> </table> <p>这个表格说明了两个问题：</p> <ul> <li><strong>你的时间应该花在哪里</strong>：IoT 厂商虽然安全投入少，但信息泄露类漏洞 SRC 又不收；金融科技找到了一个支付鉴权问题，是唯一确认排期的漏洞；视频平台什么都不给——但「什么都没找到」本身就是一个发现�?/li> <li><strong>安全是成本，不是功能</strong>：视频平台有自研 WAF、有严格鉴权、有前端混淆，每一层都在说「我们在这上面花了钱」IoT 厂商什么都没有，但 SRC 审核标准并不会因为对方安全弱就降低门槛�?/li> </ul> <h2>提交策略与踩�?/h2> <p>三周时间，我提交�?5 个漏洞，确认排期 1 个，被拒 4 个成功率 20%，惨不忍睹但每一个被拒的漏洞都让我学到了一些东西�?/p> <h3>什么会被拒</h3> <table> <tr><th>漏洞类型</th><th>提交次数</th><th>确认次数</th><th>被拒原因</th></tr> <tr><td>DNS 内部 IP 泄露</td><td>1</td><td>0</td><td>无实际攻击链</td></tr> <tr><td>CORS 通配�?/td><td>2</td><td>0</td><td>未证明能获取敏感数据</td></tr> <tr><td>预发布环境暴�?/td><td>1</td><td>0</td><td>预发布数据非生产数据</td></tr> <tr><td>支付 API 无鉴�?/td><td>1</td><td>1</td><td>�?/td></tr> </table> <h3>什么才有效</h3> <p>从这些被拒的教训里，我总结出了 SRC 提交的「黄金法则」：</p> <ul> <li><strong>可证明的 impact</strong>：能直接获取用户数据、能执行未授权操作、能导致资金损失——这些是 SRC 最关心的�?/li> <li><strong>完整的攻击链</strong>：不只是「这里有个洞」，而是「A + B + C = 攻击者能成功窃取 X」每一步都要可复现�?/li> <li><strong>清晰的复现步�?/strong>：包�?<code>curl</code> 命令 + 请求/响应截图 + 预期的安全影响审核人员每天看几十个报告，你的报告越容易复现，越容易被确认�?/li> <li><strong>合理�?CVSS 评分</strong>：不要虚报高分，也不要低估SRC 有自己的评分逻辑，虚报高分只会降低你的可信度�?/li> </ul> <h3>提交顺序的学�?/h3> <p>我学到的另一个教训是提交顺序�?/p> <ul> <li><strong>先提交信息泄露类</strong>：这类漏洞审核最快，虽然被拒率高，但反馈快，能帮你快速理�?SRC 的审核标准�?/li> <li><strong>再提逻辑漏洞</strong>：这类漏洞通常需要各种鉴�?token 和测试账号，准备工作量大，但确认率高�?/li> <li><strong>最后提交越权类</strong>：越权漏洞需要完整的前后端理解，评审周期最长，放在最后慢慢磨�?/li> </ul> <div class="pit"> <div class="pit-card"> <b><span class="no">最终建�?/span>一份好的漏洞报告应该包含什�?/b> <p>📌 漏洞名称和影响范�?br>📌 复现步骤（含具体 URL 和请求参数）<br>📌 完整�?curl 命令（可以直接复制粘贴复现）<br>📌 请求/响应截图（标注关键信息）<br>📌 业务影响说明（为什么这是个问题�?br>📌 CVSS 评分（附评分向量�?/p> <p class="fix">�?格式清晰、信息完整、可复现——这�?SRC 审核最看重的三点�?/p> </div> </div> <h2>结语</h2> <p>三周时间，三个项目，五个提交，一个确认表面上看，这个成绩单并不亮眼但对我来说，这二十一天的收获远不止一个漏洞确认——它让我建立了一套完整的白帽测试方法论，从资产发现到漏洞提交，每一个环节都有了自己的标准和流程�?/p> <p>几个核心 takeaways�?/p> <ul> <li><strong>自动化是力量倍增器�?/strong> <code>pentest-recon.cjs</code> 把重复劳动压缩到了极致，让我把精力放在真正需要判断力的地方任何白帽子都应该建立一个自己的工具链�?/li> <li><strong>前端 JS 是最容易被忽视的信息泄露面�?/strong> 现代 SPA 应用把整个应用地图打包进一�?JS 文件里，不翻一遍就去做渗透，等于闭着眼睛打仗�?/li> <li><strong>安全成熟度因行业天差地别�?/strong> 金融科技有合规托底，IoT 厂商几乎裸奔，大厂自�?WAF 让新手无从下手——选对目标比测试技术更重要�?/li> <li><strong>「没找到漏洞」也是一个发现�?/strong> 视频平台什么都没给，但反过来证明了他们的安全投入是有效的这种「被防御住」的体验本身，就是一次高水平的实战训练�?/li> <li><strong>SRC 不是 CTF�?/strong> 它不关心你秀了多少技巧，只关心你提交的漏洞有没有实际业务影响调整心态，从「找洞」切换到「证明风险」�?/li> </ul> <p>方法论还在迭代，手头�?pentest-recon.cjs 也在不断更新下一步计划把这套流程整理成更完整的工具链，也计划继续挑战更多 SRC 项目——不为排名，就为了在实战中保持手感�?/p> <p>安全这条路很长，三周才刚开了个头�?/p> </div> </article> <div id="site-footer"></div> <script src="../assets/js/main.js"></script> </body> </html>