企业官网建设流程全解析

我刚接触SRC那会儿，脑子里对漏洞挖掘的理解就是“拿扫描器到处跑，看到高危就交报告”。后来被评审连续打回好几份，我才慢慢琢磨出真正的src漏洞挖掘思路根本不是扫漏洞，而是读业务、找入口、验证影响。这篇文章没有教科书式的框架，更像我自己踩坑之后的笔记：从资产梳理、功能点定向、绕过思路，一直写到报告怎么交才不容易被打回。无论你是刚入安全圈的新人，还是在几个SRC平台之间来回尝试但产出不稳定的朋友，我都希望这份笔记能帮你把“碰运气”变成“有节奏地探测”。

1. 扫描器不是万能钥匙：先看清SRC到底在考什么

1.1 一只扫描器打天下的错觉

早期我习惯拿到资产后直接上扫描器，跑出一堆SQL注入和反射型XSS，兴冲冲提交，结果大多被标成“重复”或“忽略”。当时很不理解：明明技术上是漏洞，为什么平台不收？

后来一个简单的例子点醒了我。某次我对一个登录框提交了经典的单引号测试，数据库确实报了语法错误，但那个错误只在特定数据库版本、特定后端框架组合下才会出现，正常用户根本碰不到这个接口，而且同类问题已经被别人提交过。对SRC评审来说，这种“漏洞”没有真实危害链路，只是扫描器眼里的一串特征。

所以在SRC领域里，“漏洞=可控输入+未校验逻辑+可触达业务”这个公式比扫描器告警列表更有用。你提交的不是一个技术现象，而是一个“攻击者能利用它做什么”的完整故事。

1.2 从“找漏洞”转向“摸业务”

我后来把重心从漏洞类型清单换成了业务功能清单。每次拿到授权目标，先理清对方的业务模型：谁注册、谁登录、谁下单、谁导出数据、谁管理后台。每一段业务流转过程中，只要存在信任边界，就有可能被绕过。

举个最常见的例子。用户注册时只在客户端校验手机号格式，服务端不校验；那攻击者就可以拿一个不存在的号码注册，某些模块后续会因为这个脏数据产生异常行为。再比如，找回密码时校验验证码和修改密码是两个独立步骤，如果第二步没有重新绑定第一步的会话，就能篡改目标手机号，完成任意账号密码重置。

这些逻辑漏洞用扫描器根本跑不出来，得靠人顺着流程去理解“设计者默认了什么、信任了什么”。我自己的笔记里，每个业务功能都配了一个测试checklist，像查字典一样按流程逐项过，效率比漫无目的扫目录高得多。

2. 资产梳理：入口决定漏洞上限

一个SRC项目的测试范围通常很大，如果只盯着主域名，你会错过后台、测试站、第三方对接系统这些更容易出问题的地方。资产梳理的核心是“找全入口”，入口数量直接决定了你能发现漏洞的上限。

2.1 域名与子域名的收集顺序

我习惯按这个顺序做：

1. 从厂商授权的根域名开始，先看证书透明日志，拉出所有子域名。
2. 再用字典对已知域名做一轮子域枚举，互补覆盖。
3. 最后把相同IP、相同指纹的主机做聚合去重，同时查一下历史DNS记录，看看有没有被下线但仍有解析的资产。

证书日志这步经常被新手忽略，但它经常会暴露一些非正式命名的系统，比如内网管理平台、监控面板、临时上线的前端页面。子域枚举结果里，每个CNAME指向第三方云服务的记录更值得留意，因为这类资产经常存在配置错误，比如对象存储权限配置不当，可枚举或越权读取文件。

2.2 Web指纹、JS文件与接口提取

识别Web指纹不是只为了匹配公开CVE，更重要的是帮助你判断技术栈和常见漏洞点。比如某个后台用的是低版本框架，那我可以优先找未授权接口和默认路径，而不是漫无目的地全站扫描。

