1. 先把“漏洞挖掘”这件事想清楚你找的到底是什么很多新手问我漏洞挖掘是不是特别高大上是不是要会各种高深的理论才能上手。其实真不是。我做了几年众测项目之后最大的感受是漏洞挖掘这件事本质上就是**“找输入、看输出、理逻辑”**。你用你的脑袋模拟黑客的思路但目的是帮厂商把洞补上。众测平台给了一个合法授权的环境你在这个环境里放开手脚去测发现的问题会被官方确认并给予奖励这是目前新手入门网络安全最友好的路径之一。先说“找输入”。任何一个系统只要它运行着就一定在接收输入。你在登录框里填的用户名、你在搜索框里敲的关键字、你上传图片时附带的那串文件名、你请求接口时带上的参数这些都是输入。漏洞挖掘的第一步就是把这些输入点全部列出来然后思考一个问题如果我在这个位置塞进去一段不正常的数据系统会怎么反应再说“看输出”。输入被系统处理后会以某种形式返回给你。错误页面、报错信息、跳转地址、接口返回的JSON数据这些都是输出。输出里面往往藏着故事的结局——数据库报错了说明SQL语句拼接出了问题页面上出现了另一个用户的订单信息说明越权了接口吐出了不该出现的内部路径说明访问控制没做好。最后是“理逻辑”。逻辑漏洞是众测项目里最容易出高危的地方也是最考验脑力的地方。密码重置流程能不能被绕过、优惠券能不能重复使用、订单金额在提交时能不能被篡改、一个普通用户的请求能不能带上管理员的身份标识。这些问题不需要你懂多深的底层原理需要的是你对业务流程足够敏感愿意一步一步跟着系统的设计思路去思考“开发者在这里偷了什么懒”。我给新手一个很直接的建议不要一上来就抱着扫描器到处扫那是无头苍蝇。先拿一个目标走一遍完整业务把它的功能点画成一张流程图再对着图一个点一个点地过。这个习惯一旦养成你的漏洞发现率会成倍提升。适合谁看这篇文章如果你是完全零基础刚注册众测平台不知道从哪下手如果你已经参加过几次众测但提交的漏洞老是被忽略如果你面对一个目标不知道测哪里、怎么测这篇文章就是给你写的。我不会讲太多玄乎的理论都是我自己踩过坑之后总结出来的实操经验。1.1 漏洞的本质是“人不按规矩办事”我想用一个类比让你彻底理解漏洞是什么。假设你在网上买了一张电影票正常的流程是选座、付款、收到一个带二维码的凭证、进场时扫码核销。这套流程里所有的规则都是开发者写好的但开发者不可能做到面面俱到总有那么几个瞬间他会漏想一种情况。比如说选座时我能不能同时开两个页面抢同一排的两个座位付款时我能不能先支付一张票的钱然后篡改请求参数让系统以为我付了两张的钱扫码核销时系统只是简单地把二维码里的信息查了一下库并没有校验这个二维码是不是已经被用过了。这些“开发者没考虑到的场景”就是漏洞。漏洞挖掘的核心能力就是比开发者多想一步找到他没想到的那个边角场景。我常跟新人说你别把漏洞想成什么高深莫测的东西。SQL注入说白了就是“我把单引号传进去系统拼SQL语句时没过滤数据库就报错了”XSS说白了就是“我传了一段脚本进去系统原样存了下来别人的浏览器就执行了我的脚本”。这些原理听起来不难吧但你真去测的时候会发现系统的防护手段也在升级过滤、编码、WAF各种东西都有你想绕过去的难度就上来了。难的不是理解原理而是在层层防护下找到一个还能打进去的点。所以在众测项目里你会发现真正的高危漏洞往往出现在一些“不起眼”的地方一个老旧的导出报表功能、一个测试用的接口没删干净、一个忘记加权限判断的查询接口。这些地方往往没有经过严格的安全审查反而是最容易出成果的地方。这就是为什么我强调要把整个业务流程完整走一遍因为漏洞经常藏在流程的角落里而不是在人人都盯着的登录框里。1.2 新手最该改掉的三个错误习惯我见过太多新手在众测项目里浪费机会了总结下来有三个特别典型的错误习惯你一定要绕开。第一个是拿到目标就开扫。扫描器扫完目录再扫一遍端口满怀期待地看着输出列表结果厂商后台早就看到了你这一堆无效请求写了张低危报告或者直接忽略了。扫描器是工具不是主力。真正有效的渗透测试是把扫描结果当作线索结合人工分析去判断哪个点值得深挖。你扫到一个文件上传接口就要去测它的后缀名过滤是否严格、上传目录是否可解析、文件内容有没有做二次校验。扫描器只能告诉你这里有口井井里有没有水、水能不能喝得靠你自己弯腰去尝。第二个是不读规则就开始测。每个众测项目都有测试范围和禁止项这是天条。超出了授权范围轻则漏洞无效重则可能被拉黑甚至承担法律责任。很多人栽在这上面。你把目标放在业务A上接口却调了业务B的敏感数据你拿着它也传不上去拿了漏洞厂商直接给你拒了因为那不在授权范围内。还有一种情况是厂商明确说了“禁止测试某项功能”比如禁止使用破解工具、禁止进行拒绝服务测试你不看规则一上来就咔咔一顿打压测漏洞没测出来账号先没了。第三个是一个小问题反复提交不把链条打通。你发现了一个反射型XSS自己觉得挺高兴提交之后被驳回了原因是没有实际危害。很多人就卡在这里不会往前走一步。反射型XSS能不能配合CSRF变成存储型能不能利用同源策略的绕过让它变成会话劫持漏洞利用的价值是连出来的不是你找到一个点就完事的。你需要顺着这个点往下走看它能不能串成一条完整的攻击链。一个“低危XSS”如果配上“后台敏感操作无CSRF防护”可能就变成了一个中危如果再配上“管理员会话未设置HttpOnly”就直接变成高危了。新手缺的往往不是发现漏洞的能力而是把这个漏洞的价值挖到最大的能力。2. 众测项目的正确打开方式规则、范围与信息收集接下来讲众测项目的具体操作流程。先回答一个很多新手都会困惑的问题为什么我提交的漏洞总被忽略别人随便找找就能提交有效漏洞这背后的差距往往不是技术而是对项目的理解和对目标的熟悉程度。众测项目本质上是一个**“在有限时间内、有限范围内、发现尽可能多的有效漏洞”**的游戏。你不需要做一个完整的红队评估你只需要找到那么几个能证明危害的点把它讲清楚让厂商认可你的价值。所以你会看到有些经验丰富的人在项目上线后的第一个小时就提交了好几个有效漏洞因为他们知道这类系统最容易出问题的位置在哪里、哪些地方厂商通常没来得及做安全评估。2.1 吃透规则是性价比最高的第一步在我见过的所有无效提交里占比最大的一类就是“不在测试范围内”。有些项目只允许测试Web应用你却去扫了App的接口有些项目明确排除了某个子系统你却一头扎进去测了好久有些项目要求漏洞必须达到中危以上才算有效你提交了一堆低危的反射型XSS自然就被驳回了。我的习惯是拿到一个新项目先花十分钟把项目详情页从头到尾读一遍把以下信息记下来测试范围哪些域名或App被授权哪些明确禁止。漏洞评级规则厂商使用的是哪种评分标准各等级的漏洞分别对应什么要求。提交要求对报告格式有没有要求需不需要提供修复建议复现步骤要求到什么详细程度。奖励与审核审核周期多久同一漏洞先到先得非常明确吗有没有保底奖励。特别提醒厂商特别备注了哪些高危操作会被直接拉黑。这套信息对你后续所有工作都是指导性的。比如厂商的评分规则里写着“存储型XSS在登录场景加锁之后才算高危”那你发现一个存储型XSS就得多走一步路想办法拿到管理员权限再触发这样才能拿到高分。再比如厂商明确说“SQL注入需要在数据库配置层面验证危害”你光是报错信息就不够得把注入点打穿到能拿到数据才算数。我把读规则这件事形容为**“先看地图再进城”**。你不看地图就在城里乱闯运气好能撞到一两家店运气不好直接踩进禁区被保安带走。很多众测平台都有新手学苑或者历史漏洞报告花点时间看看别人在同一个项目里提交了什么类型的漏洞、怎么写报告能被采纳比你自己摸索半天的效率要高得多。2.2 信息收集的深度决定漏洞的高度信息收集这个词听起来很基础但真正做得好的人真不多。我见过太多新人目标域名一拿扫完子域名和端口就开始了“撞大运式测试”测到的漏洞自然也是东一榔头西一棒子。而一些老手呢会在正式开始测之前花几个小时收集目标的各种数字资产和暴露面信息然后带着一张地图去测试效率完全不一样。信息收集要做到什么程度我给你列一条参考线先收集根域名下的所有子域名找全资产的暴露面。我常用的方式包括证书透明度查询、DNS历史解析记录、搜索引擎站点收录。这些数据源可以交叉比对把目标公司所有的互联网资产全部捞出来。端口和服务识别做完之后重点留意Web服务、API服务、文件共享服务、管理后台类服务。这些是你最可能的突破口。指纹识别做起来判断目标使用的CMS、框架、中间件和版本号。版本信息直接对应你后续的漏洞查找方向如果你识别出目标使用了一个存在已知CVE的内容管理系统你就知道该往哪里翻了。最后收集因为这些系统而暴露在公网的敏感信息。包括代码仓库里的配置文件、被人传上网的内部文档、员工文档共享站点里泄露的账号信息。这类信息往往能帮你完成身份绕过、找到隐藏后台。做完这套基础收集你会发现自己对目标的了解程度已经远超只看项目详情页的时候。带着这份地图去测试你能精准定位哪些位置值得深挖、哪些位置看一眼就可以跳过。信息收集不是可有可无的步骤它是渗透测试的地基。2.3 一个适用于新手的快速信息收集实操清单我用一个模拟场景来给你演示这套流程怎么跑。假设目标名叫“模拟项目X”是一家做企业服务的公司给了你一个主域名。第一步先拿到这个域名下的子域名清单。我会用在线测绘平台搜一遍再去证书透明度日志里翻一遍两个结果去重合并得到一张几十条子域名的清单。这时候先不急着扫把每个子域名在浏览器里开一遍看看哪些是业务系统、哪些是测试环境、哪些是走向非常奇怪的老系统。我习惯在这里就打开抓包工具把每个站点的请求日志顺手存下来因为后面的测试会反复用到这些路径和参数。第二步把发现的管理后台、API网关、文件服务这类高价值目标单独拉出来做指纹识别。比如某个后台是PHP写的、用了某个低版本框架某个API网关的文档页面是默认开放的某台文件服务器没有加访问控制。每一条都是线索。第三步针对已经锁定的高价值子域名再做一次目录和接口爆破。这里新手最容易犯的一个错就是“爆破完就停”只盯着状态码200的页面看。实际上很多敏感接口返回的可能是403、302但这些状态码本身就是在告诉你“这个路径存在”你需要手动去访问一下看看它跳转到哪、为什么403大概率能发现新的入口。这套流程做完你对目标的测试工作才算是正式开始。但你别小看这几个小时的信息收集时间它直接决定了你后续能挖到什么样的漏洞。信息收集做得越深你手里的牌就越多。别人只看到登录框你看到了登录框背后的接口、服务器、历史遗留路径你自然比他更容易出成果。3. 众测实战从参数到逻辑的漏洞挖掘思路信息收集做完接下来就是真正的漏洞挖掘环节。这一节是全文的核心我会按“参数层、逻辑层、信息层”三个维度来拆解每个维度我都会结合众测项目里的真实场景把思路和技巧讲透。3.1 参数层漏洞盯住“用户能控制的每一个输入”参数层漏洞是漏洞挖掘的入门课也是众测项目里数量最多的漏洞类型。它的核心逻辑很简单凡是用户能控制的数据都是潜在的攻击面。这里的“用户能控制”包括URL参数、POST请求体、请求头、Cookie、上传的文件名和内容甚至包括一些看起来不可见的隐藏字段。新手最容易忽视的一类参数就是隐藏字段。很多系统在表单里放了一个input typehidden value100比如优惠券金额、用户角色、订单编号。开发者以为用户看不到就能保证安全实际上我在众测里见过太多系统在这种隐藏字段上翻车的。你把value从100改成10000提交后端如果没校验金额是否合法就直接按你提交的数据走流程了。这类漏洞在支付场景、积分商城场景里特别常见危害等级能到高危。另一个高频参数漏洞点是ID遍历。这类系统通常在URL里用自增数字作为对象标识比如/order?id10086。你试着把id改成10087、10088如果返回的是别人的订单信息那就是个越权漏洞。不要小看这种“笨办法”很多系统的鉴权只做在页面上接口层完全没做校验你只需要遍历就能拿到大量数据。参数层往里走一层就到了注入类漏洞。SQL注入的经典测试方式就是加单引号和and 11式的变体但现在的系统大多有基础和纵深防御。我的经验是与其用自动化工具到处跑不如先人工看请求包的参数结构找到那些参数值会被拼进SQL语句的位置。比如搜索功能、排序功能、导出功能这些地方的参数常常直接参与了数据库查询。你给排序参数传一个包含SQL语法的值观察返回结果有没有异常。关于WAF的绕过我只说一句绕WAF不是靠某个绝对有效的方法而是靠你对编码、大小写、内联注释、参数污染等手法的灵活组合。你多试几次总能找到一个防护没覆盖到的缝隙。但前提是你得先判断出目标到底有没有WAF怎么判断传一个典型的攻击载荷进去看返回包和响应时间跟正常请求有没有区别有区别说明后面可能有防护这才需要绕。3.2 逻辑层漏洞业务流程里的“想当然”逻辑漏洞是我个人最喜欢的类型因为这些洞往往不需要你懂多深的底层知识拼的是你对业务流程的理解程度和思维的发散能力。我常说找到一个逻辑漏洞本质上就是你发现了开发者写代码时脑子里那一个“想当然”的瞬间。最典型的逻辑漏洞场景是密码找回流程。开发者想用户忘了密码那就通过手机验证码重置吧。然后他默认了验证码只能试一次、默认了验证码不会被暴力枚举、默认了验证码只能作用在发起请求的那个账号上。结果你在测试时会发现验证码长度是4位且没限制尝试次数你直接暴力跑一遍就出了或者验证码和账号没绑定你把请求包里的用户名改成另一个地址验证码照样能通过。这种洞一出就是高危因为直接关系到账号安全。同样典型的是越权类操作。水平越权是同级用户之间互相访问数据垂直越权是普通用户执行了管理员才能执行的操作。我在众测里经典的测试方法是这样先用A账号走一遍业务流程把请求包全部记下来比如创建订单、查看订单、取消订单。然后换成B账号把请求包里的订单号改成A的订单号看能不能正常请求。如果返回了订单详情就是水平越权。再然后找到管理员的某个请求包把里面标识身份的字段换成自己账号的标识看接口到底有没有校验权限。很多系统在前端把管理按钮隐藏起来就以为安全了接口层完全裸奔这种垂直越权一测一个准。还有一种思路叫**“先操作后条件判断”**。这类逻辑漏洞很隐蔽因为它们藏在代码的执行顺序里。比如一个系统在创建订单时先扣减库存、再校验优惠券是否有效你用一张过期但面额很大的优惠券去下单系统照样收走了订单却在最后一步告诉你支付成功你白拿了一张大额优惠券能反复用。或者一个退款功能校验了退款金额不能超过订单金额但没校验同一个订单能不能重复申请退款你把同一笔订单反复退就薅到了羊毛。这类洞在众测里的评分通常不低因为它们是“规则设计”层面出了问题修复起来牵扯面大。3.3 信息层漏洞不该出现的页面数据信息泄露类漏洞是我认为新手最容易上手、也最不该错过的类型。它们不需要复杂的利用链你只需要做一个心细的人看到别人看不见的数据。最基础的是敏感目录信息泄露。你信息收集时发现有/backup、/test、/console这样的目录暴露在公网打开之后通常能直接看到源码打包、测试脚本、数据库配置文件。这类漏洞看似“低级”但危害极大因为攻击者拿到源码和配置之后距离拿下整个系统往往只差一步。众测厂商对这一类漏洞的重视程度非常高。其次是接口返回信息过度冗余。现在的系统大多是前后端分离的架构接口返回的数据结构由后端直接定义。我在测试模拟项目X时遇到过这样一个场景一个订单查询接口正常应该返回订单号和金额结果开发者在联调时把整个数据表结构都放在了返回结果里包含内部备注、客户手机号、后台操作日志。页面没展示这些字段但接口直接暴露了它们。这种洞的发现非常依赖你“随手抓包、随手看返回体”的习惯。还有一种是第三方组件信息泄露。目标系统可能用了某个开源组件组件自带的默认路径没删除比如监控台、心跳检测接口。你去访问一下系统把内部架构、服务名称、依赖组件版本全部告诉你。这些信息虽然不是直接漏洞但它们是你后续攻击路线的导航图。我更愿意把信息泄露看成一把钥匙它不直接开门但能告诉你门后面有什么。我在带新人时经常说一句话看到数据的时候停三秒想一下它为什么会出现在这里。这一条对信息层漏洞的挖掘特别关键。很多泄露不是无意的而是因为开发者想省事把一个大的数据结构直接序列化返回给前端。你只要养成了抓包看返回体的习惯这类漏洞对你来说就像捡钱一样。4. 写出让厂商心甘情愿打高分的漏洞报告前面讲了怎么挖洞这一节讲怎么把洞“卖”出好价钱。我自己见过太多技术能力不差的新人因为报告写得稀烂明明是个中高危漏洞硬生生被厂商降级了。也有反过来报告写得结构清晰、证据链完整低危的XSS被厂商认可为对后台安全有实际威胁而提级。报告是你和厂商之间唯一的沟通桥梁这桥搭得稳不稳直接决定了你的劳动有没有回报。4.1 报告的核心是“证明危害”而不是“堆截图”很多新人的报告上来就是一顿截图这个参数传了个单引号页面报错了我觉得这是SQL注入请厂商确认。我看了都想摇头你说这是SQL注入那危害是什么能拿到什么数据能影响多少用户厂商审核的人一天要审几十份报告时间是有限的你的报告能不能在30秒内让他看懂“这是个什么洞、危害有多严重、怎么复现”直接决定了这份报告的命运。写报告的本质是在给审核人员讲一个逻辑自洽的故事。你的故事需要包含四个要素起点是什么、发生了什么、导致了什么、厂商可以怎么修。起点就是漏洞位置和触发参数发生就是完整的复现步骤导致就是实际的危害证明修复建议是锦上添花但很加分。这四个要素缺一个报告的说服力就打折。我再强调一次“证明危害”的重要性。你说存储型XSS危害大光贴弹窗截图没用你得贴出“触发XSS之后攻击者可以拿到管理员的会话进而修改后台任意内容”这种带着攻击链条的完整证据。你说SQL注入危害大光贴报错信息没用你得通过注入点把数据库版本、当前用户权限、能访问到的数据量查出来。拿出来的证据越硬厂商对你的报告重视程度就越高。4.2 一份可用报告结构参考我习惯把众测报告写成下面这个结构这里给你做个参考漏洞标题标明位置加漏洞类型比如“某业务系统查询接口存在SQL注入漏洞可获取全部订单数据”简洁清楚一眼就知道个大概。漏洞等级根据厂商给定的评级标准自评不要乱标。如果你不确定可以写“建议等级”四个字再加一个主观建议。漏洞地址完整的URL包括请求方法、路径、参数。如果漏洞涉及多个接口全部列出来。漏洞描述用两三句话说清楚漏洞成因和危害不要长篇大论。这里最忌讳的是直接复制别处的模板一定要基于你实测的事实来写。复现步骤分步骤编号写清楚。每一步对应一张关键截图截图里要圈出重点位置。如果是接口测试把请求包完整贴出来把修改过的参数用高亮或者加粗标识出来。危害证明这是整个报告的灵魂。你需要在这里展示你最硬核的证据。比如SQL注入的当前用户权限、存储型XSS的完整利用链、越权拿到的其他用户数据样本注意脱敏。修复建议给出你认为合理的修复思路。参数校验、访问控制、编码输出按漏洞类型来。不是必要条件但写得好很加分。4.3 提交环节的注意事项提交报告时有两个特别容易踩的坑我单独拿出来讲。第一个是不要在报告里暴露过多敏感数据。你证明SQL注入危害时查到了用户手机号截图时要把这些数据打码。打码不是让你的证据变弱恰恰相反打码证明了你对数据安全的意识厂商会高看你一眼。我在审核别人提交的漏洞内部记录里见过有人把整库用户的手机号、身份证号原样贴出来这类报告反而会被认为提交者没有安全意识轻则扣分重则被拉进黑名单。第二个是提交前自查一遍漏洞是否真的是你测出来的是不是别人的已知漏洞。众测平台的规则一般是“先到先得”如果别人比你先提交了同一个漏洞你的报告就白写了。所以你在深挖一个点的时候如果发现了疑似漏洞不要拖太久先写一份简版报告提交占坑然后继续完善详细版本。这里有个小技巧很多人会忽视提交时间不重要完成质量很重要。与其第一个小时提交一份毛糙的报告不如花半小时把证据链补完整再提交。但前提是这个洞还没有被别人交过你要是慢了半天可能就只剩遗憾了。5. 常见问题与排查技巧实录这一节是我最想对新手说的话。我把自己在众测项目里踩过的坑、翻过的车、总结出来的排查思路整理成一组实录你对照着看看能少走不少弯路。5.1 新手最容易翻车的几个场景第一类翻车是不看返回包就下结论。新手常常盯着页面上显示的内容页面没反应就以为没漏洞。实际上很多漏洞的响应藏在返回包的响应体里页面渲染不出来不代表接口没处理你的恶意数据。比如存储型XSS页面可能把脚本过滤了但看返回包你会发现数据确实被存进服务器了只是因为某种原因没在页面上原样输出。这时候你要做的不是放弃而是找一个能够原样输出内容的场景来验证。我测过不少系统登录页把XSS过滤得死死的但你换个导出Excel的功能脚本就原样躺在导出的单元格里了。第二类翻车是把业务校验和权限校验混为一谈。很多系统对请求里的业务数据做了校验但没对执行这个操作的人做权限校验。比如你调用了一个删除数据的接口正常请求是可以删除自己的数据的你换成删除别人的数据试试。如果接口直接执行了说明这是一个垂直越权。有些新手会在这一点上纠结半天以为系统校验了业务数据就等于安全的其实完全不是一回事。第三类翻车是只测一个点不测完整流程。你发现了一个上传功能急着传PHP文件上去试能不能执行结果被WAF拦了就下结论“这个上传是安全的”。但上传漏洞不只是“上传可执行文件”这一种玩法。你可以试试上传一个带SVG的图片文件SVG里能包含脚本在一些特定场景下就是XSS你也可以把上传的文件路径里加点特殊字符造成路径穿越覆盖服务器上的关键文件你还可以尝试上传超大文件、巧构内容让后端解析器出错产生信息泄露。一个漏洞点有无数种打开方式你只试了一种就下结论等于把一个金矿看成了一块石头。5.2 排查一条“疑似漏洞”的完整思路新人最大的误区是看到一点异常就急着提交然后被驳回。我教大家一条排查疑似漏洞的思路你自己对着走一遍能筛掉一半的无效提交。当你发现某个输入点存在疑似异常时先问自己三个问题第一个问题这个异常是否在正常业务范围内比如你传了一个超长字符串页面报了个500错误。这个报错可能只是正常业务没考虑到超长输入不一定就是漏洞。你需要继续验证这个报错有没有泄露敏感信息这个超长输入能不能进一步利用成SQL注入或缓冲区溢出如果不能你只是遇到了一个健壮性问题不够提交标准。第二个问题这个异常是否可被外部稳定触发有些漏洞你测试的时候能触发但要求攻击者具备一些不太现实的条件。比如你发现某个接口存在时间盲注但需要提前拿到一个只能通过管理员操作才能生成的token。那这个漏洞的实际可利用性就差了很多提交时会大打折扣。你需要分清哪些是“理论上存在”的漏洞哪些是“实际可被利用”的漏洞。第三个问题这个异常的影响边界在哪里你找到一个反射型XSS影响的是别人点链接才可能被攻击危害有限自评低危比较合理。同样是XSS如果发生在后台内容编辑器里任何管理员发文时都会触发那危害就大得多自评中危或者高危也不夸张。影响边界是评级的关键你需要想清楚你这个漏洞打到最远能打到哪。这三个问题想清楚之后你再动手写报告。我敢说你按这条思路走完的报告被驳回的概率至少下降一半。5.3 关于工具的一点心得工具这一块我讲得不多但确实是很多新人的执念总觉得工具越猛越能出成果。我的态度是工具很重要但作用是帮你提高效率不是替你思考。你要是刚开始做众测我建议你把下面这几类工具的用法吃透就够打出不错的战绩了流量抓包与改包工具这是必选项是手工测试的入场券。你需要随时查看请求和响应包、修改参数重放请求、构造各种边界值。目录与接口扫描工具用来快速发现目标站点的隐藏路径。注意控制并发和速率众测项目通常会限制扫描强度别把厂商的系统扫挂了那是重大事故。浏览器开发者工具很多人不够重视它其实它是个隐藏的宝贝。前端代码里经常藏着接口地址、加密逻辑、权限判断逻辑你随手翻一翻就能发现不少线索。一款好用的笔记工具有条理地记录你的测试子域名清单、接口清单、状态和截图。测试过程跨度几天很常见笔记记不清你会后悔的。最后叮嘱一句绝对不要用你拿到的账号做任何超出测试范围的操作更不要利用你发现的漏洞获取敏感数据用于任何非授权的目的。众测规则写在明面上这是合法合规的漏洞发现与报告行为你碰了红线技术能力再强也没人保你。我在实际带人的过程中发现能把工具用好的新人不少但能把“思路”训练出来的新人真的不多。我希望你读完这篇文章之后不只是多了几条技巧而是对漏洞挖掘这件事建立了正确的认知它是一门基于逻辑和细心的手艺不是碰运气的赌博。你把这套思路带到任何一个众测项目里踏踏实实走完整个流程就会发现自己提交的报告越来越有效打出来的等级也越来越稳定。 
长河君 · 2026/10/21 23:14:47 · 阅读 1.2k 众测实战指南：漏洞挖掘思路、渗透测试技巧与报告撰写
1. 先把“漏洞挖掘”这件事想清楚你找的到底是什么很多新手问我漏洞挖掘是不是特别高大上是不是要会各种高深的理论才能上手。其实真不是。我做了几年众测项目之后最大的感受是漏洞挖掘这件事本质上就是**“找输入、看输出、理逻辑”**。你用你的脑袋模拟黑客的思路但目的是帮厂商把洞补上。众测平台给了一个合法授权的环境你在这个环境里放开手脚去测发现的问题会被官方确认并给予奖励这是目前新手入门网络安全最友好的路径之一。先说“找输入”。任何一个系统只要它运行着就一定在接收输入。你在登录框里填的用户名、你在搜索框里敲的关键字、你上传图片时附带的那串文件名、你请求接口时带上的参数这些都是输入。漏洞挖掘的第一步就是把这些输入点全部列出来然后思考一个问题如果我在这个位置塞进去一段不正常的数据系统会怎么反应再说“看输出”。输入被系统处理后会以某种形式返回给你。错误页面、报错信息、跳转地址、接口返回的JSON数据这些都是输出。输出里面往往藏着故事的结局——数据库报错了说明SQL语句拼接出了问题页面上出现了另一个用户的订单信息说明越权了接口吐出了不该出现的内部路径说明访问控制没做好。最后是“理逻辑”。逻辑漏洞是众测项目里最容易出高危的地方也是最考验脑力的地方。密码重置流程能不能被绕过、优惠券能不能重复使用、订单金额在提交时能不能被篡改、一个普通用户的请求能不能带上管理员的身份标识。这些问题不需要你懂多深的底层原理需要的是你对业务流程足够敏感愿意一步一步跟着系统的设计思路去思考“开发者在这里偷了什么懒”。我给新手一个很直接的建议不要一上来就抱着扫描器到处扫那是无头苍蝇。先拿一个目标走一遍完整业务把它的功能点画成一张流程图再对着图一个点一个点地过。这个习惯一旦养成你的漏洞发现率会成倍提升。适合谁看这篇文章如果你是完全零基础刚注册众测平台不知道从哪下手如果你已经参加过几次众测但提交的漏洞老是被忽略如果你面对一个目标不知道测哪里、怎么测这篇文章就是给你写的。我不会讲太多玄乎的理论都是我自己踩过坑之后总结出来的实操经验。1.1 漏洞的本质是“人不按规矩办事”我想用一个类比让你彻底理解漏洞是什么。假设你在网上买了一张电影票正常的流程是选座、付款、收到一个带二维码的凭证、进场时扫码核销。这套流程里所有的规则都是开发者写好的但开发者不可能做到面面俱到总有那么几个瞬间他会漏想一种情况。比如说选座时我能不能同时开两个页面抢同一排的两个座位付款时我能不能先支付一张票的钱然后篡改请求参数让系统以为我付了两张的钱扫码核销时系统只是简单地把二维码里的信息查了一下库并没有校验这个二维码是不是已经被用过了。这些“开发者没考虑到的场景”就是漏洞。漏洞挖掘的核心能力就是比开发者多想一步找到他没想到的那个边角场景。我常跟新人说你别把漏洞想成什么高深莫测的东西。SQL注入说白了就是“我把单引号传进去系统拼SQL语句时没过滤数据库就报错了”XSS说白了就是“我传了一段脚本进去系统原样存了下来别人的浏览器就执行了我的脚本”。这些原理听起来不难吧但你真去测的时候会发现系统的防护手段也在升级过滤、编码、WAF各种东西都有你想绕过去的难度就上来了。难的不是理解原理而是在层层防护下找到一个还能打进去的点。所以在众测项目里你会发现真正的高危漏洞往往出现在一些“不起眼”的地方一个老旧的导出报表功能、一个测试用的接口没删干净、一个忘记加权限判断的查询接口。这些地方往往没有经过严格的安全审查反而是最容易出成果的地方。这就是为什么我强调要把整个业务流程完整走一遍因为漏洞经常藏在流程的角落里而不是在人人都盯着的登录框里。1.2 新手最该改掉的三个错误习惯我见过太多新手在众测项目里浪费机会了总结下来有三个特别典型的错误习惯你一定要绕开。第一个是拿到目标就开扫。扫描器扫完目录再扫一遍端口满怀期待地看着输出列表结果厂商后台早就看到了你这一堆无效请求写了张低危报告或者直接忽略了。扫描器是工具不是主力。真正有效的渗透测试是把扫描结果当作线索结合人工分析去判断哪个点值得深挖。你扫到一个文件上传接口就要去测它的后缀名过滤是否严格、上传目录是否可解析、文件内容有没有做二次校验。扫描器只能告诉你这里有口井井里有没有水、水能不能喝得靠你自己弯腰去尝。第二个是不读规则就开始测。每个众测项目都有测试范围和禁止项这是天条。超出了授权范围轻则漏洞无效重则可能被拉黑甚至承担法律责任。很多人栽在这上面。你把目标放在业务A上接口却调了业务B的敏感数据你拿着它也传不上去拿了漏洞厂商直接给你拒了因为那不在授权范围内。还有一种情况是厂商明确说了“禁止测试某项功能”比如禁止使用破解工具、禁止进行拒绝服务测试你不看规则一上来就咔咔一顿打压测漏洞没测出来账号先没了。第三个是一个小问题反复提交不把链条打通。你发现了一个反射型XSS自己觉得挺高兴提交之后被驳回了原因是没有实际危害。很多人就卡在这里不会往前走一步。反射型XSS能不能配合CSRF变成存储型能不能利用同源策略的绕过让它变成会话劫持漏洞利用的价值是连出来的不是你找到一个点就完事的。你需要顺着这个点往下走看它能不能串成一条完整的攻击链。一个“低危XSS”如果配上“后台敏感操作无CSRF防护”可能就变成了一个中危如果再配上“管理员会话未设置HttpOnly”就直接变成高危了。新手缺的往往不是发现漏洞的能力而是把这个漏洞的价值挖到最大的能力。2. 众测项目的正确打开方式规则、范围与信息收集接下来讲众测项目的具体操作流程。先回答一个很多新手都会困惑的问题为什么我提交的漏洞总被忽略别人随便找找就能提交有效漏洞这背后的差距往往不是技术而是对项目的理解和对目标的熟悉程度。众测项目本质上是一个**“在有限时间内、有限范围内、发现尽可能多的有效漏洞”**的游戏。你不需要做一个完整的红队评估你只需要找到那么几个能证明危害的点把它讲清楚让厂商认可你的价值。所以你会看到有些经验丰富的人在项目上线后的第一个小时就提交了好几个有效漏洞因为他们知道这类系统最容易出问题的位置在哪里、哪些地方厂商通常没来得及做安全评估。2.1 吃透规则是性价比最高的第一步在我见过的所有无效提交里占比最大的一类就是“不在测试范围内”。有些项目只允许测试Web应用你却去扫了App的接口有些项目明确排除了某个子系统你却一头扎进去测了好久有些项目要求漏洞必须达到中危以上才算有效你提交了一堆低危的反射型XSS自然就被驳回了。我的习惯是拿到一个新项目先花十分钟把项目详情页从头到尾读一遍把以下信息记下来测试范围哪些域名或App被授权哪些明确禁止。漏洞评级规则厂商使用的是哪种评分标准各等级的漏洞分别对应什么要求。提交要求对报告格式有没有要求需不需要提供修复建议复现步骤要求到什么详细程度。奖励与审核审核周期多久同一漏洞先到先得非常明确吗有没有保底奖励。特别提醒厂商特别备注了哪些高危操作会被直接拉黑。这套信息对你后续所有工作都是指导性的。比如厂商的评分规则里写着“存储型XSS在登录场景加锁之后才算高危”那你发现一个存储型XSS就得多走一步路想办法拿到管理员权限再触发这样才能拿到高分。再比如厂商明确说“SQL注入需要在数据库配置层面验证危害”你光是报错信息就不够得把注入点打穿到能拿到数据才算数。我把读规则这件事形容为**“先看地图再进城”**。你不看地图就在城里乱闯运气好能撞到一两家店运气不好直接踩进禁区被保安带走。很多众测平台都有新手学苑或者历史漏洞报告花点时间看看别人在同一个项目里提交了什么类型的漏洞、怎么写报告能被采纳比你自己摸索半天的效率要高得多。2.2 信息收集的深度决定漏洞的高度信息收集这个词听起来很基础但真正做得好的人真不多。我见过太多新人目标域名一拿扫完子域名和端口就开始了“撞大运式测试”测到的漏洞自然也是东一榔头西一棒子。而一些老手呢会在正式开始测之前花几个小时收集目标的各种数字资产和暴露面信息然后带着一张地图去测试效率完全不一样。信息收集要做到什么程度我给你列一条参考线先收集根域名下的所有子域名找全资产的暴露面。我常用的方式包括证书透明度查询、DNS历史解析记录、搜索引擎站点收录。这些数据源可以交叉比对把目标公司所有的互联网资产全部捞出来。端口和服务识别做完之后重点留意Web服务、API服务、文件共享服务、管理后台类服务。这些是你最可能的突破口。指纹识别做起来判断目标使用的CMS、框架、中间件和版本号。版本信息直接对应你后续的漏洞查找方向如果你识别出目标使用了一个存在已知CVE的内容管理系统你就知道该往哪里翻了。最后收集因为这些系统而暴露在公网的敏感信息。包括代码仓库里的配置文件、被人传上网的内部文档、员工文档共享站点里泄露的账号信息。这类信息往往能帮你完成身份绕过、找到隐藏后台。做完这套基础收集你会发现自己对目标的了解程度已经远超只看项目详情页的时候。带着这份地图去测试你能精准定位哪些位置值得深挖、哪些位置看一眼就可以跳过。信息收集不是可有可无的步骤它是渗透测试的地基。2.3 一个适用于新手的快速信息收集实操清单我用一个模拟场景来给你演示这套流程怎么跑。假设目标名叫“模拟项目X”是一家做企业服务的公司给了你一个主域名。第一步先拿到这个域名下的子域名清单。我会用在线测绘平台搜一遍再去证书透明度日志里翻一遍两个结果去重合并得到一张几十条子域名的清单。这时候先不急着扫把每个子域名在浏览器里开一遍看看哪些是业务系统、哪些是测试环境、哪些是走向非常奇怪的老系统。我习惯在这里就打开抓包工具把每个站点的请求日志顺手存下来因为后面的测试会反复用到这些路径和参数。第二步把发现的管理后台、API网关、文件服务这类高价值目标单独拉出来做指纹识别。比如某个后台是PHP写的、用了某个低版本框架某个API网关的文档页面是默认开放的某台文件服务器没有加访问控制。每一条都是线索。第三步针对已经锁定的高价值子域名再做一次目录和接口爆破。这里新手最容易犯的一个错就是“爆破完就停”只盯着状态码200的页面看。实际上很多敏感接口返回的可能是403、302但这些状态码本身就是在告诉你“这个路径存在”你需要手动去访问一下看看它跳转到哪、为什么403大概率能发现新的入口。这套流程做完你对目标的测试工作才算是正式开始。但你别小看这几个小时的信息收集时间它直接决定了你后续能挖到什么样的漏洞。信息收集做得越深你手里的牌就越多。别人只看到登录框你看到了登录框背后的接口、服务器、历史遗留路径你自然比他更容易出成果。3. 众测实战从参数到逻辑的漏洞挖掘思路信息收集做完接下来就是真正的漏洞挖掘环节。这一节是全文的核心我会按“参数层、逻辑层、信息层”三个维度来拆解每个维度我都会结合众测项目里的真实场景把思路和技巧讲透。3.1 参数层漏洞盯住“用户能控制的每一个输入”参数层漏洞是漏洞挖掘的入门课也是众测项目里数量最多的漏洞类型。它的核心逻辑很简单凡是用户能控制的数据都是潜在的攻击面。这里的“用户能控制”包括URL参数、POST请求体、请求头、Cookie、上传的文件名和内容甚至包括一些看起来不可见的隐藏字段。新手最容易忽视的一类参数就是隐藏字段。很多系统在表单里放了一个input typehidden value100比如优惠券金额、用户角色、订单编号。开发者以为用户看不到就能保证安全实际上我在众测里见过太多系统在这种隐藏字段上翻车的。你把value从100改成10000提交后端如果没校验金额是否合法就直接按你提交的数据走流程了。这类漏洞在支付场景、积分商城场景里特别常见危害等级能到高危。另一个高频参数漏洞点是ID遍历。这类系统通常在URL里用自增数字作为对象标识比如/order?id10086。你试着把id改成10087、10088如果返回的是别人的订单信息那就是个越权漏洞。不要小看这种“笨办法”很多系统的鉴权只做在页面上接口层完全没做校验你只需要遍历就能拿到大量数据。参数层往里走一层就到了注入类漏洞。SQL注入的经典测试方式就是加单引号和and 11式的变体但现在的系统大多有基础和纵深防御。我的经验是与其用自动化工具到处跑不如先人工看请求包的参数结构找到那些参数值会被拼进SQL语句的位置。比如搜索功能、排序功能、导出功能这些地方的参数常常直接参与了数据库查询。你给排序参数传一个包含SQL语法的值观察返回结果有没有异常。关于WAF的绕过我只说一句绕WAF不是靠某个绝对有效的方法而是靠你对编码、大小写、内联注释、参数污染等手法的灵活组合。你多试几次总能找到一个防护没覆盖到的缝隙。但前提是你得先判断出目标到底有没有WAF怎么判断传一个典型的攻击载荷进去看返回包和响应时间跟正常请求有没有区别有区别说明后面可能有防护这才需要绕。3.2 逻辑层漏洞业务流程里的“想当然”逻辑漏洞是我个人最喜欢的类型因为这些洞往往不需要你懂多深的底层知识拼的是你对业务流程的理解程度和思维的发散能力。我常说找到一个逻辑漏洞本质上就是你发现了开发者写代码时脑子里那一个“想当然”的瞬间。最典型的逻辑漏洞场景是密码找回流程。开发者想用户忘了密码那就通过手机验证码重置吧。然后他默认了验证码只能试一次、默认了验证码不会被暴力枚举、默认了验证码只能作用在发起请求的那个账号上。结果你在测试时会发现验证码长度是4位且没限制尝试次数你直接暴力跑一遍就出了或者验证码和账号没绑定你把请求包里的用户名改成另一个地址验证码照样能通过。这种洞一出就是高危因为直接关系到账号安全。同样典型的是越权类操作。水平越权是同级用户之间互相访问数据垂直越权是普通用户执行了管理员才能执行的操作。我在众测里经典的测试方法是这样先用A账号走一遍业务流程把请求包全部记下来比如创建订单、查看订单、取消订单。然后换成B账号把请求包里的订单号改成A的订单号看能不能正常请求。如果返回了订单详情就是水平越权。再然后找到管理员的某个请求包把里面标识身份的字段换成自己账号的标识看接口到底有没有校验权限。很多系统在前端把管理按钮隐藏起来就以为安全了接口层完全裸奔这种垂直越权一测一个准。还有一种思路叫**“先操作后条件判断”**。这类逻辑漏洞很隐蔽因为它们藏在代码的执行顺序里。比如一个系统在创建订单时先扣减库存、再校验优惠券是否有效你用一张过期但面额很大的优惠券去下单系统照样收走了订单却在最后一步告诉你支付成功你白拿了一张大额优惠券能反复用。或者一个退款功能校验了退款金额不能超过订单金额但没校验同一个订单能不能重复申请退款你把同一笔订单反复退就薅到了羊毛。这类洞在众测里的评分通常不低因为它们是“规则设计”层面出了问题修复起来牵扯面大。3.3 信息层漏洞不该出现的页面数据信息泄露类漏洞是我认为新手最容易上手、也最不该错过的类型。它们不需要复杂的利用链你只需要做一个心细的人看到别人看不见的数据。最基础的是敏感目录信息泄露。你信息收集时发现有/backup、/test、/console这样的目录暴露在公网打开之后通常能直接看到源码打包、测试脚本、数据库配置文件。这类漏洞看似“低级”但危害极大因为攻击者拿到源码和配置之后距离拿下整个系统往往只差一步。众测厂商对这一类漏洞的重视程度非常高。其次是接口返回信息过度冗余。现在的系统大多是前后端分离的架构接口返回的数据结构由后端直接定义。我在测试模拟项目X时遇到过这样一个场景一个订单查询接口正常应该返回订单号和金额结果开发者在联调时把整个数据表结构都放在了返回结果里包含内部备注、客户手机号、后台操作日志。页面没展示这些字段但接口直接暴露了它们。这种洞的发现非常依赖你“随手抓包、随手看返回体”的习惯。还有一种是第三方组件信息泄露。目标系统可能用了某个开源组件组件自带的默认路径没删除比如监控台、心跳检测接口。你去访问一下系统把内部架构、服务名称、依赖组件版本全部告诉你。这些信息虽然不是直接漏洞但它们是你后续攻击路线的导航图。我更愿意把信息泄露看成一把钥匙它不直接开门但能告诉你门后面有什么。我在带新人时经常说一句话看到数据的时候停三秒想一下它为什么会出现在这里。这一条对信息层漏洞的挖掘特别关键。很多泄露不是无意的而是因为开发者想省事把一个大的数据结构直接序列化返回给前端。你只要养成了抓包看返回体的习惯这类漏洞对你来说就像捡钱一样。4. 写出让厂商心甘情愿打高分的漏洞报告前面讲了怎么挖洞这一节讲怎么把洞“卖”出好价钱。我自己见过太多技术能力不差的新人因为报告写得稀烂明明是个中高危漏洞硬生生被厂商降级了。也有反过来报告写得结构清晰、证据链完整低危的XSS被厂商认可为对后台安全有实际威胁而提级。报告是你和厂商之间唯一的沟通桥梁这桥搭得稳不稳直接决定了你的劳动有没有回报。4.1 报告的核心是“证明危害”而不是“堆截图”很多新人的报告上来就是一顿截图这个参数传了个单引号页面报错了我觉得这是SQL注入请厂商确认。我看了都想摇头你说这是SQL注入那危害是什么能拿到什么数据能影响多少用户厂商审核的人一天要审几十份报告时间是有限的你的报告能不能在30秒内让他看懂“这是个什么洞、危害有多严重、怎么复现”直接决定了这份报告的命运。写报告的本质是在给审核人员讲一个逻辑自洽的故事。你的故事需要包含四个要素起点是什么、发生了什么、导致了什么、厂商可以怎么修。起点就是漏洞位置和触发参数发生就是完整的复现步骤导致就是实际的危害证明修复建议是锦上添花但很加分。这四个要素缺一个报告的说服力就打折。我再强调一次“证明危害”的重要性。你说存储型XSS危害大光贴弹窗截图没用你得贴出“触发XSS之后攻击者可以拿到管理员的会话进而修改后台任意内容”这种带着攻击链条的完整证据。你说SQL注入危害大光贴报错信息没用你得通过注入点把数据库版本、当前用户权限、能访问到的数据量查出来。拿出来的证据越硬厂商对你的报告重视程度就越高。4.2 一份可用报告结构参考我习惯把众测报告写成下面这个结构这里给你做个参考漏洞标题标明位置加漏洞类型比如“某业务系统查询接口存在SQL注入漏洞可获取全部订单数据”简洁清楚一眼就知道个大概。漏洞等级根据厂商给定的评级标准自评不要乱标。如果你不确定可以写“建议等级”四个字再加一个主观建议。漏洞地址完整的URL包括请求方法、路径、参数。如果漏洞涉及多个接口全部列出来。漏洞描述用两三句话说清楚漏洞成因和危害不要长篇大论。这里最忌讳的是直接复制别处的模板一定要基于你实测的事实来写。复现步骤分步骤编号写清楚。每一步对应一张关键截图截图里要圈出重点位置。如果是接口测试把请求包完整贴出来把修改过的参数用高亮或者加粗标识出来。危害证明这是整个报告的灵魂。你需要在这里展示你最硬核的证据。比如SQL注入的当前用户权限、存储型XSS的完整利用链、越权拿到的其他用户数据样本注意脱敏。修复建议给出你认为合理的修复思路。参数校验、访问控制、编码输出按漏洞类型来。不是必要条件但写得好很加分。4.3 提交环节的注意事项提交报告时有两个特别容易踩的坑我单独拿出来讲。第一个是不要在报告里暴露过多敏感数据。你证明SQL注入危害时查到了用户手机号截图时要把这些数据打码。打码不是让你的证据变弱恰恰相反打码证明了你对数据安全的意识厂商会高看你一眼。我在审核别人提交的漏洞内部记录里见过有人把整库用户的手机号、身份证号原样贴出来这类报告反而会被认为提交者没有安全意识轻则扣分重则被拉进黑名单。第二个是提交前自查一遍漏洞是否真的是你测出来的是不是别人的已知漏洞。众测平台的规则一般是“先到先得”如果别人比你先提交了同一个漏洞你的报告就白写了。所以你在深挖一个点的时候如果发现了疑似漏洞不要拖太久先写一份简版报告提交占坑然后继续完善详细版本。这里有个小技巧很多人会忽视提交时间不重要完成质量很重要。与其第一个小时提交一份毛糙的报告不如花半小时把证据链补完整再提交。但前提是这个洞还没有被别人交过你要是慢了半天可能就只剩遗憾了。5. 常见问题与排查技巧实录这一节是我最想对新手说的话。我把自己在众测项目里踩过的坑、翻过的车、总结出来的排查思路整理成一组实录你对照着看看能少走不少弯路。5.1 新手最容易翻车的几个场景第一类翻车是不看返回包就下结论。新手常常盯着页面上显示的内容页面没反应就以为没漏洞。实际上很多漏洞的响应藏在返回包的响应体里页面渲染不出来不代表接口没处理你的恶意数据。比如存储型XSS页面可能把脚本过滤了但看返回包你会发现数据确实被存进服务器了只是因为某种原因没在页面上原样输出。这时候你要做的不是放弃而是找一个能够原样输出内容的场景来验证。我测过不少系统登录页把XSS过滤得死死的但你换个导出Excel的功能脚本就原样躺在导出的单元格里了。第二类翻车是把业务校验和权限校验混为一谈。很多系统对请求里的业务数据做了校验但没对执行这个操作的人做权限校验。比如你调用了一个删除数据的接口正常请求是可以删除自己的数据的你换成删除别人的数据试试。如果接口直接执行了说明这是一个垂直越权。有些新手会在这一点上纠结半天以为系统校验了业务数据就等于安全的其实完全不是一回事。第三类翻车是只测一个点不测完整流程。你发现了一个上传功能急着传PHP文件上去试能不能执行结果被WAF拦了就下结论“这个上传是安全的”。但上传漏洞不只是“上传可执行文件”这一种玩法。你可以试试上传一个带SVG的图片文件SVG里能包含脚本在一些特定场景下就是XSS你也可以把上传的文件路径里加点特殊字符造成路径穿越覆盖服务器上的关键文件你还可以尝试上传超大文件、巧构内容让后端解析器出错产生信息泄露。一个漏洞点有无数种打开方式你只试了一种就下结论等于把一个金矿看成了一块石头。5.2 排查一条“疑似漏洞”的完整思路新人最大的误区是看到一点异常就急着提交然后被驳回。我教大家一条排查疑似漏洞的思路你自己对着走一遍能筛掉一半的无效提交。当你发现某个输入点存在疑似异常时先问自己三个问题第一个问题这个异常是否在正常业务范围内比如你传了一个超长字符串页面报了个500错误。这个报错可能只是正常业务没考虑到超长输入不一定就是漏洞。你需要继续验证这个报错有没有泄露敏感信息这个超长输入能不能进一步利用成SQL注入或缓冲区溢出如果不能你只是遇到了一个健壮性问题不够提交标准。第二个问题这个异常是否可被外部稳定触发有些漏洞你测试的时候能触发但要求攻击者具备一些不太现实的条件。比如你发现某个接口存在时间盲注但需要提前拿到一个只能通过管理员操作才能生成的token。那这个漏洞的实际可利用性就差了很多提交时会大打折扣。你需要分清哪些是“理论上存在”的漏洞哪些是“实际可被利用”的漏洞。第三个问题这个异常的影响边界在哪里你找到一个反射型XSS影响的是别人点链接才可能被攻击危害有限自评低危比较合理。同样是XSS如果发生在后台内容编辑器里任何管理员发文时都会触发那危害就大得多自评中危或者高危也不夸张。影响边界是评级的关键你需要想清楚你这个漏洞打到最远能打到哪。这三个问题想清楚之后你再动手写报告。我敢说你按这条思路走完的报告被驳回的概率至少下降一半。5.3 关于工具的一点心得工具这一块我讲得不多但确实是很多新人的执念总觉得工具越猛越能出成果。我的态度是工具很重要但作用是帮你提高效率不是替你思考。你要是刚开始做众测我建议你把下面这几类工具的用法吃透就够打出不错的战绩了流量抓包与改包工具这是必选项是手工测试的入场券。你需要随时查看请求和响应包、修改参数重放请求、构造各种边界值。目录与接口扫描工具用来快速发现目标站点的隐藏路径。注意控制并发和速率众测项目通常会限制扫描强度别把厂商的系统扫挂了那是重大事故。浏览器开发者工具很多人不够重视它其实它是个隐藏的宝贝。前端代码里经常藏着接口地址、加密逻辑、权限判断逻辑你随手翻一翻就能发现不少线索。一款好用的笔记工具有条理地记录你的测试子域名清单、接口清单、状态和截图。测试过程跨度几天很常见笔记记不清你会后悔的。最后叮嘱一句绝对不要用你拿到的账号做任何超出测试范围的操作更不要利用你发现的漏洞获取敏感数据用于任何非授权的目的。众测规则写在明面上这是合法合规的漏洞发现与报告行为你碰了红线技术能力再强也没人保你。我在实际带人的过程中发现能把工具用好的新人不少但能把“思路”训练出来的新人真的不多。我希望你读完这篇文章之后不只是多了几条技巧而是对漏洞挖掘这件事建立了正确的认知它是一门基于逻辑和细心的手艺不是碰运气的赌博。你把这套思路带到任何一个众测项目里踏踏实实走完整个流程就会发现自己提交的报告越来越有效打出来的等级也越来越稳定。