企业官网建设流程全解析

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 type="hidden" value="100">，比如优惠券金额、用户角色、订单编号。开发者以为用户看不到就能保证安全，实际上我在众测里见过太多系统在这种隐藏字段上翻车的。你把value从100改成10000提交，后端如果没校验金额是否合法，就直接按你提交的数据走流程了。这类漏洞在支付场景、积分商城场景里特别常见，危害等级能到高危。

另一个高频参数漏洞点是ID遍历。这类系统通常在URL里用自增数字作为对象标识，比如/order?id=10086。你试着把id改成10087、10088，如果返回的是别人的订单信息，那就是个越权漏洞。不要小看这种“笨办法”，很多系统的鉴权只做在页面上，接口层完全没做校验，你只需要遍历就能拿到大量数据。

参数层往里走一层，就到了注入类漏洞。SQL注入的经典测试方式就是加单引号和and 1=1式的变体，但现在的系统大多有基础和纵深防御。我的经验是，与其用自动化工具到处跑，不如先人工看请求包的参数结构，找到那些参数值会被拼进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 关于工具的一点心得

工具这一块我讲得不多，但确实是很多新人的执念，总觉得工具越猛越能出成果。我的态度是：工具很重要，但作用是帮你提高效率，不是替你思考。

你要是刚开始做众测，我建议你把下面这几类工具的用法吃透，就够打出不错的战绩了：

• 流量抓包与改包工具：这是必选项，是手工测试的入场券。你需要随时查看请求和响应包、修改参数重放请求、构造各种边界值。
• 目录与接口扫描工具：用来快速发现目标站点的隐藏路径。注意控制并发和速率，众测项目通常会限制扫描强度，别把厂商的系统扫挂了，那是重大事故。
• 浏览器开发者工具：很多人不够重视它，其实它是个隐藏的宝贝。前端代码里经常藏着接口地址、加密逻辑、权限判断逻辑，你随手翻一翻就能发现不少线索。
• 一款好用的笔记工具：有条理地记录你的测试子域名清单、接口清单、状态和截图。测试过程跨度几天很常见，笔记记不清你会后悔的。

最后叮嘱一句：绝对不要用你拿到的账号做任何超出测试范围的操作，更不要利用你发现的漏洞获取敏感数据用于任何非授权的目的。众测规则写在明面上，这是合法合规的漏洞发现与报告行为，你碰了红线，技术能力再强也没人保你。

我在实际带人的过程中发现，能把工具用好的新人不少，但能把“思路”训练出来的新人真的不多。我希望你读完这篇文章之后，不只是多了几条技巧，而是对漏洞挖掘这件事建立了正确的认知：它是一门基于逻辑和细心的手艺，不是碰运气的赌博。你把这套思路带到任何一个众测项目里，踏踏实实走完整个流程，就会发现自己提交的报告越来越有效，打出来的等级也越来越稳定。