我每次都会把目标站点所有JS文件下载到本地，然后搜几个高频关键词：api、admin、token、secret、upload、debug。很多项目会不小心把接口地址、加密规则甚至云存储密钥直接写在前端代码里。有一次我就是在某个JS文件的注释里发现了一个隐藏的管理接口，直接跳到未授权访问测试。这类信息提取用脚本批量做会快很多：

grep -rE "api/|/admin|token|secret|upload|debug" ./js_files

接口列表整理出来后，再对每个接口标注“登录后可访问”“无鉴权”“参数包含对象ID”，后面测越权时就有的放矢了。

2.3 目录扫描与端口服务的取舍

目录扫描不是越猛越好。我见过有人用超大字典全速跑，结果目标直接拒绝服务，界面几小时都进不去。SRC测试是授权范围里的测试，但也要尽量降低影响。我建议把并发压到5到10，超时时间调短，重点观察返回码的差异，而不是只盯着200。

在封禁和风控策略比较严格的目标上，柔和扫描往往能获得更多有效结果。返回403的路径尤其值得记录，它很可能存在但被访问控制策略拦住了，后续可以带着绕过思路再测一轮。端口方面，只关注在授权范围和业务范围内的服务，比如未授权访问的Redis、Nacos这类组件的风险，但不同SRC平台对基础组件的收录态度不一样，动手之前先读平台公告，能省掉很多白工。

3. 定向漏洞类型：照着业务功能测

很多人问我“SRC漏洞挖掘到底优先测哪几类”，我的回答是：看目标提供什么业务，就测什么逻辑。但在几乎所有平台上，越权、业务逻辑、文件上传、存储型XSS这四类都是高频收入来源。

3.1 越权：改ID就能拿分的IDOR

越权的测试前提很简单：注册两个普通账号，申请一个接口请求，然后把请求里的对象参数替换成另一个账号的对象ID，观察返回结果。

以订单查询接口为例，正常请求是GET /api/order/detail?orderId=10001。把orderId改成10002后如果还能正常返回订单详情，那就是典型的平行越权。同样思路还可以用在个人信息、发票下载、附件预览、消息通知等场景。

测试写型越权时要非常克制。我一般只验证到“能修改一个非敏感字段且未造成破坏”这一步就停止，比如修改头像URL，再改回来。绝不碰他人密码、余额、订单状态这类高影响对象。越权的定级通常看能力：读取型越权是中危，写入型越权是高危，如果能直接修改管理员配置或重置管理员密码，那就是严重级别。

3.2 业务逻辑：密码、支付与验证码的战场

业务逻辑漏洞的乐趣在于“参数对了但流程错了”。密码找回流程里，我遇到过验证码不绑定手机号：输入自己的验证码，却在提交时替换目标手机号字段，后端没有校验一致性，于是拿到了目标账户的重置凭证。这类问题修复起来很简单，就是加一次校验，但影响是账号接管。

支付逻辑更是经典战场。前端禁掉修改按钮不代表后端信任价格，有些系统会从请求体里直接读price、quantity、discount这些字段。测试时可以用小数、负数、0值去试探，但千万别真的下单支付造成损失。更稳妥的做法是找到测试环境或使用平台提供的测试金额配置。

另一个高频点验证码是短信轰炸和校验次数。发送验证码接口如果不做频率限制，攻击者可以批量骚扰其他用户；登录验证码如果不在服务端绑定会话，那就可以尝试“先拿自己的验证码，再替换受害者的手机号”。这类问题技术门槛不高，但危害清晰，SRC平台一般会认真接纳。

3.3 文件上传与解析漏洞的实际边界

文件上传功能一旦拿下，往往直接通向远程代码执行，这是SRC定级里最快进入严重区间的路径之一。测试时优先看三个点：

• 后缀校验是否基于黑名单，黑名单可以绕过；
• 文件内容头是否和真实类型一致；
• 上传后文件的存储路径和URL是否可控。

