Web安全测试用例实战：从输入验证到越权与注入的落地检查清单

简介这份安全性测试用例文档面向软件测试工程师、安全测试初学者及需要开展Web系统安全验证的研发团队围绕权限校验、输入验证、访问控制、日志记录与数据加密等核心场景整理出一套可直接参照执行的测试用例集。资源包内共1个PDF文件大小约484KB内容以测试用例表格形式呈现涵盖客户端与服务器端验证、URL非法入侵防范、日志完整性、密码策略、未验证输入、访问控制、输入框验证、关键数据加密及认证请求方式等模块每个用例均给出Summary、Steps与Expected Results便于对照执行并记录Pass/Fail结论。目前已有1674人学习下载适合作为安全测试入门练习、用例编写模板或项目安全自查的参考清单帮助读者快速理解Web安全测试的关注点与验证思路减少遗漏关键安全项的风险。1. 拿到一份安全性测试用例先别急着照单全跑很多团队做 Web 安全测试第一反应是上工具扫一遍结果报告里全是「疑似风险」开发看完一脸茫然改都不知道从哪改。这份《安全性测试用例》走的是另一条路它把安全测试拆成一条条可执行、可判定 Pass/Fail 的用例覆盖客户端与服务器端验证、URL 越权、日志完整性、访问控制、SQL 注入、文件上传、通信保密、数据备份等场景还单独列了服务器侧的操作系统账户、文件分区格式、中间件密码、数据库用户密码与访问限制。它适合谁适合手里有 Web 系统、需要出一份能落地整改的安全测试清单的测试工程师和安全从业者。说白了它不教你「什么是安全」它给你一张「照着做就能出结论」的检查表。下面我按自己拆这类文档的习惯把它怎么用、参数怎么设、坑在哪讲透。2. 客户端与服务器端验证输入边界用例怎么落地2.1 为什么验证要分两层看这份用例里 Test Case001 的核心是「客户端验证服务器端验证」并且特别标注了「禁用脚本调试禁用 Cookies」。这个前提很关键。客户端验证JavaScript 校验只是体验层攻击者抓包改请求就能绕过真正决定系统安全的是服务器端验证。所以测试时必须把浏览器脚本关掉、把 Cookies 清掉模拟一个「不配合」的客户端看服务器还认不认这些非法输入。常见做法是先用正常流程走一遍确认功能通再关脚本重放同样的请求对比两次结果。如果关掉脚本后非法数据照样进库说明服务器端根本没校验这就是高危。2.2 输入边界的具体测试步骤用例里列了 9 类输入我把它整理成可抄的检查表配合下面的脚本批量构造测试数据。# 构造边界与异常输入用于手工或自动化提交 payloads { 超大整数: 4294967269, # 接近 32 位无符号上限 负数: -1, 超长字符串: A * 5000, # 试探长度限制是否在服务端生效 刚好到限制: A * 255, # 常见 varchar 边界 特殊字符: ~!#$%^*()_:\{}|, 首尾空格: admin , 中间空格: ad min, 空值变体: [NULL, null, 0x0d, 0x0a], 类型错配: abc, # 要求数字时传字母 HTML注入: scriptalert(1)/script, JS注入: javascript:alert(1), } for name, val in payloads.items(): print(f[{name}] - {val!r})这段脚本只是把用例里的输入类型具象化方便你逐条往表单或接口里灌。参数说明4294967269用来试探整型溢出A*5000和A*255分别测「远超限制」和「刚好到限制」两种边界很多系统只挡了前者漏了后者0x0d 0x0a是回车换行的十六进制写法用来测日志注入或头部注入。每条输入提交后对照用例的 Expected Results 判断验证码是否报错、超长是否被截断或拒绝、特殊字符是否被转义、HTML/JS 是否在页面被执行。2.3 直接输 URL 与改参数怎么测用例 Test Case001 第 9、10 条和 Test Case002 讲的是同一类问题越权访问。做法是——先以低权限用户登录进到一个有权限的页面把 URL 复制下来退出登录或换一个无权限账号直接粘贴这个 URL 访问。如果还能打开说明只做了「菜单隐藏」没做「服务端鉴权」。带参数的 URL 更典型比如detail?id1001把1001改成1002、改成字母、改成超大数、改成特殊字符看是否报错、是否能读到别人的数据。这里有个血泪经验很多系统对「数字改字母」会报 500但对「数字改另一个数字」毫无反应后者才是真正的越权漏洞前者只是没做异常处理。提示测越权一定要用两个不同权限的真实账号交叉验证单账号自测很容易漏判。3. 访问控制、日志与认证三条容易被忽略的防线3.1 访问控制与会话管理Test Case006 讲访问控制Test Case015 讲 IE 回退按钮Test Case017 讲并发会话限制其实是一条线会话和权限有没有管住。回退按钮那条特别实用——退出系统后点浏览器回退如果能重新回到系统内页说明退出时没真正销毁服务端会话只是前端跳转了。并发会话限制则要求同一账号不能在同一时间多处登录单用户并发会话数要有限制超时要自动锁定。测试方法很直接同一账号在两个浏览器登录看先登录的那个是否被踢下线或提示登录后放置不动看是否在设定时间后自动结束会话。这些参数超时时间、最大并发数通常写在安全策略里测试时要拿实际配置去对而不是凭感觉。3.2 日志记录完整性怎么验Test Case003 和 Test Case013 都指向日志。用例要求日志至少记录操作员、操作时间、系统状态、操作事项、IP 地址。验证方法是做一次「详单查询」这类敏感操作然后去日志里翻这五项是否齐全。常见翻车点日志只记了操作没记操作人或者记了人没记 IP或者时间用的是客户端时间可以被篡改。合格的做法是服务端统一打点时间取服务器时间IP 取真实来源地址。如果系统有多个模块要确认日志是否集中存储、能否按条件检索否则出了事根本查不到。3.3 认证请求方式与密码策略Test Case009 要求认证和会话数据用 POST 而非 GET。原因很直白GET 会把用户名密码拼在 URL 里留在浏览器历史、服务器访问日志、代理记录中。测试时打开开发者工具的 Network 面板看登录请求是 GET 还是 POST参数在 URL 还是请求体里。Test Case004 则是一整套密码策略检查最小长度、能否含空格回车、用户名密码能否一致、能否自动填表批量注册、遗忘密码处理、有无默认超级用户和超级密码、密码错误有无次数限制、密码复杂度是否要求大小写数字特殊字符混合。这些逐条对照系统实际配置打勾即可其中「有无缺省超级用户/超级密码」是最容易出事的一条很多系统交付时忘了删测试账号。# 用 curl 观察登录请求方法确认是否为 POST curl -v -X POST https://example.com/login \ -d usernametestpasswordTest123 \ -H Content-Type: application/x-www-form-urlencoded # 关注输出中的 POST /login 与请求体若为 GET 则参数会出现在 URL 上参数说明-v打印完整请求响应头-X POST指定方法-d携带表单数据。如果换成-G或直接把参数拼在 URL 后就能复现 GET 提交的场景用来对比两种方式下敏感信息是否暴露。4. 注入、上传与通信高危项的排查手法4.1 SQL 注入与输入验证Test Case010 是 SQL 注入Test Case005 是「没有被验证的输入」两者是因果关系。用例要求检查数据类型、字符集、长度、是否允许空、参数是否必填、是否允许重复、数值范围、枚举值、正则模式。这些如果服务端没控住注入就有了入口。手工验证 SQL 注入最稳的是在参数里塞单引号看是否报数据库错误再塞 OR 11看是否绕过逻辑。但要注意报错不等于可利用不报错也不等于安全盲注可能没有任何回显。常见做法是结合参数化查询的代码审查一起判断而不是只靠黑盒。-- 在测试环境的查询参数中尝试观察返回是否异常 OR 11 ; WAITFOR DELAY 0:0:5-- 1 AND (SELECT COUNT(*) FROM users) 0--逻辑说明第一条测逻辑绕过第二条测时间盲注响应是否延迟 5 秒第三条测布尔盲注。这些必须在授权测试环境里做生产环境严禁尝试。参数上WAITFOR DELAY是 SQL Server 语法MySQL 对应SLEEP(5)用之前先确认数据库类型。4.2 文件上传与功能异常风险Test Case011 文件上传、Test Case012 功能失效带来的安全风险用例里 Expected Results 写的是「无效」意思是这两项需要你根据系统实际情况补充判定标准。文件上传的检查点是否校验扩展名、是否校验 MIME 类型、是否校验文件内容头、上传目录是否可执行脚本、文件名是否可被覆盖或路径穿越。功能异常则关注异常报错是否暴露堆栈和路径、失败后是否留下临时文件、并发操作是否导致状态错乱。这两项没有标准答案靠的是测试人员对系统的理解去设计用例。4.3 通信保密性与数据备份Test Case016 通信保密性要求验证三件事一方长时间无响应时另一方能否自动结束会话、建立会话前是否用密码技术做初始化验证、通信过程是否对整个报文或会话加密。测试时抓包看数据是否明文看超时后会话是否真的断开。Test Case018 数据备份和恢复要求重要信息本地和异地自动备份、提供恢复功能、关键设备和线路有硬件冗余、重要业务系统有本地热备份。这部分偏运维测试时确认备份策略是否配置、恢复演练是否做过、冗余是否真实生效而不是只看文档写了没有。5. 服务器侧检查与避坑清单5.1 服务器安全用例怎么补文档第二部分是服务器安全性说明包含操作系统账户、文件分区格式、中间件密码、数据库用户密码、数据库访问限制。这部分用例写得比较简略我一般会补成下面这张检查表来执行。检查项检查内容合格标准操作系统账户是否有多余账户、默认账户是否改名禁用仅保留必要账户无默认口令文件分区格式系统盘与数据盘格式、权限关键目录最小权限无 Everyone 可写中间件密码管理后台口令强度、是否默认强口令非默认限制访问来源数据库用户密码密码是否与用户名一致、长度不一致长度达标定期更换数据库访问限制是否配置 IP 过滤仅允许应用服务器 IP 连接这张表的价值在于把「无效」的 Expected Results 补成可判定的标准。执行时逐项登录服务器或查配置确认不要只问运维「配了吗」要看实际配置文件。5.2 常见问题与排查现象关掉 JavaScript 后非法输入照样提交成功。原因只有客户端校验服务器端没做二次验证。 解决在服务端对每个入参做类型、长度、范围校验前端校验只当体验优化。现象退出登录后点回退还能进系统。原因退出只清了前端状态服务端 Session 没销毁。 解决退出时服务端显式销毁会话并设置会话超时。现象日志里查不到谁改了数据。原因日志只记了操作内容没记操作人和 IP。 解决统一日志格式强制包含操作员、时间、IP、事项、状态五项。现象改 URL 参数能读到别人的数据。原因只在前端隐藏了入口服务端没校验数据归属。 解决每次请求都在服务端校验当前用户是否有权访问该资源。现象登录请求是 GET密码出现在 URL 里。原因表单 method 写成了 get或接口设计如此。 解决改为 POST敏感数据放请求体并启用加密传输。注意以上排查都要在授权范围内进行生产环境操作前先备份、先沟通。6. 把用例变成可复用的回归清单这份文档最大的价值不是让你跑一遍就完事而是把它变成团队的安全回归清单。我的习惯是把 18 条 Web 用例和 5 条服务器用例拆成带编号的检查项每项标注「测试方法、预期结果、责任人、复测状态」每次发版前挑与本次改动相关的项跑一遍。比如这次改了登录模块就重点跑密码策略、认证方式、登录次数限制、回退按钮这几条改了查询接口就重点跑 SQL 注入、越权、日志记录。这样安全测试不再是发版前的一次性运动而是嵌进流程的固定动作。再补一个具体技巧用例里的 Expected Results 有些写的是「无效」别直接跳过。我一般会拉着开发确认这条到底该是什么结果确认完补进清单下次就能直接判定。还有测试数据要单独准备别拿生产数据测注入和上传这是底线。从那以后我每次拿到这类用例文档都先做一件事——把「无效」的条目全部补成可判定的标准再开始跑否则跑完还是一笔糊涂账。希望帮到你。本文还有配套的精品资源点击获取