安全性测试用例：一份覆盖Web系统与服务器侧的检查单

简介这是一份专为网页系统测试人员整理的软件安全性测试用例文档围绕整个Web系统安全验证设计覆盖客户端验证、服务器端验证、日志记录完整性、访问控制、输入框验证、关键数据加密等核心测试维度。资源共1个PDF文件压缩包约484KB内容采用标准测试用例表格形式每条用例均提供具体操作步骤与对应预期结果并附有场景法Pass/Fail记录栏及作者、测试备注等字段可直接对照执行与留痕。目前已有1674人学习下载适合功能测试、安全测试及质量保障工程师参考。文档针对密码最小长度与复杂度、特殊字符与超长字符输入、URL参数恶意篡改、未验证输入、越权访问、日志操作留痕、防恶意注册等高风险场景给出了系统性检查点同时涉及会话认证方式、数据备份、超级用户与超级密码等细节可帮助团队快速建立或补齐安全测试用例库提升网页系统安全验证的覆盖率与规范性。1. 安全性测试用例一份能直接落地到Wen系统与服务器侧的检查单做互联网业务系统上线前的安全评估最怕的不是漏洞多而是不知道该从哪里下手。手里没有检查单测试就容易变成“想到哪测到哪”密码框试了个SQL注入登录页验证码绕过去就算完事等安全通告出来才发现文件上传、会话超时、日志完整性这些位置全漏了。这份安全性测试用例文档解决的就是这个问题——把Web系统侧18条用例和服务器侧5条基线核查项整理成逐条可执行的Steps与Expected Results对照表从客户端输入校验、URL越权访问、SQL注入、文件上传一直覆盖到通信加密、并发会话限制、数据备份恢复和服务器口令策略。适合刚接手安全测试的测试工程师照着执行也适合研发自测时拿来当检查基线每条用例都给了场景法Pass/Fail的记录位直接填结论就能形成测试证据。2. 把18个Web用例拆开看每条在测什么、预期怎么判2.1 输入与验证类用例客户端校验永远不能替代服务端校验Test Case001把“客户端验证、服务器端验证”放在一起前提是先禁用脚本调试、禁用Cookies再逐条执行9个Steps。这里有个容易被忽略的设计意图禁用脚本调试是为了让前端JavaScript校验失效禁用Cookies是为了让会话机制退化为无状态模式在这种“裸奔”状态下如果系统仍然能拦截非法输入说明服务端校验是真的存在。Steps里覆盖的输入类型分别是很大的数如4,294,967,269、负数、超长字符、特殊字符、中英文空格、字符串中间和首尾空格、NULL/null、0x0d 0x0a、正常字符串、类型不符的输入如数字与字母互换以及html和JavaScript代码。对应的Expected Results里除了第6条“输入的验证码正确成功登陆系统”是正常路径其余大部分都指向“输入的验证码错误”最后一句话点题系统权限设置是有效的。这类用例执行时的判断逻辑是“只要有一类非法输入被服务端接受整条用例就应判Fail”。超长字符和特殊字符容易翻车的位置在长度边界如果系统对输入长度有限制要分别尝试超过限制、刚好到达限制字数这两种情况因为有些框架在临界长度时会溢出报错暴露出后端参数拼接的细节。特殊字符串NULL、0x0d 0x0a要区分大小写与不同编码形态0x0d 0x0a在HTTP报文里对应回车换行如果输入被原样拼进日志或响应头就可能形成CRLF注入。我一般会在浏览器里开两个会话窗口一个正常执行Steps另一个用curl直接向服务端提交同样的参数对比前端拦截与服务端响应的差异——只有两端都拦截这条用例才算真正通过。Test Case005把输入验证拆成了9个维度数据类型、允许的字符集、最小和最大长度、是否允许空输入、参数是否必须、重复是否允许、数值范围、特定的枚举值、特定的模式如正则表达式。这其实是一份参数校验的检查维度表适合拿到接口测试中逐字段套用。执行时关注的不是“有没有报错”而是“报错信息是否泄露了后端逻辑”比如要求输入数字时提交一个超长字符串如果响应里出现“ORA-01722: invalid number”这类数据库原始错误就说明参数进入了SQL拼接层攻击面比单纯的校验失败大得多。Test Case007针对Grid、Label、Tree view类输入框未做验证的情况内容会被按照html语法解析执行。这是XSS用例的变体执行时要在这些控件里提交scriptalert(1)/script或img srcx onerroralert(1)看页面是否弹出对话框或发起额外请求。注意Tree view这类控件有些是前端框架渲染的富组件输入值可能被转义显示为纯文本这并不代表安全——要实际查看页面源代码里提交内容是否被原样嵌入如果出现在script或事件属性中依然判定为风险。Test Case008和Test Case009聚焦关键数据与认证请求方式。TC008的Step很直接登录界面输入密码后页面显示的是*****此时右键查看源文件确认密码明文是否出现在HTML源码中。有些老系统的密码框虽然是掩码显示但value属性里存的是明文或者浏览器自动填充把密码写进了DOM查看源文件或使用开发者工具查看元素都能暴露。TC009要求认证和会话数据使用POST而非GET方式这条要用抓包工具验证登录请求如果走GET密码会出现在URL参数里同时会留在浏览器历史、服务器访问日志和代理日志中任何能读到日志的人都能提取到凭据。2.2 访问控制与入侵防护类用例URL越权要区分水平与垂直Test Case002和Test Case006的核心是URL层面的越权访问。TC002给了三个具体场景需登录或特殊用户才能进入的页面能否通过直接输入网址进入带参数的网址恶意修改参数后是否能非法进入页面搜索页面URL中含有关键字时输入html代码或JavaScript是否在页面中显示或执行。TC006的Step描述了一个典型越权路径复制需要验证身份的页面URL关闭页面后再直接输入该地址查看能否访问到本没有权限的页面信息。这两条用例执行时要区分水平越权和垂直越权两类问题。水平越权的典型形态是修改URL中的业务参数比如把订单ID从100改成101如果返回了另一个用户的订单详情说明服务端没有做数据归属校验垂直越权的典型形态是普通用户直接拼管理员功能页面的URL路径比如绕过菜单直接访问/admin/user/list如果返回200而不是302跳转登录页就说明权限中间件没有生效。修改参数时原文给的思路很实用——若为数字则输入字母、很大的数字、特殊字符这同时覆盖了参数类型校验和越权校验如果打开网址出错或弹出异常堆栈责任定位反而是服务端参数处理不当这本身也是一条安全缺陷。Test Case015是IE回退按钮用例步骤写的是“退出系统后点击IE回退按钮能否重新回到系统中”。这条用例放在现在的浏览器环境下仍然有效差异只是触发方式现在更常见的是退出登录后用浏览器历史记录回退或多标签页之间互相切换会话系统应该强制跳转到登录页而不是展示已退出的页面缓存。如果回退后能看到上一位用户的敏感数据页面说明页面没有设置Cache-Control: no-store同时浏览器缓存策略有问题属于会话注销不完整的典型症状。2.3 日志、会话与通信安全类用例界面操作只能发现一部分问题Test Case003切入日志记录的完整性Steps是进行详单查询后检测系统是否记录操作员、操作时间、系统状态、操作事项、IP地址这五类信息。执行这类用例的难点不在“有没有日志”而在“日志字段是否齐全”和“日志是否防篡改”。我一般会找一个测试账号完成一次真实操作然后直接查数据库的审计表或日志文件核对五个字段是否都有值而不是只看日志系统页面上有没有一条记录。操作事项里要包含具体动作描述比如“查询了某用户的详单”而不是含糊的“操作成功”IP地址要能区分内网和公网来源如果全部记录为网关IP就无法追溯到具体终端。Test Case014登录次数限制和Test Case016、Test Case017构成了会话安全的三件套。TC014比较简单脚本连续输错密码确认触发锁定阈值TC016关于通信保密性的三个测试点值得细看通信双方一方在一段时间内无响应时另一方能否自动结束会话建立会话之前是否利用密码技术做会话初始化验证比如SSL建立加密通道前的握手验证通信过程中是否对整个报文或会话过程加密。这些用浏览器界面无法直接判断需要抓包看TLS握手报文和会话复用机制这个我在第五章展开讲。TC017列了9条会话控制要求从限制单个用户的多重并发会话、限制最大并发会话连接数、限制时间段内并发会话数到登录终端操作超时锁定、鉴别失败锁定、同一账号同一时间禁止并发登录、按安全属性允许或拒绝建立会话、服务水平降低到最小值时能检测报警、按优先级分配系统资源。这9条是典型的等保会话控制检查项执行时要注意区分测试方法a到e走功能测试用两个浏览器窗口模拟同一账号并发登录f和g走配置核查检查应用服务器会话管理参数h和i走故障注入压测或手动断开数据库连接后看系统是否触发报警。原文Test Case018是数据备份和恢复要求提供自动备份机制对重要信息进行本地和异地备份、提供恢复功能、重要网络设备和服务器硬件冗余、重要业务系统本地系统级热备份执行时要挑选一条真实数据做恢复演练而不是只确认备份任务在跑。用例编号测试对象关键验证点执行方式TC001输入验证非法输入是否被服务端拦截禁用脚本与Cookies后逐类提交TC002URL访问控制越权直链与恶意参数修改直接输入受限URL并改参TC003日志完整性操作员/时间/状态/事项/IP五字段操作后查日志表核对字段TC006访问控制关闭页面后直链能否进入复制URL新开窗口访问TC008关键数据加密密码是否明文出现在源码查看源文件与DOMTC009认证请求方式POST与GET抓包查登录请求方法TC014登录次数限制锁定阈值是否生效连续错误密码触发锁定TC015会话注销回退按钮能否重新进入退出后浏览器回退TC016/017通信保密与会话控制加密通道与并发限制抓包分析与双窗口并发登录TC018数据备份与恢复自动备份与恢复功能真实数据恢复演练Test Case010到TC013的用例原文只写了“无效”作为预期结果内容分别是SQL注入、文件上传风险、功能失效与异常带来的安全风险、操作日志检查。这几条属于“留白待补”的用例实际填写时要把预期结果写具体SQL注入的预期是“输入单引号、注释符、union拼接后系统不返回数据库异常信息且参数化查询正常”文件上传的预期是“上传非允许类型文件被拒上传成功后文件不放在Web可执行目录”功能失效的预期是“第三方接口超时或返回异常时系统降级且不泄露内部错误”。把预期结果补全用例才能真正执行起来这也是这份资源的价值所在——框架在细节需要测试者自己往里面填。3. 服务器侧5条基线核查从账户口令到数据库访问限制3.1 操作系统与中间件基线账户、分区与弱口令服务器部分的第一条用例是操作系统账户核查原文没展开步骤但这类核查在项目里的执行路径通常是固定的登录服务器查看当前系统中有哪些账户、哪些账户拥有sudo或root权限、是否存在长期未使用的幽灵账户、空口令账户是否被禁用。账户核查的常见做法是逐项执行系统命令并记录输出# 列出所有本地账户 awk -F: {print $1, $3, $7} /etc/passwd # 查找UID为0的账户正常应只有一个root awk -F: $30{print $1} /etc/passwd # 检查空口令账户 awk -F: ($2){print $1} /etc/shadow # 检查最近90天未登录的账户 lastlog -b 90执行完上述命令需要人工确认三件事UID 0账户是否只有root空口令字段是否为空lastlog输出中是否有可疑的“从未登录过”的账户。如果发现异常账户不能直接删除要先和业务方确认归属再走账号冻结流程。这里还要顺带检查/etc/sudoers里是否有非授权用户被赋予了NOPASSWD权限常见翻车点在运维为了方便把一个普通账户加入了sudo组这条很容易被漏掉。文件分区格式这条核查项的目的是确认系统与数据分区是否启用了足够细粒度的访问控制。Linux环境常见做法是确认关键目录使用的是ext4或xfs等支持权限位的文件系统而不是vfat或exfat这类不支持UNIX权限位的格式Windows环境则确认系统分区和Web站点目录使用的是NTFS。同时检查/tmp、/var/tmp这类可写目录是否挂载了noexec、nosuid、nodev选项防止攻击者把恶意二进制丢进临时目录执行# 查看挂载选项 mount | grep -E tmp|var|home # 检查关键目录的权限位 ls -ld /etc /usr /var /tmp /home执行完这两条关注点转移到目录权限的实际效果/etc目录如果被普通用户可写任何能拿到低权限shell的人都可能替换全局配置文件这比漏洞利用更直接。基线核查不是简单跑一遍命令而是要对着权限最小化原则逐项评判每个目录的owner、group、other三类权限位都要记录在案。中间件密码核查这一条针对的是Tomcat、Weblogic、Nginx等中间件的管理控制台或管理接口。Tomcat的conf/tomcat-users.xml里如果配置了manager-gui角色且口令是tomcat、admin这类默认值就等于把管理后台送给了扫描器Weblogic的boot.properties里如果明文保存了weblogic密码任何能读到该文件的人都能接管整个域。核查手段是读取中间件配置文件检查密码是否加密存储、是否修改过默认凭据同时检查管理端口是否对公网开放# Tomcat用户配置文件检查是否还存在默认口令 cat $CATALINA_HOME/conf/tomcat-users.xml # 检查中间件监听端口是否绑定在公网地址 ss -lntp | grep java常见的中问件翻车现场是管理端口绑定在0.0.0.0上绕过防火墙就能直接访问管理控制台配合弱口令一步到位。排查时如果发现管理端口只应内网访问操作是修改配置文件里的address绑定为127.0.0.1或内网IP再重启中间件服务验证。3.2 数据库层核查密码强度与IP过滤策略Test Case004服务器部分关注数据库用户密码原文给了两个问题密码是否一致、密码长度。这里的“一致”指的是同一套数据库在不同环境中的口令是否不同以及是否存在所有应用共用一个超级账户的情况。数据库密码策略核查的常见做法是直接查询系统表或视图以下以MySQL为例-- 查看所有数据库用户及当前密码策略 SELECT user, host, plugin FROM mysql.user; -- 检查是否有空口令账户 SELECT user, host FROM mysql.user WHERE authentication_string; -- 查看密码长度策略MySQL 8.0校验组件 SHOW VARIABLES LIKE validate_password%;执行完查询逐项核对是否存在userroot AND host%这类允许任意主机连接的账户是否还有authentication_string为空的账户validate_password_policy是否至少为MEDIUM并且密码长度下限不低于8位。如果发现过期账户或者host为%的高权限账户写进整改清单而不是直接改动——数据库账户改动牵连应用连接串必须先走变更流程。数据库访问限制核查对应的Test Case005原文点到的检查项是“是否应用IP过滤策略阻止非法访问”。这条的执行包含两个层面MySQL的bind-address是否限制在了应用服务器网段以及是否在数据库层面对应用账号的host字段做了来源IP限制而不是让所有账号都从%连接。常见做法是把应用账号的host改为应用服务器的内网IP或网段这样即使数据库口令泄露攻击者也无法从其他来源IP建立连接-- 查看当前bind-address配置 SHOW VARIABLES LIKE bind_address; -- 查看每个账号允许的来源主机 SELECT user, host FROM mysql.user; -- 查看数据库当前连接来源IP分布 SELECT SUBSTRING_INDEX(host, :, 1) AS src_ip, COUNT(*) FROM information_schema.processlist GROUP BY src_ip;服务器侧这5条核查项的特点是“命令好跑、结论难下”。跑一条cat /etc/passwd只需要几秒但要判断这些账户是否都应该存在、权限是否合理需要结合业务部署情况。我执行这类核查时通常会列一张对照表把核查项、命令输出、判定结论、整改责任人四个字段写满才算是完成了一个基线条目的闭环。4. 复现这份用例的避坑指南五个容易误判或漏测的场景4.1 验证码那一步“禁用脚本”和“禁用Cookies”经常只做了一半现象执行Test Case001时把9个Steps跑完所有非法输入都被拦截用例判Pass。但上线后爆破工具依然能撞库成功。原因浏览器设置里只禁用了JavaScriptCookies没真正禁用或者反过来。用例要求的前提是两种禁用同时生效目的是让前端的输入校验失效、服务端无法依赖会话状态识别请求来源。如果只禁了一半前端的正则校验还在拦截非法输入根本测不到服务端那层。解决在浏览器开发者工具的Network面板里直接屏蔽Cookies同时用curl命令手动构造不带Cookie的请求绕过浏览器渲染层把非法输入直接打到服务端接口上。两种方式的结果都验证过才算真正执行了这条用例。4.2 日志完整性的Pass标准有一条审计记录不等于五字段齐全现象做完详单查询后在日志系统里看到一条操作记录就把Test Case003判成Pass。后续安全审计时被质疑日志不完整。原因日志系统展示给管理员的列表页和后台审计表里真正存储的字段经常不是一回事。管理页可能只展示了操作时间和操作事项而操作员、系统状态、IP地址这些字段要么没采集要么存成了空值。解决直接连数据库查审计表对照操作员、操作时间、系统状态、操作事项、IP地址五个字段逐一确认非空。凡是五字段里任何一个为空的用例判Fail并定位是日志采集代码漏写了字段还是日志系统配置的映射关系不对。4.3 文件上传用例不能只测扩展名Content-Type和文件名解析都要覆盖现象上传一个.exe文件被系统拒绝Test Case011直接判Pass。几天后被安全扫描发现服务器Web目录下有一张“图片”实际上是个可执行的脚本。原因扩展名黑名单只挡了最外层攻击者把脚本文件后缀改成.jpg再用抓包工具把HTTP请求里的Content-Type改成image/jpeg系统内部的文件类型检测逻辑如果只看Content-Type头就会被绕过。上传成功后如果文件落在Web目录且Web容器配置了解析规则脚本就能被直接执行。解决改包后重新提交验证本次上传是否成功上传成功后访问该文件确认返回的是文件内容而不是被当作脚本执行。测试包里要包含正常的图片文件、改包后的伪装文件、以及内容里含?php的文本文件三种都试过再下结论。4.4 SQL注入的“无效”判定太笼统报错型、盲注、绕过要分开验证现象Test Case010执行时输入1页面弹出数据库错误然后把用例判为Fail换一个接口输入同样的内容没有任何反应又顺手判了Pass。原因SQL注入用例的“无效”预期结果需要区分三种形态。报错型注入输入特殊符号后页面出现SQL语法报错说明参数进入了SQL拼接层盲注型注入页面虽然在正常显示但响应时间或页面内容随布尔条件变化绕过型注入输入拼接了admin--之类的语法后发现可以绕过登录限制登录系统。用单一输入验证不了所有形态。解决对每个带参数的接口分别执行三种测试报错型测特殊符号盲注型测1 AND SLEEP(5)的响应时差绕过型测 OR 11是否产生越权响应。三类都没有异常这条用例才填Pass。4.5 并发会话那9条要求只测了重复登录就收工漏掉超时锁定和资源限制现象Test Case017执行时开了两个浏览器窗口用同一账号登录第二个窗口提示“会话已存在”用例判Pass其余a到i条款没有逐条验证。原因9条限制里a到e属于功能层面的会话控制f到i属于配置和政策层面的资源控制。功能测试能覆盖a到e的部分场景但操作超时锁定要看应用服务器的session超时配置和页面跳转逻辑资源限额要看中间件的线程池和数据库连接池上限设置这些在界面上操作不到。解决把9条拆成三批执行。第一批用双浏览器窗口逐一验证并发会话限制和禁止同时登录第二批检查应用服务器配置文件中session超时时间、登录失败锁定阈值并在系统里实际等待超时触发第三批用压测工具模拟高并发访问观察连接数到达上限时系统是否拒绝新请求并记录报警日志。三条路径都验证完TC017才算闭环。5. 把用例表升级成回归基线用抓包报文补齐界面看不到的验证Test Case016和TC009这两条用例有一个共同特点界面操作给不出可靠结论。登录请求用的是POST还是GET通信过程是否加密报文是否被加密传输这些只有看网络层的数据包才能确认。我执行这两类用例时有一个固定习惯浏览器Operator界面操作旁边同时开着抓包工具把界面操作和数据包对照着看。具体验证点可以做成一张对照表每次执行时逐行核对。打开登录页正常输入账号密码点登录抓包工具里过滤出这次登录请求确认请求方法是POST而不是GET确认请求地址是HTTPS而不是HTTP确认POST表单里没有把密码直接拼进URL。如果抓到的登录报文是用HTTP明文传输的密码字段直接可见那TC009直接判Fail不需要再看别的。再选中登录请求查看TLS握手信息确认协商的加密套件不是RC4这类已废弃的弱套件确认证书链有效且没有使用自签名证书。页面跳转到登录后连续等待超过会话超时时间再点击业务按钮抓包确认服务端返回了要求重新认证的响应而不是直接吐出业务数据。通信加密这条用例还可以做一次报文对比在同一个无线网络环境里分别用明文HTTP和HTTPS登录系统抓包查看两个会话中密码字段的可见性。明文HTTP的包里能直接看到账号密码字段而HTTPS包里数据段是密文这一对比得到的结论比任何配置核查都有说服力测试报告里作为证据截两张包内容对比图就够了。从那以后我每次跑安全性测试都强制自己把抓包工具和界面操作同步打开界面点一步、报文看一步。Test Case003的日志完整性和TC017的会话超时锁定这些“看起来在执行其实没验证到”的用例只有把报文层和数据存储层都对照过才敢填Pass。遇到用例预期结果是“无效”的留白位置我也会在归档前把补全的预期描述和执行结果一起写进去保证下一轮回归时别人拿着文档也能跑出同样的结论。希望这份用例模板的拆解过程能帮你在下一次安全测试里少踩几个坑。本文还有配套的精品资源点击获取