比如只检查.jpg后缀，用图片马加shell.php.jpg之类的组合来试探，要看目标服务器的解析配置。如果服务端对上传内容做了重命名，那原文件名这一层就没戏了，但路径遍历和覆盖上传仍值得一试。需要特别提醒的是，有些SRC平台明确规定禁止在真实环境中上传可执行文件，这种情况我一般测试到“确认上传接口未做类型限制”就停下，在报告里说明风险即可，不需要真的把一个Webshell落到服务器上。

3.4 存储型XSS：从输入点到触达面

存储型XSS的价值取决于“谁能看到”。测试输入点是昵称、评论、反馈、个人简介这类能持久化的位置。我提交存储型XSS时会额外说明触达范围，比如“普通用户发表内容，管理员在审核页触发脚本，可能造成会话窃取”，这比单纯提交“弹窗”要有说服力得多。

测试时我只使用<script>alert(document.domain)</script>这类无害载荷，或者构造一个不可见的图片地址来证明请求可被第三方接收，不会植入恶意跳转或窃取cookie的真实攻击脚本。验证到“输入被原样输出且可执行”就完成了，剩下的交给评审去评估影响。

4. 绕过与对抗：当常规测试被拦截之后

新手最容易在“被测系统和WAF的对抗”上卡壳。常规探测被拦下，不代表漏洞不存在，更不代表测试思路已经到头。冷静下来，你会发现在授权测试中，绕过无非是寻找规则盲区和解析差异。

4.1 403与访问控制的绕过试探

目录扫描或接口探测返回403，说明后端可能存在一个受保护的路径，而不是单纯“不存在”。授权范围内，我用这些低风险方式确认访问控制是否严密：

• 路径大小写混淆：/Admin、/admin/.、/admin%2f；
• 尝试添加代理头字段，观察是否被某些反向代理系统直接放行；
• 用X-Original-URL或X-Rewrite-URL指定真实路径，如果前端网关解析了这些头，就可能命中背后的受保护接口。

这部分的本质是判断“安全设备看到的URL”和“后端实际处理的URL”是否有差异。如果两者不一致，你会发现有些代理设备以为你在访问公开页面，但后面已经切到了管理路由。

4.2 参数污染与请求解析差异

参数污染是我最常用的绕过方式之一。同一个参数在请求中提交两次，有的后端框架取第一个值，有的取第二个值；有的网关校验第一个值，业务系统用第二个值。这种不一致就可能绕过参数校验。

另一个常见差异是Content-Type。同一接口用JSON格式提交和用application/x-www-form-urlencoded提交，后端可能走两套解析逻辑。一套设备只对JSON解包里的参数做规则匹配，另一套设备只关心表单字段。测试时我很少盲目改动请求方式，而是先抓一份正常请求，再逐项修改字段格式，观察响应差异。

4.3 低并发、变特征与风控观察

SRC项目通常有风控系统，目录扫描或接口测试频率过高会直接封IP或封会话。我的经验是控制并发不超过5，两个请求之间随机间隔2到5秒，字典优先用精简后的定制版本。这样既能降低对目标业务的影响，也能延长自己的测试窗口。

当响应开始出现一连串403或429时，说明风控已经开始干预。这时继续蛮力测试意义不大，不如暂停一段时间，换个网络出口或者换个测试思路。最不推荐的做法是伪造UA和来源来反向试探风控，一旦被判定为恶意行为，对账号信誉影响很糟糕。在授权范围内做合规测试，克制本身就是一种专业。

5. 报告提交：从确认漏洞到拿到积分

测试做得再漂亮，报告写得不清不楚，评审一样可能打回。SRC报告的第一目标不是炫耀技术，而是让一个没碰过这系统的评审人员按照你的步骤，五分钟内能复现出问题。

5.1 高通过率报告的内容清单

我提交报告前会按照下面的清单逐项检查：

1. 标题包含功能点、漏洞类型和影响位置，例如“订单查询接口越权导致任意用户订单数据泄漏”；
2. 前置条件写清楚，比如“需要两个普通用户账号”；
3. 复现步骤用小步骤编号，每一步附上对应的HTTP请求和响应；
4. 截图或录屏中必须包含请求包、响应包、浏览器地址栏，最好带上当时的时间；
5. 影响说明写成“攻击者可以做什么”，而不是“存在越权”。

