很多人问过我一个特别现实的问题那些真正能把漏洞挖出花来的高手手里到底攥着什么秘密武器是比别人多装了十款扫描器还是在某个神秘社区里有内部情报说实话刚开始做漏洞挖掘那几年我也有同样的困惑。后来跟着几个前辈做了一批授权测试项目又陆陆续续在几个 SRC 平台交了不少报告慢慢琢磨出来一个反直觉的结论高手跟新手的差别根本不在工具数量而在看系统的方式。他们不会一上来就狂扫目录、乱打 payload而是先问一句这个目标到底是什么数据流怎么走哪一段代码最有可能出现误信输入的情况脑子里有这张地图再配合几款顺手的工具效率立刻就不一样了。这篇文章我想把这套思考过程拆开给你看包括攻击面梳理、漏洞类型匹配、实战链路、报告写法以及现在 AI 工具能帮我们做点什么。篇幅不短但每一个环节都是我实际踩过坑之后沉淀下来的东西适合刚入门想找方向的人也适合已经在挖但总觉得“差一点感觉”的朋友。1. 先搞清楚漏洞挖掘到底在挖什么1.1 大多数新手对挖漏洞的最大误解我见过太多人抱着“扫一下就能出洞”的心态入场他们打开 AWVS、AppScan 或者好几款综合扫描器对着目标一顿扫然后盯着报告看有没有高危。结果往往很残酷要么全绿要么全部是误报真正能提交到 SRC 并确认的漏洞一个都没有。问题出在哪先说一个基本判断扫描器干不了“挖掘”这件事它只干两件费力气不费脑子的事——发现攻击面验证已知问题。比如 nmap 帮你找出开放了哪些端口whatweb 帮你识别用了什么中间件sqlmap 帮你验证某个参数是否真的存在注入。这些都是“确认”动作不是“发现”动作。真正的发现发生在两者之间的思考区这个端口上的服务是什么逻辑这段代码处理了用户的哪个输入业务流转里有没有一个人应该做不到的操作有一个特别典型的例子。以前我带过一个实习生看到站点的 HTTP 响应头里有X-Powered-By: ThinkPHP就直接往命令执行打打了半天没反应回头跟我说这个站是假的。我去看了一眼发现这只是某个教师信息管理系统里一个静态页面残留的响应头真正的接口全在另一个后端项目里。他输就输在把“指纹识别”当成了“漏洞确认”中间缺失了最关键的一步先想清楚参数从哪里进来、会走进哪段代码、执行结果如何可观察。1.2 从“找茬”到“验证一个假设”的思维转变我在自己写的内部培训材料里经常放一句话漏洞挖掘的本质是验证假设不是碰运气。看到任何功能点高手脑子里会自动冒出三个问题这个输入参数最终去向哪里是拼进 SQL、进了 HTML 字符串、还是变成后端发起的请求 URL这条代码路径上有没有过滤或者转义过滤了什么没过滤什么绕过过滤之后我能通过什么现象观察到结果是页面回显、响应时间、还是外部的 DNS 交互这三个问题串起来就是一个可以验证的假设。比如你看搜索框假设是“关键字进入了 SQL 查询且无预编译”那验证方式就是给它一个单引号观察是否报错如果是“关键字进入了前端拼接的 HTML”验证方式是给它一段带 script 标签的文本看是否原样渲染。你不需要把十种 payload 全打一遍只需要设计两三次试探就基本能断定方向。我用生活里的场景打个比方开锁师傅不是把所有钥匙都试一遍而是先看锁孔形状推测钥匙的齿形范围再选几把去试。漏洞挖掘也是同理你越快把攻击面缩小到少数几个高概率路径你的“命中率”就会明显上来。这也是为什么同样测试一个系统有人两小时出三条有效漏洞有人泡了一整天却颗粒无收。2. 攻击面梳理拿到目标先画一张地图2.1 资产收集的第一步范围与边界我在 SRC 平台和授权测试项目里最常犯的错误就是把范围搞错。你看着一个主域名觉得很简单但实际线上可能跑了十几个子系统部署在 CDN 后面或者藏在某个隐蔽路径下。所以第一步永远是资产盘点不是立即测试。以主域名为例常规的收集顺序是这样的子域名收集通过证书透明度日志、字典爆破、DNS 历史记录、交叉查跨域引用的 JS 文件路径来扩充资产列表。存活探测批量请求每个子域名记录响应码和标题剔除空壳或未解析记录。端口与服务指纹对存活的 Web 端口做指纹识别确认中间件、框架、开发语言、API 网关等特征。目录与 JS 文件收集把 JS 文件里的接口路径、参数名、注释信息全部扒出来这是很多人忽略的高价值信息源。做完这一步你会得到一份“可测资产清单”。这时候别急着动手先按优先级排个序存量老系统通常比新上线功能更好打后台管理端通常比前台更具价值API 层往往比页面层更容易出逻辑漏洞。把精力集中在高优先级目标上后面每花的一分钟都会更值钱。需要说明的是这个过程里最花时间的不是跑字典而是梳理资产之间的关系。比如发现某个子域名用了独立的管理后台框架那它大概率是一个业务系统的入口发现某个 API 网关把所有请求统一代理到内网服务那它天然就是把外部输入引向内部逻辑的“咽喉”值得重点盯。2.2 功能点清单每个输入框都是一扇门资产盘点是“找门”功能点梳理是“看门里面是什么”。这一步很多人会偷懒直接对着页面点两下就开测。我建议你把目标系统完整地用几遍然后按功能模块列一张清单。常见的功能点包括登录、注册、忘记密码、短信/邮箱验证码个人信息修改、头像上传、资料导入搜索、筛选、排序、分页文件下载、导出报表、文件预览订单创建、支付、退款、优惠券领取评论、留言、工单反馈、客服聊天权限管理、邀请成员、团队角色切换每个功能点对应一组可能的问题这就是你的“测试矩阵”。我在实际项目中经常用类似下面的表格来规划测试任务功能点核心参数最容易出的问题我的预判搜索框keyword、pageSQL 注入 / XSS / DoS商品系统大概率预编译XSS 概率更高文件下载接口fileName、fileUrl路径穿越 / SSRF如果参数是完整 URL优先测 SSRF密码重置username、token、step用户枚举 / 验证码绕过 / token 可控先看 token 生成逻辑再试 step 跳转订单接口orderId、price、amount越权访问 / 价格篡改 / 重放重点测水平越权和重复提交资料上传file、type、ext内容伪造 / 解析绕过先看文件存储域名和后缀名策略这张表的价值在于它有“前提条件”也有“测试方向”不是让你乱试而是让每一次请求都有的放矢。你会慢慢发现漏洞不是藏在某个奇技淫巧的 payload 里而是藏在你是否认真对待每个普通功能的细节里。3. 漏洞类型不是背题是“条件匹配”3.1 OWASP Top 10 为什么是入门底线网上有很多人把 OWASP Top 10 当成十种“题型”背下例子觉得就算掌握了。这其实是本末倒置。OWASP Top 10 的价值在于帮你建立一个“触发条件清单”某种漏洞之所以能发生是因为某些前置条件恰好同时满足。你只需要按图索骥地去检查那些条件是否存在。比如 SQL 注入的触发条件至少要满足三点用户可控的参数拼接进了 SQL 语句数据库没有使用预编译或参数化查询结果能通过回显、报错、时间差异等通道被你观察到。再比如 XSS 的触发条件用户输入的内容被输出到页面输出位置没有做 HTML 实体编码或 CSP 限制浏览器会执行这些内容DOM 环境或服务端渲染环境。你发现没有这些条件本身就是“测试步骤”。条件不满足的接口你打再多 payload 也没用条件满足的接口你甚至不需要复杂的利用代码就能拿到证据。这也是为什么越是高手越喜欢先分析代码和数据流再决定打什么——因为他们是在做条件判断不是在背答案。3.2 逻辑漏洞才是 SRC 里的香饽饽现实一点说现在攻击面大量收敛主流框架跟 WAF 已经把经典注入和存储 XSS 挡得比较严实你在 SRC 平台上看到的高质量漏洞报告里越来越多是业务逻辑漏洞。这类漏洞不需要你懂逆向、不需要找 0day只需要你比产品经理多想一层。举几个我实际测到过的例子水平越权登录 A 账号直接改 URL 里的orderId12345就能查看到 B 账号的订单详情。接口只校验了“是否登录”没有校验“数据归属”。垂直越权普通用户直接访问管理员的接口路径/admin/user/export如果网关没做角色校验一个普通权限 token 也能下载全量用户数据。支付逻辑支付订单时把price从 100 改成 1或者把quantity改成 -1 导致应付金额为负数商城系统在服务端没有重新计算金额。验证码逻辑短信验证码不失效、不限制次数同一个验证码可以被反复提交或者验证码校验通过后重置下一个步骤的 token导致可直接跳到修改密码步骤。状态机绕过订单流程是“待支付→已支付→发货→完成”如果请求直接把状态字段改成“已发货”服务端没有校验前置状态。这些漏洞看起来很“笨”但在真实业务里非常常见因为开发同学很容易只对“输入内容”做校验而忽略“操作链路”本身的合法性。你在测试时多问一句这个操作是当前角色在正常业务流转里能够完成的吗大概率就能找到突破口。3.3 一个表格理清常见漏洞的触发条件我把平时测试时最常用的判断表放出来建议你存一份漏洞类型核心触发条件典型入口快速验证方式SQL 注入参数进入数据库查询且无预编译搜索、排序、分页、ID 参数单引号引发报错或sleep(0.1)观察延迟XSS输入输出链路上没有转义/CSP搜索回显、评论、昵称、富文本提交带标签的字符观察是否原样渲染CSRF敏感操作仅靠 Cookie 鉴权且无随机 Token改密、改邮箱、删除订单构造跨站表单验证是否生效SSRF服务端发起请求时 URL 可控图片代理、文件预览、Webhook 地址用可观察的临时回调地址确认请求真实性文件上传绕过仅校验后缀或 Content-Type头像上传、附件上传先传正常文件再尝试内容伪造或解析绕过越权接口只验登录态未验资源归属订单详情、个人信息、文件下载切换账号重放同一请求逻辑漏洞操作链路或金额字段缺少服务端校验支付、优惠券、身份审核修改金额/数量/状态字段重放并观察结果路径穿越下载接口拼接文件名且不做归一化文件下载、附件预览用../序列测试响应内容这张表我会贴在工位旁边虽然干了这么多年偶尔还是会拿出来提醒自己不要因为某个功能长得很普通就觉得它不值得测。4. 一条完整的实战链路信息收集—测试—验证—报告4.1 信息收集的广度和深度很多文章会讲一堆信息收集工具但我更想讲一个“节奏”问题信息收集至少做两轮。第一轮是快速轮廓扫描。目标范围内有哪些域名、IP、端口、中间件半小时内尽快建立全局视图。这轮的目的不是发现所有细节而是知道哪些点值得深入。第二轮是定向深挖。当你锁定某个子系统或某个功能模块后再把收集粒度放大抓取页面中的 JS 文件提取其中的接口地址、参数名、可能存在的硬编码 key查看登录请求的完整消息体判断凭证格式和会话机制观察接口返回的错误信息判断后端语言和框架的识别特征。这时候的信息收集越细后面测试的准确性就越高。我举一个真实经验。有一次发现某系统的文件下载接口把fileUrl参数直接当作值为http://xxx.xxx.xxx/file/123.png的完整 URL 处理我当时的第一反应就是 SSRF。接着我深挖了一下这条参数链发现后端用 Java 的URL.openConnection()去请求这个 URL并且响应内容直接写入下载流。这个链路里用户同时控制了“请求地址”和“响应输出位置”是一个非常标准的 SSRF 打内网并回显结果的入口。如果一开始只跑通用目录扫描根本不会发现这类问题。4.2 测试过程中的证据链意识这是我最想强调的一件事测试是攻防过程报告是裁判过程。你挖到了漏洞但没有留下能说服审核人员复现的证据链报告大概率会被打回。所以从开始测试的第一秒起就要带着证据链意识。具体来说我的习惯是每个测试用例单独建一个存档目录命名格式为“日期_目标_功能点_漏洞预判”例如20250105_report_sys_search_xss每个请求和响应都完整保存报文包含请求头、Cookies、请求体、响应状态和响应正文关键验证位置用截图或文本 diff 标注清楚比如正常请求返回 200 且包含用户 A 的数据越权请求返回 200 且包含用户 B 的身份证号两者对比一目了然记录测试时间、账号角色、操作步骤尽量让复现者可以照着一步步走下来。不要嫌麻烦。我在上一个授权项目里光是一项越权漏洞的复现包就存了三份请求、五张截图结果审核人员两分钟就确认了高危定级。反过来我也见过有人明明测出了 SSRF 但没保存完整的响应内容审核让他补证据时目标已经修复本来可以收一个高危最后空手而归。证据链的完整程度直接影响你对漏洞价值的兑现。4.3 报告的写法决定你的漏洞能不能被确认报告是漏洞挖掘的最后一公里偏偏很多人在这里翻车。一份能被快速确认的报告一般包含五个要素漏洞描述与影响范围直接说清楚这是什么漏洞、影响哪些接口和数据。复现步骤从登录到触发漏洞每一步都写清楚包括账号角色和前置条件。请求与响应样例贴出关键报文的简化版本去掉无意义的 header保留核心参数。危害证明最好能给出“成功读取了某用户敏感信息”或“验证码校验被绕过并成功修改密码”这类结论性证据。修复建议哪怕你只写一句“校验数据归属使用预编译查询”也会比空白报告显得专业得多。我自己写报告的习惯是先写结论再写步骤最后附证据。审报告的人通常很忙他们想快速确认的是“这个问题是否存在”而不是看你炫技。把证据摆清楚比写三千字分析更有效。5. AI 工具在这个时代能帮你做些什么5.1 代码审计场景下的 AI 用法现在做漏洞挖掘完全不提 AI 已经不现实了。尤其是拿到一套前端带源码或者部分后端逻辑的目标时AI 工具能极大提升审计效率。像我现在常用的 AI IDE 辅助工具包括 Trae 这类集成 AI 能力的开发环境很适合当“第二双眼睛”。我的用法是把可疑的 Controller 代码片段贴给 AI让它帮我回答三个问题——这段代码的参数来源是外部请求还是内部调用有没有经过过滤或白名单校验谁能触发到这段逻辑AI 在“梳理调用链”这件事上做得特别好能在几秒内把函数间的调用关系理出来省掉我逐行翻代码的时间。再比如让我手工提取前端 JS 里的接口和参数我也会让 AI 写一个正则表达式或者脚本批量解析文件把可疑的鉴权参数名和无注释接口汇总成表。还有一个更实用的场景写检测脚本。比如目标是一个有大量接口的 API 网关你想批量测试越权手工一条条改 Cookie 太慢。让 AI 先写一个简易脚本遍历接口清单并替换请求里的账号标识再用两个不同角色账号去回放最后对比响应差异。AI 生成脚本的能力已经在可用水平但前提是你得把需求描述得非常具体包括接口格式、鉴权 Header 样式、结果输出字段。5.2 自动化辅助的边界与坑不过我得泼一盆冷水AI 目前最大的问题是会“一本正经地胡说八道”。它可能在给你写越权检测脚本时自动把一个不存在的接口路径补上也可能在分析代码时把某个普通赋值当成“硬编码凭证”输出为高风险提示。你要是完全信任它很容易被带偏。我踩过的一个坑是让 AI 帮我分析一段包含第三方回调地址的代码它很自信地指出这个地址可控、存在 SSRF。但实际测试里这段代码对外部输入的 URL 做了 host 白名单校验非授权域名直接抛异常。如果我把 AI 的判断当成结论写进报告审核第一轮就会被驳回。所以我现在给自己定了一条铁律AI 的所有判断只能作为线索必须经过手工验证才算有效证据。这个原则放在业务逻辑漏洞上尤其重要因为 AI 目前很难理解“运营后台的角色权限”和“前台用户的访问条件”这些业务语义。说到底AI 在漏洞挖掘里是放大器放大的是你的判断能力永远不会取代你的判断本身。你用得好它可以帮你半小时干完三小时的体力活你用不好它会用错误结论消耗你更多时间去纠偏。6. 想快速上手edusrc 是最适合新手的练手场6.1 为什么推荐教育行业漏洞响应经常有人问我“新人想练手去哪个平台最好”我的回答大概率是 edusrc也就是教育行业的漏洞响应平台。原因不在于它漏洞最多而在于它最适合用来建立完整闭环。教育行业数字化程度很高门户网站、教务系统、图书馆、一卡通、在线考试、课程平台等等资产类型非常丰富而且各学校之间技术栈差异大有的用统一框架有的是老项目赶工改出来的。这意味着你的攻击面种类足够多能找到练手的感觉。更重要的是教育行业很多系统的防护强度相对有限一些在互联网厂商身上已经很难见到的经典漏洞在这里还有存活空间。当然安全性始终要放在第一位。你需要先确认目标属于平台的授权范围内遵守平台规则只做验证不作恶不下载大范围数据不进行破坏性测试。SRC 存在的意义是“让有防御能力的人帮助加固系统”不是给攻击行为提供一个合法外衣。把这个边界想清楚后面的练习才踏实。edusrc 对新手友好的另一个点是反馈机制清晰确认等级和修复通报都比较规范。你可以清楚看到自己提交的漏洞被判定为什么级别、为什么不通过。这种反馈迭代速度对入门期太重要了。6.2 一条可执行的新手路线图如果你想照着练我建议按下面的节奏来每段时间都有明确目标第 1-2 周补齐 Web 基础三件套。理解 HTTP 请求的组成、Cookie 和 Session 的鉴权逻辑、同源策略的边界。不用深挖算法但要清楚一个请求从浏览器到服务端发生了哪些关键变化。第 3-4 周掌握核心测试工具。学会 Burp Suite 的 Proxy 拦截、Repeater 改包重放、Intruder 批量枚举再搭配一款目录扫描工具和一款指纹识别工具。工具不在多在于顺手。第 5-8 周在靶场练手。用 DVWA、Juice Shop 等本地靶场把 SQL 注入、XSS、越权、SSRF 逐类做一遍重点是观察漏洞产生的现象而不是背 payload。第 9 周以后开始真实目标。从 edusrc 挑选一个目标系统先做资产盘点和功能点梳理再建立一个“功能点 × 漏洞类型”的测试矩阵然后一个格子一个格子地测。每个发现都写成报告坚持两到三个月你会明显感受到“思路”比“工具”重要得多。我在带新人时发现一个规律能在三个月内出第一个有效漏洞的人几乎都坚持做了测试矩阵这一步。而那些天天问“今天拿什么工具能出洞”的人往往半年还在原地打转。另外一个特别实用的习惯是每次测试开始前花十分钟把一个系统中“你做不了的事”列出来。比如“我是普通用户我不能删除他人评论”“我是老师我不能修改自己的评教成绩”。然后你就去测这些“我不能做的事”看看系统是不是真的拦住了你。这个思路非常简单但它就是越权漏洞的核心密码也是逻辑漏洞挖掘者最日常的思考方式。最后分享一个我坚持了很多年的小习惯每次挖完一个洞不论大小我都会把完整的测试矩阵和实际验证过程整理成一份反思笔记不是流水账而是写清楚“当时为什么走到了这一步、哪条路径被否定了”。时间久了这份笔记就成了我自己的漏洞模式库。很多所谓的高手其实只是在参考库里积累得足够多一眼就能把当前目标的关键路径对应上而已。对你来说如果也能把这个习惯坚持下来别的不说三个月内你一定会比现在清晰很多。