项目跑到0.2.11提测单递到我手上时功能测试已经标记通过。但按照惯例版本上线前的一轮安全测试里我第一个盯上的不是接口鉴权也不是密码策略而是“页面填充”——把各种正常之外的、带着恶意的、踩边界的输入依次填进页面的每一个交互点看它怎么回应。这篇文章就是0.2.11页面填充专项的完整复盘。0.2.11是我们车联网数据服务平台的一个迭代版本这轮改动集中在车辆轨迹回放、告警规则配置、批量导出这类信息密集的页面上。页面填充测试要回答一个很朴素的问题当页面上任何一个输入点被填入异常数据系统还能不能保持清醒。内容主要覆盖测试范围怎么划定、载荷怎么组织、几种典型漏洞从发现到修复的完整链路以及最后沉淀的复用清单。适合安全测试工程师、QA、全栈开发以及所有需要在版本上线前给自己留一道安全关的团队参考。1. 为什么0.2.11要单独做一轮“页面填充”测试1.1 0.2.11版本改了什么改到哪些危险地带0.2.11这个版本从功能列表上看并不算大但改动的几处地方都踩在安全测试的高危区。新增的车辆轨迹回放页面涉及地图组件、时间范围选择、轨迹点列表告警规则配置页面引入了富文本说明、下拉联动、条件组合批量导出功能把查询条件和导出格式绑定在一起。这些页面有一个共同特点它们不是静态展示页而是“输入—查询—渲染—导出”的完整链条。前端要接收用户的输入后端要解析参数数据库要执行查询页面要根据结果渲染DOM。链条上的每一环都可能成为异常数据“住”下来的地方。我拿到提测单后先做了个判断这版虽然没有改动登录和权限模块但新增了几个接口字段还升级了前端的公共渲染组件。哪怕只有一个页面从字符串拼接改成了模板渲染填充测试的结论都可能完全不同。所以这轮单独做不并入例行全量回归是有必要的。版本迭代越多这种“小改动引出大问题”的概率就越高。1.2 “页面填充”在安全测试里到底指什么很多刚接触安全测试的同事会把“页面填充”理解成“往表单里填数据”。这个理解没错但范围太窄了。真正的页面填充是把正常输入之外的所有数据形态系统地填入页面的每个交互点然后观察页面在“不该被接受”的输入面前是优雅拒绝还是原形毕露。填充的对象不只是输入框。URL参数、隐藏字段、下拉框、单选框、上传文件、请求头、Cookie、localStorage甚至页面上可点击的元素都可能成为填充点。填充的数据也不只是脚本标签和SQL语句还包括超长字符串、空值、特殊编码、畸形JSON、Unicode、换行符。用一个朴素的类比页面填充测试就像给一台设备投喂各种“原材料”正常的、带杂质、超标的、形态怪异的都喂一遍看它在什么输入下会卡住、报错、吐出内部信息或者把不该展示的东西展示出来。这个动作听起来简单但恰恰是很多安全缺陷的第一道防线。1.3 功能测试覆盖不到的那类问题功能测试之所以覆盖不到是因为它填的都是“应该被接受”的数据。比如搜索框填“北京”列表页能正确过滤表单填一个合法的手机号能正常提交。这些用例验证的是业务逻辑是否符合预期输入集合是有限的、良性的。页面填充测试正好反过来填的都是“不应该被接受”的数据验证的是系统在异常输入下是否还能守住边界。功能测试通过只能说明业务逻辑正常不能说明系统安全。一个非常典型的例子搜索框填正常关键字时接口响应完全正常填一个单引号接口直接返回500响应体里还带着SQL查询片段。功能测试不会填单引号这个问题只有页面填充能发现。两类测试关注点也完全不同。功能测试关心“功能是否可用”页面填充关心“数据是否可控”“信息是否泄露”“权限是否越界”。所以它们没法互相替代只能组合使用。这也是为什么在0.2.11这类版本迭代里我坚持把页面填充独立成专项来做。2. 填充前的准备把0.2.11的页面交互点摸了个底2.1 从提测单到交互点清单开始测试之前我花了小半天时间做了一件看起来不太“黑客”的事盘点。我把0.2.11的提测单、接口文档、前端代码变更记录放在一起逐个页面过了一遍列出一张《页面交互点清单》。清单里每一项记录几类信息模块、页面、输入点位置、输入点类型、请求方式、输出位置。这样做的目的是保证填充动作是“系统性的”不是想到哪填到哪。我用的工具组合很常规浏览器开发者工具配合抓包代理把所有页面加载产生的请求梳理一遍再手动点击每个可交互元素看它会发起什么请求、带什么参数。0.2.11的页面数量不算多但这个盘点花的时间比后面实际填充还长因为盘点结果直接决定了测试覆盖的完整性。模块页面输入点位置输入点类型请求接口输出位置轨迹回放列表页搜索框、时间范围文本框/api/v1/track/query列表行、地图弹窗告警规则配置页规则名称、富文本说明文本框、富文本/api/v1/alert/rule规则详情、列表摘要批量导出导出页导出条件、文件格式下拉框、单选框/api/v1/export/submit下载任务列表表格只是一个索引真正的价值在于让我明确哪些输入点是新加的哪些是老的哪些输出点会把用户可控的数据回显到页面上。2.2 输出点比输入点更值得标记刚开始做安全测试时我习惯只盯输入点后来吃了亏才明白输出点同样要标记。很多XSS漏洞的根因不在输入侧——数据不是被过滤掉的而是被原样存储、原样输出最终在另一个页面以HTML的形式渲染出来。如果只盯着输入点永远发现不了这类问题。所以在盘点时我会把每个输入点的数据“流向”也标出来这个参数进了哪个接口接口返回后渲染在哪个位置渲染方式是文本插值还是HTML插值。0.2.11的轨迹回放页面里车辆名称、告警内容这些字段都是从服务端返回后直接插入页面模板的这种位置就是重点观察对象。标记输出点还有一个作用帮助判断“回显型”问题。比如填充一个特殊字符串后如果响应报文里原样出现了这个字符串说明数据在前端和后端之间是否做了转义处理需要逐段排查。2.3 工具组合工具选型我坚持一个原则不追新但要看清楚请求与响应。这次用的是抓包代理工具加浏览器开发者工具另外写了一个简单的脚本用来批量生成填充数据和对响应做初步断言。抓包代理解决的是“能不能改请求、看响应”的问题。浏览器开发者工具解决的是“页面上到底发生了什么”的问题。两者配合可以快速判断一个问题发生在请求阶段、响应阶段还是渲染阶段。批量脚本则是我为了减少重复劳动加的用Python写了一个小工具读取填充字典逐条替换请求参数把响应状态码、响应体关键字记录下来。这套组合没有太多新奇之处但它足够可靠。页面填充测试的核心是观察力工具只是帮我把请求和响应摆到桌面上的手段。越早看清数据流的全貌越容易在后面的填充过程中定位问题。3. 实测从普通填充到恶意载荷我按这个顺序扫了一遍3.1 第一遍边界填充边界填充是所有填充动作里性价比最高的一步也是我最先做的一步。它的思路很简单把各种“卡边界”的数据填入输入点看页面和接口的反应。常见的边界数据包括超长字符串、空字符串、null、Unicode字符、全角符号、emoji、换行符、特殊控制字符。举几个实际填过的例子。在车辆名称输入框填入一个5000字符的字符串观察接口是否正常返回、数据库是否截断、页面是否卡死在时间范围选择器填入空值观察后端是否做了必填校验在搜索框填入百分号%观察数据库查询是否把它当成了通配符导致返回全量数据。边界填充主要为了发现三类问题一是崩溃型系统直接抛异常、白屏、进程挂掉二是截断型数据被静默截断可能引发字段错位三是回显型特殊字符原样出现在响应报文里这通常是后续注入类漏洞的信号。实测过程中光是百分号和单引号就帮我发现了一个搜索接口的异常这个在第四章会展开讲。3.2 第二遍结构填充结构填充是把自己的数据伪装成“有结构”的内容看系统怎么解析。这一步覆盖的是URL编码、双重编码、JSON结构异常、HTML标签、SQL片段、文件路径等。在0.2.11里我重点填了几类结构。第一类是编码变体把同一个字符用%27、%2527、unicode编码分别填进去观察后端是否做了解码以及解码后是否还有过滤。第二类是JSON结构异常在接口参数里塞入嵌套的畸形结构比如把数组写成字符串或者在一个对象里重复同一个键。第三类是HTML与SQL结构往富文本、搜索框里填入带有标签或SQL关键字的字符串观察是原样输出、被转义还是被当作结构解析。结构填充的意义在于它能提前暴露“过滤规则只看表面”的问题。很多输入校验只拦了明文的关键字但系统内部如果存在二次解码、二次拼接明文被编码后就绕过了校验。这轮测试里富文本编辑器的问题就是结构填充阶段暴露出来的标签没有被清洗而是被原样存进了数据库。3.3 第三遍恶意载荷填充前两遍填充过后基本能确认哪些输入点“没有防护”。第三遍就是在这些点上投入真正的恶意载荷验证危害程度。这里只说测试验证目的是让开发团队知道问题有多严重、修复优先级有多高。恶意载荷我分成三类。第一类是脚本注入典型的是scriptalert(1)/script以及不需要script标签的事件型写法比如img srcx onerroralert(1)。第二类是SQL注入在搜索、排序、筛选这类会拼进查询语句的参数里填入 OR 11、 AND SLEEP(5)--这类验证串观察响应时间、结果集、报错信息的变化。第三类是路径与命令注入在导出文件名、下载路径这类参数里填入../、分号、管道符观察是否能跳出预期目录或触发额外命令。观察点也很明确响应的状态码、响应时间、响应体内容、页面DOM结构是否发生变化。只要填充的载荷能引起异常响应就说明这个输入点需要加固。实际测试中我会从最小验证集开始先看页面反应再决定要不要深入。安全测试的价值是发现问题不是演示破坏。3.4 AI辅助把填充字典做得更厚这次测试我尝试了一个新做法用AI辅助生成填充载荷的变体。传统的填充字典是人工维护的覆盖面受个人经验限制容易漏掉某些编码形式。我把常见的边界值、编码方式、标签形态、SQL片段喂给AI让它按“绕过输入过滤”的方向生成一批变体再人工筛选合并进填充字典。实测下来AI生成的变体确实补上了几个手工容易漏掉的点比如不同浏览器对HTML实体编码的解析差异、嵌套编码绕过等。但我也没完全依赖它因为AI生成的载荷需要人工理解它的意图否则填进去看到异常响应也无法判断是系统问题还是载荷本身不合法。AI在页面填充里扮演的是“扩字典”和“整理响应”的助手真正做判断的还是人。4. 0.2.11这次踩到的三个典型问题从发现到修复验证4.1 富文本二次渲染藏得最深的存储型XSS这次测试最有价值的一个发现发生在告警规则配置页的富文本编辑器里。排查链路是这样的。在富文本说明里填入一段带img srcx onerroralert(1)的内容发布规则后列表页显示正常标题、摘要都没有异常。但当我进入规则详情页时浏览器控制台出现了异常报错页面局部的弹窗加载出问题。第一反应是详情页可能对富文本做了HTML渲染。我回头抓包看了详情页的接口响应发现响应体里那段img标签原样存在没有任何转义或过滤痕迹。再查列表页为什么正常是因为列表页只截取了纯文本摘要。继续追踪到前端代码详情页用的是v-html指令直接插入富文本内容等于把数据库里的HTML原样交给了浏览器解析。到这里根因清楚了输入侧没有做白名单过滤富文本内容带着HTML标签入库输出侧又用了最危险的渲染方式直接把服务端返回的内容当HTML执行。这是典型的存储型XSS闭环。修复方案分了两步。输出侧强制走富文本清洗库把事件属性、危险标签剥离后再渲染输入侧增加长度上限和标签白名单双端加固。复测时我在富文本里填了同样的载荷页面展示出来的是被转义的文本内容不再触发执行。这类问题难在排查链路长跨越编辑器、后端存储、前端渲染三个环节如果只看某一层很容易漏掉。4.2 搜索接口的报错信息回显一个被忽视的信息泄露口子第二个问题是在轨迹查询页的搜索框里发现的。边界填充阶段我在搜索框填入一个单引号页面没有正常加载数据而是弹出一个500错误。抓包看响应体里面赫然带着一段SQL查询片段包含表名和查询条件的痕迹。定位过程不算复杂。先确认是搜索接口返回的然后看服务端日志日志里打印了完整的异常堆栈。继续查接口代码发现搜索方法的异常处理直接把e.getMessage()拼进了响应体返回值在框架层被当作业务数据返回给前端。也就是说数据库在解析单引号时抛出语法异常异常信息原件被原样送回了页面。这个问题的危害不是能直接拖库而是信息泄露数据库类型、表名、字段名这些线索本来不应该让前端看到现在全暴露了。攻击者拿到这些线索后面构造注入就会容易很多。修复方案是统一异常处理对外返回模糊的“查询失败请稍后重试”详细堆栈只写日志。同时把搜索查询改成参数化查询避免拼接SQL。复测时再填入同样的单引号页面返回的是通用错误提示响应体里不再出现任何SQL痕迹。这类问题提醒我信息泄露往往不是一个大洞而是一堆小口子。搜索结果报错信息、上传失败路径、配置解析错误细节都是经常漏的地方。4.3 超长ID的隐式截断越权数据从哪冒出来的第三个问题藏在批量导出接口里发现过程比较偶然。边界填充阶段我把导出任务中的ID参数填入一段超过500位的超长数字接口没有报错反而返回了一个比正常情况大得多的任务列表里面有其他用户创建的导出记录。我沿着这个异常往回查。先看接口接收参数的方式发现ID参数的类型是字符串后端在处理时没有做长度校验而是用了一个substring方法取了前若干位。问题的关键来了当两个ID的前若干位完全相同时超长ID就会被隐式截断后映射到同一个真实ID上导致归属校验在一个错误的ID上判断越权数据就这样被带了出来。这个问题的根因不是过滤而是“截断后没校验”。系统对参数长度没有约束校验逻辑只检查了截断后的ID归属没有检查原始参数和截断结果是否一致。修复方案做了三层加固第一ID参数用数组格式传输不做字符串截断第二每个ID必须通过归属校验校验不通过直接拒绝第三对参数长度设置硬上限。复测时再填入超长ID接口返回校验失败越权数据不再出现。这个案例给我最大的启发是越权问题不一定都藏在权限逻辑里数据流中间的隐式处理也可能制造漏洞。填充测试的价值就是在这些处理逻辑上反复试探。5. 把0.2.11的页面填充过程沉淀成一套可复用清单5.1 页面填充测试的Checklist0.2.11这轮测试结束后我把过程整理成一份清单方便后续版本直接套用。清单分几个阶段盘点阶段确认版本改动范围梳理页面交互点标记输入输出位置边界填充填入超长、空值、特殊字符、编码字符观察响应与页面表现结构填充填入异常JSON、HTML标签、SQL片段、文件路径观察解析与渲染结果恶意载荷填充在无防护点投入脚本、SQL、命令、路径穿越载荷验证危害并评估风险等级修复验证对每个问题复测确认同时检查是否在相邻功能或公共组件中存在同类问题。这份清单不会让测试变得机械它的作用是确保每次都在同样的起点开始不至于因为换了测试人员就漏掉某个环节。5.2 哪些代码改动必须触发一轮页面填充团队里经常有人问“什么情况下要做页面填充测试”我总结了几条触发规则基本能覆盖大多数场景。第一新增或修改任何接收用户输入的接口第二前端模板、公共组件、渲染方式发生变化第三引入了富文本、文件上传、批量导入导出这类高复杂度组件第四数据库表结构或查询语句有调整第五前后端框架版本升级。触发规则不是用来增加工作量而是把安全测试的点位放在改动最密集、风险最高发的地方。0.2.11这版如果套用这套规则富文本、搜索、导出三个模块都会被自动圈进来省去很多人工判断。5.3 把填充用例塞进自动化但别指望自动化解决一切这轮测试之后我把一部分常见填充用例做成了自动化冒烟用例接进了持续集成流程。每次构建后自动对关键页面的搜索框、列表参数发起一组基础填充请求检查状态码、响应体关键字和响应时间。自动化的好处是稳定、快速能挡掉大部分低级回归。但它替代不了手工页面填充因为自动化脚本很难判断页面DOM的语义变化也很难覆盖复杂业务链路。比如富文本二次渲染的问题自动化只能发现接口响应里出现了HTML标签但“标签在详情页被当作HTML执行”这件事必须结合浏览器渲染才能确认。所以我的做法是自动化负责门槛手工负责深度AI负责扩展样本。三者配合页面填充测试才能形成一条完整的防线。这次0.2.11的页面填充做下来我最大的感受是大多数安全问题不是安全测试人员用了多高深的技术而是把“这个页面如果被填入意想不到的数据会怎样”这个问题问到底。填充不是目的观察系统在异常输入面前有没有守住边界才是目的。版本越小越容易让人放松但小改动藏大问题的情况我见过太多次了。 
长河君 · 2026/9/16 21:17:54 · 阅读 1.2k 0.2.11页面填充专项复盘：从边界填充到恶意载荷的安全测试实践
项目跑到0.2.11提测单递到我手上时功能测试已经标记通过。但按照惯例版本上线前的一轮安全测试里我第一个盯上的不是接口鉴权也不是密码策略而是“页面填充”——把各种正常之外的、带着恶意的、踩边界的输入依次填进页面的每一个交互点看它怎么回应。这篇文章就是0.2.11页面填充专项的完整复盘。0.2.11是我们车联网数据服务平台的一个迭代版本这轮改动集中在车辆轨迹回放、告警规则配置、批量导出这类信息密集的页面上。页面填充测试要回答一个很朴素的问题当页面上任何一个输入点被填入异常数据系统还能不能保持清醒。内容主要覆盖测试范围怎么划定、载荷怎么组织、几种典型漏洞从发现到修复的完整链路以及最后沉淀的复用清单。适合安全测试工程师、QA、全栈开发以及所有需要在版本上线前给自己留一道安全关的团队参考。1. 为什么0.2.11要单独做一轮“页面填充”测试1.1 0.2.11版本改了什么改到哪些危险地带0.2.11这个版本从功能列表上看并不算大但改动的几处地方都踩在安全测试的高危区。新增的车辆轨迹回放页面涉及地图组件、时间范围选择、轨迹点列表告警规则配置页面引入了富文本说明、下拉联动、条件组合批量导出功能把查询条件和导出格式绑定在一起。这些页面有一个共同特点它们不是静态展示页而是“输入—查询—渲染—导出”的完整链条。前端要接收用户的输入后端要解析参数数据库要执行查询页面要根据结果渲染DOM。链条上的每一环都可能成为异常数据“住”下来的地方。我拿到提测单后先做了个判断这版虽然没有改动登录和权限模块但新增了几个接口字段还升级了前端的公共渲染组件。哪怕只有一个页面从字符串拼接改成了模板渲染填充测试的结论都可能完全不同。所以这轮单独做不并入例行全量回归是有必要的。版本迭代越多这种“小改动引出大问题”的概率就越高。1.2 “页面填充”在安全测试里到底指什么很多刚接触安全测试的同事会把“页面填充”理解成“往表单里填数据”。这个理解没错但范围太窄了。真正的页面填充是把正常输入之外的所有数据形态系统地填入页面的每个交互点然后观察页面在“不该被接受”的输入面前是优雅拒绝还是原形毕露。填充的对象不只是输入框。URL参数、隐藏字段、下拉框、单选框、上传文件、请求头、Cookie、localStorage甚至页面上可点击的元素都可能成为填充点。填充的数据也不只是脚本标签和SQL语句还包括超长字符串、空值、特殊编码、畸形JSON、Unicode、换行符。用一个朴素的类比页面填充测试就像给一台设备投喂各种“原材料”正常的、带杂质、超标的、形态怪异的都喂一遍看它在什么输入下会卡住、报错、吐出内部信息或者把不该展示的东西展示出来。这个动作听起来简单但恰恰是很多安全缺陷的第一道防线。1.3 功能测试覆盖不到的那类问题功能测试之所以覆盖不到是因为它填的都是“应该被接受”的数据。比如搜索框填“北京”列表页能正确过滤表单填一个合法的手机号能正常提交。这些用例验证的是业务逻辑是否符合预期输入集合是有限的、良性的。页面填充测试正好反过来填的都是“不应该被接受”的数据验证的是系统在异常输入下是否还能守住边界。功能测试通过只能说明业务逻辑正常不能说明系统安全。一个非常典型的例子搜索框填正常关键字时接口响应完全正常填一个单引号接口直接返回500响应体里还带着SQL查询片段。功能测试不会填单引号这个问题只有页面填充能发现。两类测试关注点也完全不同。功能测试关心“功能是否可用”页面填充关心“数据是否可控”“信息是否泄露”“权限是否越界”。所以它们没法互相替代只能组合使用。这也是为什么在0.2.11这类版本迭代里我坚持把页面填充独立成专项来做。2. 填充前的准备把0.2.11的页面交互点摸了个底2.1 从提测单到交互点清单开始测试之前我花了小半天时间做了一件看起来不太“黑客”的事盘点。我把0.2.11的提测单、接口文档、前端代码变更记录放在一起逐个页面过了一遍列出一张《页面交互点清单》。清单里每一项记录几类信息模块、页面、输入点位置、输入点类型、请求方式、输出位置。这样做的目的是保证填充动作是“系统性的”不是想到哪填到哪。我用的工具组合很常规浏览器开发者工具配合抓包代理把所有页面加载产生的请求梳理一遍再手动点击每个可交互元素看它会发起什么请求、带什么参数。0.2.11的页面数量不算多但这个盘点花的时间比后面实际填充还长因为盘点结果直接决定了测试覆盖的完整性。模块页面输入点位置输入点类型请求接口输出位置轨迹回放列表页搜索框、时间范围文本框/api/v1/track/query列表行、地图弹窗告警规则配置页规则名称、富文本说明文本框、富文本/api/v1/alert/rule规则详情、列表摘要批量导出导出页导出条件、文件格式下拉框、单选框/api/v1/export/submit下载任务列表表格只是一个索引真正的价值在于让我明确哪些输入点是新加的哪些是老的哪些输出点会把用户可控的数据回显到页面上。2.2 输出点比输入点更值得标记刚开始做安全测试时我习惯只盯输入点后来吃了亏才明白输出点同样要标记。很多XSS漏洞的根因不在输入侧——数据不是被过滤掉的而是被原样存储、原样输出最终在另一个页面以HTML的形式渲染出来。如果只盯着输入点永远发现不了这类问题。所以在盘点时我会把每个输入点的数据“流向”也标出来这个参数进了哪个接口接口返回后渲染在哪个位置渲染方式是文本插值还是HTML插值。0.2.11的轨迹回放页面里车辆名称、告警内容这些字段都是从服务端返回后直接插入页面模板的这种位置就是重点观察对象。标记输出点还有一个作用帮助判断“回显型”问题。比如填充一个特殊字符串后如果响应报文里原样出现了这个字符串说明数据在前端和后端之间是否做了转义处理需要逐段排查。2.3 工具组合工具选型我坚持一个原则不追新但要看清楚请求与响应。这次用的是抓包代理工具加浏览器开发者工具另外写了一个简单的脚本用来批量生成填充数据和对响应做初步断言。抓包代理解决的是“能不能改请求、看响应”的问题。浏览器开发者工具解决的是“页面上到底发生了什么”的问题。两者配合可以快速判断一个问题发生在请求阶段、响应阶段还是渲染阶段。批量脚本则是我为了减少重复劳动加的用Python写了一个小工具读取填充字典逐条替换请求参数把响应状态码、响应体关键字记录下来。这套组合没有太多新奇之处但它足够可靠。页面填充测试的核心是观察力工具只是帮我把请求和响应摆到桌面上的手段。越早看清数据流的全貌越容易在后面的填充过程中定位问题。3. 实测从普通填充到恶意载荷我按这个顺序扫了一遍3.1 第一遍边界填充边界填充是所有填充动作里性价比最高的一步也是我最先做的一步。它的思路很简单把各种“卡边界”的数据填入输入点看页面和接口的反应。常见的边界数据包括超长字符串、空字符串、null、Unicode字符、全角符号、emoji、换行符、特殊控制字符。举几个实际填过的例子。在车辆名称输入框填入一个5000字符的字符串观察接口是否正常返回、数据库是否截断、页面是否卡死在时间范围选择器填入空值观察后端是否做了必填校验在搜索框填入百分号%观察数据库查询是否把它当成了通配符导致返回全量数据。边界填充主要为了发现三类问题一是崩溃型系统直接抛异常、白屏、进程挂掉二是截断型数据被静默截断可能引发字段错位三是回显型特殊字符原样出现在响应报文里这通常是后续注入类漏洞的信号。实测过程中光是百分号和单引号就帮我发现了一个搜索接口的异常这个在第四章会展开讲。3.2 第二遍结构填充结构填充是把自己的数据伪装成“有结构”的内容看系统怎么解析。这一步覆盖的是URL编码、双重编码、JSON结构异常、HTML标签、SQL片段、文件路径等。在0.2.11里我重点填了几类结构。第一类是编码变体把同一个字符用%27、%2527、unicode编码分别填进去观察后端是否做了解码以及解码后是否还有过滤。第二类是JSON结构异常在接口参数里塞入嵌套的畸形结构比如把数组写成字符串或者在一个对象里重复同一个键。第三类是HTML与SQL结构往富文本、搜索框里填入带有标签或SQL关键字的字符串观察是原样输出、被转义还是被当作结构解析。结构填充的意义在于它能提前暴露“过滤规则只看表面”的问题。很多输入校验只拦了明文的关键字但系统内部如果存在二次解码、二次拼接明文被编码后就绕过了校验。这轮测试里富文本编辑器的问题就是结构填充阶段暴露出来的标签没有被清洗而是被原样存进了数据库。3.3 第三遍恶意载荷填充前两遍填充过后基本能确认哪些输入点“没有防护”。第三遍就是在这些点上投入真正的恶意载荷验证危害程度。这里只说测试验证目的是让开发团队知道问题有多严重、修复优先级有多高。恶意载荷我分成三类。第一类是脚本注入典型的是scriptalert(1)/script以及不需要script标签的事件型写法比如img srcx onerroralert(1)。第二类是SQL注入在搜索、排序、筛选这类会拼进查询语句的参数里填入 OR 11、 AND SLEEP(5)--这类验证串观察响应时间、结果集、报错信息的变化。第三类是路径与命令注入在导出文件名、下载路径这类参数里填入../、分号、管道符观察是否能跳出预期目录或触发额外命令。观察点也很明确响应的状态码、响应时间、响应体内容、页面DOM结构是否发生变化。只要填充的载荷能引起异常响应就说明这个输入点需要加固。实际测试中我会从最小验证集开始先看页面反应再决定要不要深入。安全测试的价值是发现问题不是演示破坏。3.4 AI辅助把填充字典做得更厚这次测试我尝试了一个新做法用AI辅助生成填充载荷的变体。传统的填充字典是人工维护的覆盖面受个人经验限制容易漏掉某些编码形式。我把常见的边界值、编码方式、标签形态、SQL片段喂给AI让它按“绕过输入过滤”的方向生成一批变体再人工筛选合并进填充字典。实测下来AI生成的变体确实补上了几个手工容易漏掉的点比如不同浏览器对HTML实体编码的解析差异、嵌套编码绕过等。但我也没完全依赖它因为AI生成的载荷需要人工理解它的意图否则填进去看到异常响应也无法判断是系统问题还是载荷本身不合法。AI在页面填充里扮演的是“扩字典”和“整理响应”的助手真正做判断的还是人。4. 0.2.11这次踩到的三个典型问题从发现到修复验证4.1 富文本二次渲染藏得最深的存储型XSS这次测试最有价值的一个发现发生在告警规则配置页的富文本编辑器里。排查链路是这样的。在富文本说明里填入一段带img srcx onerroralert(1)的内容发布规则后列表页显示正常标题、摘要都没有异常。但当我进入规则详情页时浏览器控制台出现了异常报错页面局部的弹窗加载出问题。第一反应是详情页可能对富文本做了HTML渲染。我回头抓包看了详情页的接口响应发现响应体里那段img标签原样存在没有任何转义或过滤痕迹。再查列表页为什么正常是因为列表页只截取了纯文本摘要。继续追踪到前端代码详情页用的是v-html指令直接插入富文本内容等于把数据库里的HTML原样交给了浏览器解析。到这里根因清楚了输入侧没有做白名单过滤富文本内容带着HTML标签入库输出侧又用了最危险的渲染方式直接把服务端返回的内容当HTML执行。这是典型的存储型XSS闭环。修复方案分了两步。输出侧强制走富文本清洗库把事件属性、危险标签剥离后再渲染输入侧增加长度上限和标签白名单双端加固。复测时我在富文本里填了同样的载荷页面展示出来的是被转义的文本内容不再触发执行。这类问题难在排查链路长跨越编辑器、后端存储、前端渲染三个环节如果只看某一层很容易漏掉。4.2 搜索接口的报错信息回显一个被忽视的信息泄露口子第二个问题是在轨迹查询页的搜索框里发现的。边界填充阶段我在搜索框填入一个单引号页面没有正常加载数据而是弹出一个500错误。抓包看响应体里面赫然带着一段SQL查询片段包含表名和查询条件的痕迹。定位过程不算复杂。先确认是搜索接口返回的然后看服务端日志日志里打印了完整的异常堆栈。继续查接口代码发现搜索方法的异常处理直接把e.getMessage()拼进了响应体返回值在框架层被当作业务数据返回给前端。也就是说数据库在解析单引号时抛出语法异常异常信息原件被原样送回了页面。这个问题的危害不是能直接拖库而是信息泄露数据库类型、表名、字段名这些线索本来不应该让前端看到现在全暴露了。攻击者拿到这些线索后面构造注入就会容易很多。修复方案是统一异常处理对外返回模糊的“查询失败请稍后重试”详细堆栈只写日志。同时把搜索查询改成参数化查询避免拼接SQL。复测时再填入同样的单引号页面返回的是通用错误提示响应体里不再出现任何SQL痕迹。这类问题提醒我信息泄露往往不是一个大洞而是一堆小口子。搜索结果报错信息、上传失败路径、配置解析错误细节都是经常漏的地方。4.3 超长ID的隐式截断越权数据从哪冒出来的第三个问题藏在批量导出接口里发现过程比较偶然。边界填充阶段我把导出任务中的ID参数填入一段超过500位的超长数字接口没有报错反而返回了一个比正常情况大得多的任务列表里面有其他用户创建的导出记录。我沿着这个异常往回查。先看接口接收参数的方式发现ID参数的类型是字符串后端在处理时没有做长度校验而是用了一个substring方法取了前若干位。问题的关键来了当两个ID的前若干位完全相同时超长ID就会被隐式截断后映射到同一个真实ID上导致归属校验在一个错误的ID上判断越权数据就这样被带了出来。这个问题的根因不是过滤而是“截断后没校验”。系统对参数长度没有约束校验逻辑只检查了截断后的ID归属没有检查原始参数和截断结果是否一致。修复方案做了三层加固第一ID参数用数组格式传输不做字符串截断第二每个ID必须通过归属校验校验不通过直接拒绝第三对参数长度设置硬上限。复测时再填入超长ID接口返回校验失败越权数据不再出现。这个案例给我最大的启发是越权问题不一定都藏在权限逻辑里数据流中间的隐式处理也可能制造漏洞。填充测试的价值就是在这些处理逻辑上反复试探。5. 把0.2.11的页面填充过程沉淀成一套可复用清单5.1 页面填充测试的Checklist0.2.11这轮测试结束后我把过程整理成一份清单方便后续版本直接套用。清单分几个阶段盘点阶段确认版本改动范围梳理页面交互点标记输入输出位置边界填充填入超长、空值、特殊字符、编码字符观察响应与页面表现结构填充填入异常JSON、HTML标签、SQL片段、文件路径观察解析与渲染结果恶意载荷填充在无防护点投入脚本、SQL、命令、路径穿越载荷验证危害并评估风险等级修复验证对每个问题复测确认同时检查是否在相邻功能或公共组件中存在同类问题。这份清单不会让测试变得机械它的作用是确保每次都在同样的起点开始不至于因为换了测试人员就漏掉某个环节。5.2 哪些代码改动必须触发一轮页面填充团队里经常有人问“什么情况下要做页面填充测试”我总结了几条触发规则基本能覆盖大多数场景。第一新增或修改任何接收用户输入的接口第二前端模板、公共组件、渲染方式发生变化第三引入了富文本、文件上传、批量导入导出这类高复杂度组件第四数据库表结构或查询语句有调整第五前后端框架版本升级。触发规则不是用来增加工作量而是把安全测试的点位放在改动最密集、风险最高发的地方。0.2.11这版如果套用这套规则富文本、搜索、导出三个模块都会被自动圈进来省去很多人工判断。5.3 把填充用例塞进自动化但别指望自动化解决一切这轮测试之后我把一部分常见填充用例做成了自动化冒烟用例接进了持续集成流程。每次构建后自动对关键页面的搜索框、列表参数发起一组基础填充请求检查状态码、响应体关键字和响应时间。自动化的好处是稳定、快速能挡掉大部分低级回归。但它替代不了手工页面填充因为自动化脚本很难判断页面DOM的语义变化也很难覆盖复杂业务链路。比如富文本二次渲染的问题自动化只能发现接口响应里出现了HTML标签但“标签在详情页被当作HTML执行”这件事必须结合浏览器渲染才能确认。所以我的做法是自动化负责门槛手工负责深度AI负责扩展样本。三者配合页面填充测试才能形成一条完整的防线。这次0.2.11的页面填充做下来我最大的感受是大多数安全问题不是安全测试人员用了多高深的技术而是把“这个页面如果被填入意想不到的数据会怎样”这个问题问到底。填充不是目的观察系统在异常输入面前有没有守住边界才是目的。版本越小越容易让人放松但小改动藏大问题的情况我见过太多次了。