修复建议我通常给两个方向：一个是立即修复的空校验点，另一个是更长期的架构级建议，比如统一鉴权中间件。这样评审会觉得你不是在刷积分，而是在认真帮业务做安全建设。

5.2 重复漏洞、误报与被驳回的处理

几乎每个人都会被“重复”二字体面打击过。提交之前先搜索目标平台的历史漏洞更新和公告，很多SRC平台会定期公开已确认漏洞，关键词匹配一下能避开大部分重复。同一个根因换不同入口提交，大概率还是会被判重复，除非影响的业务链路有本质差别。

被驳回不用急着申诉，先在本地复现一遍，确认是不是环境变化导致步骤失效。如果的确是之前测试环境可用、线上不可用，那也要撤下或改写成“测试环境可复现”的限定报告。误报硬撑只会消耗评审的信任。

5.3 与评审沟通的边界感

我见过有人在漏洞提交页面附上威胁性的留言，比如“不给高分就公开”，这个行为几乎等于自毁账号。SRC平台欢迎的是发现漏洞的白帽，不是以此要挟的“猎人”。与评审沟通时，只提供能帮助复现的技术信息，不讨论奖励金额，不公开漏洞细节，更不要擅自向第三方披露厂商信息。

正确的沟通方式是“针对无法复现的步骤给出补充截图”或“针对定级提出事实依据”，语气保持专业和平和。多数平台的运营人员都愿意和讲逻辑的技术人打交道，我的经验是越配合的测试者，后续获得内测邀请的概率越高。

6. 持续投入：把每一次驳回和低危变成二次资产

6.1 建立自己的漏洞笔记仓库

我维护一个简单的Markdown表格，每次漏洞测试结束后，不管最终有没有提交成功，都会记录字段：

这个仓库的价值在三个月后才会显现。回看时会发现同一入口模式在不同的目标上重复出现，有的入口上次没测透，这次可以换一种方式继续。漏洞笔记不是日记，而是你的个人漏洞特征库，越沉淀越值钱。

6.2 关注业务更新与新旧功能差异

新功能和版本更新是SRC最甜的时间窗口。业务方为了赶上线，往往会跳过部分安全测试，新接口不统一、参数不校验的情况也比老代码多。我会定时关注目标SRC平台的公告和外网包，凡是出现“上线新模块”“接入第三方服务”“全面改版”这样的信号，就优先把新功能完整测一遍。

有一回我只是顺着厂商公告里的“消息中心升级”找到了一个新的已读接口，发现消息ID可以遍历读取私信内容。这类“新版功能+老逻辑”的组合在SRC领域里尤其常见。

6.3 授权红线：什么测试坚决不做

最后必须强调界限。SRC测试只允许在平台规定的授权范围内进行，不在范围内的域名、IP、第三方服务再脆弱也不能碰。测试过程中不做破坏性操作，不真正批量下载或导出真实用户数据，不做接近暴力破解的高频尝试，不利用已发现漏洞进一步扩大或迁移控制权限。

我在笔记首页用加粗字写着“证明危害，不造成危害”，每次开工前都会先默读一遍。守住这条底线，你才能在这个领域长期稳定地做下去。工具和技巧都会过时，但边界感永远不会。

我现在拿到一个新授权的SRC项目，第一反应不是立刻掏扫描器，而是先把对方的业务功能当成一条故事线读一遍：谁注册，谁登录，谁下单，谁导出数据，谁在后台审核。这个习惯帮我躲开了好多次无效扫描，也让报告里写的每一个风险都有了真实的业务落脚点。翻看自己的漏洞笔记时，我经常想起第一次被驳回的那份报告，它比任何教程都更清晰地教会了我什么叫影响面。希望这份笔记，也能让你少走一段弯路。