安全测试用例汇总
Posted 回忆式~过去.
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了安全测试用例汇总相关的知识，希望对你有一定的参考价值。
渗透测试 是一种合法且授权定位计算机系统，并对其成功实施漏洞攻击的方法，其目是查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力，根据安全指标不同测试策略也不同，如果遵循相同的原则，去证明软件的安全性，将有利于软件安全测试的工作规范的进行，有利于软件安全测试工作的发展。
渗透测试也称为黑客活动、道德黑客、白帽黑客。
安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令;②专门定做软件破坏系统的保护机制;③故意导致系统失败，企图趁恢复之机非法进入;④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。
本文汇总的工作中实际遇到的一些安全测试用例汇总：登录安全，服务端认证，会话管理，口令安全，配置测试，认证不充分，数据加密，文件上传漏洞，验证码，隐私保护，用户权限管理，越权访问，账号管理，注入漏洞，cookie安全，CSRF，mysql，OS，xss漏洞...
这些只能算是举例，并不能代表全部，实际的安全测试项要多的多。作为学习列出来和大家一起
| 用例类别 | 用例编号 | 用例名称 | 执行方式 | 用例级别 | 用例描述 | 预置条件 | 测试步骤 | 预期结果 |
| 账号管理 | SEC-AccoutManagement-001 | 基于角色的帐号权限管理模型 | 手工测试 | Level 1 | 系统基于角色的帐号权限管理模型进行角色控制 | 被测系统正常，有账号管理功能 | 以系统管理员登录系统，访问系统的权限管理模块，检查系统的权限管理是否基于以下步骤： 1.创建角色 2.为角色分配权限 3.创建帐号并指定其所属角色 4.帐号自动继承角色所拥有的权限 | 系统的权限管理基于以下步骤： 1.创建角色 2.为角色分配权限 3.创建帐号并指定其所属角色 4.帐号自动继承角色所拥有的权限 |
| SEC-AccoutManagement-002 | 帐号唯一性 | 手工测试 | Level 1 | 系统中的帐号应具有唯一性。如果帐号不唯一，就会造成审计和管理的混乱。 | 被测系统正常，有账号管理功能 | 1、使用管理员账号登陆系统。 2、查看系统中的账号列表，挑选一个已经存在的账号，例如：examplea。 3、尝试新建账号，账号名称使用examplea，看是否可以创建成功。 | 创建不成功，系统提示“XX帐号已存在”。 | |
| SEC-AccoutManagement-006 | 删除账号测试 | 手工测试 | Level 2 | 系统删除账号时，如果与之关联的信息删除不完全，而新建账号与已删除的账号同名时，又继承了原账号的某些信息，则可能出现越权等问题。 | 1、系统运行正常 | 1、使用管理员账号登陆系统。 2、新建应用账号，填写所有相关信息（个人信息、认证信息等），并分配或关联多个程序执行权限（如telnet登陆权限、FTP上传权限等）。 3、删除此应用账号。 4、新建应用账号与之前删除的同名，所有非必选信息默认不填，新建成功后，查看此应用账号是否有相关信息继承了之前的账号（如是否继承了原账号的个人信息或相关程序执行权限）。 | 1、删除应用帐号时，与该帐号的权限相关的所有属性同时删除或使之失效，不再可以重用。 2、新建应用帐号时，如果帐号与某个已经删除的帐号名称相同，则不能继承已删除帐号的所有信息（如个人信息、认证信息、授权信息等）。 | |
| SEC-AccoutManagement-009 | 检查系统文件权限 | 自动化 | Level 1 | linux下的系统文件权限检查 | 1.被测系统正常运行 | 1.在产品的系统目录中运行命令：find / -perm 777 -exec ls -l \\; > /tmp/perm_test.txt 说明：find / -perm 777 -exec ls -l \\; > /tmp/perm_test.txt 命令将查询到的信息写入到perm_test.txt文件中，并在该文件中进行检查 | 1.系统中不存在文件权限为777的文件，link文件除外 | |
| SEC-AccoutManagement-010 | UID为0的非root用户检查 | 手工测试 | Level 2 | UID为0的非root用户被认为是后门，业界广泛使用的安全检测工具都将UID为0的非root用户视为一种不安全行为，所以需防止产品预留此类后门帐号。 | 1、Unix/Linux系统运行正常 | 1、使用已知账号登陆Unix/Linux操作系统。2、查看/etc/passwd文件内容（cat /etc/passwd）。3、看是否存在UID为0的非root用户。 | 1、Unix/Linux系统中不存在UID为0的非root用户。 UID位置：root:x:0:0:root:/root:/bin/bash | |
| 服务端认证 | SEC-ServerAUTH-001 | 用户登录认证信息在服务端进行处理 | 手工测试 | Level 1 | 用户登录认证信息在服务端进行处理 | Web服务正常或 C/S应用正常 | B/S应用 1.启动浏览器，打开被测系统的登录页面； 2.启动WebScarab/burpsuite_v1.4.01代理，配置对GET和POST方法进行拦截； 3.在浏览器上设置代理服务器为127.0.0.1，端口为8008； 4.在步骤1打开的登录界面中输入正确的认证信息，提交登录 5.在WebScarab/burpsuite_v1.4.01拦截的消息中，修改认证信息为错误的内容，点击WebScarab/burpsuite_v1.4.01的“Accept Changes” 6.检查登录情况 C/S应用 1.启动C/S客户端登录页面； 2.启动softProxy代理，在“设置->基本设置”中配置被测系统的目标IP和Port；在“设置->高级设置”中配置“消息拦截规则”为“拦截所有消息”（ps：熟练掌握工具并极熟悉被测系统消息的测试人员可以选择按关键字拦截，并配置合适的关键字）； 3.点击softProxy“操作->启动”，开始拦截消息 4.在步骤1打开的登录界面中输入正确的认证信息，提交登录； 5.在softProxy拦截的“消息详情”中，修改认证信息为错误的内容，点击softProxy的“发送编辑后内容” 6.检查登录情况 | 1.登录不成功 |
| SEC-ServerAUTH-002 | 认证失败提示信息检查 | Level 2 | 认证失败后，不能提示给用户详细以及明确的错误原因，可以给出一般性的提示 | 1.系统提供登录认证功能 | 1.系统不同角色的用户输入错误的用户名或密码登录系统，查看系统的认证失败提示信息 | 1.认证失败后，系统提示：“用户名或者口令错误”；不能提示过于详细，不能出现类似于“密码错误”.“用户名不存在”之类的提示信息；用户名和密码错误的系统返回消息一致 | ||
| SEC-ServerAUTH-003 | 连续登录失败锁定帐号 | 手工测试 | Level 1 | 客户端在限定的时间段内有多次连续尝试登录失败时，可以执行如下策略中的一种： 策略一：锁定帐号 策略二：锁定IP 策略三：认证间隔时间依次加倍，采用这种方式时，用户可以不设置自动锁定。 适用于：操作员帐号.最终用户帐号。 | 1.系统提供登录认证功能 | 1.以某操作员帐号连续N次使用错误的口令登录，查看系统提示。（N<10）； 2.以某最终用户帐号连续N次使用错误的口令登录，查看系统提示。（N<10）； 3.连续N次使用错误的口令登录使帐号锁定（N<10）；再刷新登录界面，使用该帐号正确的口令登录； 4.连续N次使用错误的口令登录使帐号锁定（N<10）；关闭客户端，并清除客户端所有本地记录（如历史记录等等）,或者使用该账号在另外一台pc登陆；再次打开客户端，使用步骤1中的帐号正确的口令登录应用系统 | 1和2：系统提示该帐号或IP已被锁定或者第N次的认证处理时间是第N-1次认证处理时间的两倍。 服务端锁定一个帐号后，在解锁之前，该帐号不能登录系统；服务端锁定一个 IP 后，在解锁之前，由该 IP 发起的登录请求都不能成功。 对于只能在物理上本地操作的接入认证（如进入Bios），不强制提供锁定机制； 注：如果已经通过验证码防止帐号口令的暴力破解，那么，不强制遵循本条要求。 3和4：系统提示该帐号或IP已被锁定。 注：如果已经通过验证码防止帐号口令的暴力破解，那么，不强制遵循本条要求。 | |
| SEC-ServerAUTH-004 | 连续登录失败锁定策略的“允许连续失败的次数”可配置 | 手工测试 | Level 3 | 连续登录失败锁定策略的“允许连续失败的次数”可配置，取值范围：0-99 次，当取值为 0 时，表示不执行锁定策略，建议默认：3 次。 说明： 允许连续失败的次数指从最后一次登录成功以来登录失败的次数的累计值。 | 1.系统提供登录认证功能 | 访问认证的配置界面，检查“允许连续失败的次数”是否可配置 | 连续登录失败锁定策略的“允许连续失败的次数”可配置，取值范围：有验证码机制的产品可以为0-*次（0表示不启动锁定功能），无验证码机制的产品未1-*次 机机接口的锁定/解锁机制不强制提供用户配置接口。 注：如果已经通过验证码防止帐号口令的暴力破解，那么，不强制遵循本条要求。 | |
| SEC-ServerAUTH-005 | 认证失败次数计算方法检查 | Level 2 | 连续失败次数指同一个帐号从最后一次登录成功以来登录失败的次数的累积值 | 1.系统提供“连续登录失败锁定”功能； 2.系统提供的连续错误登录次数为N（N<10） | 1.连续N-1次使用错误的口令登录使帐号锁定； 2.使用另一个账号口令正常登录业务系统并退出； 3.使用步骤1中的账号再次错误登录 4.使用另外一台机器，尝试登录步骤1中的账号 | 系统提示该帐号已被锁定。 注：如果已经通过验证码防止帐号口令的暴力破解，那么，不强制遵循本条要求。 | ||
| SEC-ServerAUTH-007 | 自动解锁检查 | 手工测试 | Level 2 | 用户帐号连续登录失败锁定策略执行并在锁定时间超时后自动解锁 | 1.系统提供登录认证功能 | 分别以某操作员账号和最终用户帐号连续使用错误的口令登录，直到系统提示帐号或IP已被锁定；锁定时长过后再以正确的帐号和口令登录。 | 锁定时长过后，可以正常登录。 注：自动解锁和管理员手动解锁二者有其一就满足红线 | |
| SEC-ServerAUTH-008 | 管理员手动解锁检查 | 手工测试 | Level 2 | 在锁定时间内，仅能允许应用安全管理员角色所属帐号手动解锁该用户 | 1.系统提供登录认证功能 | 1.以系统管理员登录系统，查看系统是否提供安全管理员手动解锁功能（包括帐号解锁或IP解锁），是否提供除安全管理员之外的手工解锁：比如平级操作员互相解锁； 2.使用webscarab/burpsuite_v1.4.01测试解锁功能是否存在平级操作员越权解锁现象 | 1.系统提供管理员手动解锁功能并且能解锁成功 注：通过登录数据库手动修改操作员状态的做法属与维护定位，非解锁功能）。 注：自动解锁和管理员手动解锁二者有其一就满足红线 2.在锁定时间内，仅能允许应用安全管理员角色所属帐号手动解锁该用户 | |
| 口令安全 | SEC-PasswdSec-001 | 动态口令一次使用后立即失效 | 手工测试 | Level 1 | 动态口令一次使用后应立即失效，新的请求需要重新生成动态口令。 | 1、产品环境可用。 | 1、访问系统带有动态口令的页面（以带有动态口令的登陆页面为例）。 2、使用正确的用户名、密码、动态口令登陆系统，然后注销。 3、在动态口令无变化的前提下，再次使用正确的用户名、密码、动态口令登陆系统，看能否登陆成功。 4、手动刷新动态口令或等待动态口令刷新时间。 5、使用错误的用户名、密码，正确的动态口令登陆系统，登陆失败。 6、在动态口令无变化的前提下，使用正确的用户名、密码、动态口令登陆系统，看能否登陆成功。 | 1、第3、6步均登陆失败，系统提示类似“动态口令已失效”。 |
| SEC-PasswdSec-002 | 动态口令随机性 | 手工测试 | Level 1 | 动态口令应保证足够的随机性、不可预测，才能真正体现其安全性。 | 1、产品环境可用。 | 1、手动触发动态口令刷新或多次等待口令刷新时间，采集多组动态口令，分析是否存在规律。 2、查看产品源码中的动态口令生成函数，分析是否能保证足够的随机性。 | 1、动态口令足够随机，没有规律性（至少保证在刷新时间内不会被破解）。 | |
| SEC-PasswdSec-003 | 口令输入禁止明文显示 | 手工测试 | Level 2 | 对于系统自身操作维护类的口令，检查是否明文显示。 | 1.应用程序存在用户注册、登陆功能，并采取了登陆验证机制。 | 1、列举所有图形界面口令的输入点（登陆、修改口令等），检查缺省状态下是否明文显示口令。 2、在交互式命令行操作界面，执行涉及口令、密码的相关命令，检查是否明文显示；使用向上键或向下键查看历史命令，检查是否明文回显。 3、消费类产品（如手机终端等），用户输入口令时，检查是否明文显示口令（可短暂显示或由用户选择是否显示键入的口令明文）。 4、查找源码中涉及口令处理的模块，分析存储明文口令的变量在使用完成后，是否立即释放。 备注： （1）操作界面中的输入口令可不显示或用*代替，包括存储在日志中时也不能明文显示口令。 （2）对于某些业务接入口令，如wifi ap接入口令，根据业界惯例可选明文显示。 | 1、图形界面缺省没有明文显示用户键入的所有口令。 2、交互式命令行界面没有明文显示用户实时输入的口令，且查看历史命令也查看不到明文口令。 3、对于消费类产品（例如手机终端），可短暂显示或由用户选择是否显示键入的口令明文。 4、内存中的明文口令（如登录期间），在使用后立即覆盖。 | |
| SEC-PasswdSec-004 | 口令输入框禁止拷贝 | 手工测试 | Level 2 | 系统应禁止在口令输入框进行拷出、剪切操作以防止口令被非法窃取。 | 1.应用程序存在用户注册、登陆功能，并采取了登陆验证机制。 | 1.在口令输入框中输入口令； 2.全选口令，使用鼠标右键或者Ctrl+C快捷键尝试拷贝口令； 3.将拷贝的内容粘贴到记事本中，如果成功说明存在问题； 4.全选口令，使用鼠标右键或者Ctrl+X快捷键尝试剪切口令； 5.将剪切的内容粘贴到记事本中，如果成功说明存在问题。 | 1.键入口令时不能明文显示。 2.口令输入框不支持拷出、剪切功能。 | |
| SEC-PasswdSec-005 | 重新认证 | 手工测试 | Level 1 | 对于重要的管理事务或重要的交易事务要进行重新认证，以防范会话劫持和跨站请求伪造给用户带来损失。 | 1.系统正常运行 | 重新认证的场合包括但不限于以下场景： 1） 终端用户操作超时被断开，重新连接时需要进行重新认证； 2） 用户修改自己口令时需要进行重新认证； 3） 解除会话锁定时需要进行重新认证； 4） 涉及金额的操作时（例如有资金操作的系统或软件产品）需要进行重新认证 | 重新认证的场合包括但不限于以下场景： 1） 终端用户操作超时被断开，重新连接时需要进行重新认证； 2） 用户修改自己口令时需要进行重新认证； 3） 解除会话锁定时需要进行重新认证； 4） 涉及金额的操作时（例如有资金操作的系统或软件产品）需要进行重新认证 | |
| SEC-PasswdSec-007 | 口令不能在网络中明文传输 | 手工测试 | Level 1 | 口令等认证凭证在传输过程中必须加密，使用高安全等级的加密算法。如果传输通道已经做了加密，例如使用了HTTPS、SFTP等，则口令可以不加密。 | 1、系统存在口令传输的场景。 2、产品环境可用。 2、获取产品资料 | 1.检查产品设计文档或资料，梳理产品所有涉及非信任网络的B/S、C/S应用.接口(ftp/Webservice等)，检查是否涉及口令的传输。 2.运行相应的功能并使用嗅探工具进行嗅探。 3.查看嗅探记录，根据传输的源IP及目的IP过滤出相应的记录，右键并点击“Follow TCP Stream”，检查是否能够看到明文的口令。 4.如果嗅探记录中为密文口令，是否存在：密文与密钥一起传输、传输口令的SHA256摘要(数据库中存储的也是MD5摘要)等不和规的场景。 | 1.在非信任网络之间进行口令的传输采用安全传输通道或者加密后传输，有标准协议规定除外。 2.避免密文口令与密钥一起传、.传输口令的SHA256摘要(数据库中存储的也是SHA256摘要)等等实际不能达到防止黑客攻击(重放攻击)效果的设计。 说明：系统不同节点间的通信如果中间网络经过Internet，则需要考虑敏感数据加密传输。 | |
| SEC-PasswdSec-008 | 口令复杂度检查 | 手工测试 | Level 3 | 对于人机接口或可远程访问的机机接口之间，产品默认在所有操作维护类口令设置时进行复杂度检查，若口令不符合复杂度规则，必须禁止设置并进行警告。 | 1、应用程序采用口令认证方式。 | 一、密码修改 1.登陆系统选择修改密码； 2.尝试使用长度小于6个字符的新密码； 3.尝试使用全部为小写字母的密码； 4.尝试使用全部为大写字母的密码； 5.尝试使用全部为数字的新密码； 6.尝试使用全部为特殊字符的新密码； 7.尝试使用用户名做为新密码。 | 一、产品支持用户关闭复杂度检查机制时，在CPI资料或界面中有提示风险。 二、系统默认检测口令复杂度，口令至少满足如下要求： 1、口令长度至少6个字符； 2、口令必须包含如下至少两种字符的组合: －至少一个小写字母； －至少一个大写字母； －至少一个数字； －至少一个特殊字符：`~!@#$%^&*()-_=+\\|[];:'",<.>/? 和空格 3、口令不能和帐号一样； 若设置的口令不符合上述规则，必须进行警告。 | |
| SEC-PasswdSec-009 | 口令修改功能验证 | 手工测试 | Level 3 | 检查系统用户口令修改是否验证旧口令，且是否对新口令进行确认。 | 1、系统运行正常 2、系统提供用户修改口令功能 | 1、使用普通账号登录系统。 2、尝试修改当前用户口令，看是否需要输入旧口令，且是否需要对新口令进行确认（例如：输入两遍）。 3、修改口令时，连续多次输入错误的旧口令，看是否提示旧口令错误，且禁止继续尝试修改口令。 4、使用管理员账户登录系统。 5、尝试修改自身口令，看是否需要输入旧口令，且是否需要对新口令进行确认（例如：输入两遍）。 6、尝试修改其他用户口令，看是否需要输入旧口令。 | 1、第2步普通用户修改自身口令需要验证旧口令，且需要对新口令进行确认。 2、第3步连续多次输入错误旧口令时，提示口令错误，且禁止继续修改口令。 3、第5步管理员账号修改自身口令需要验证旧口令，且需要对新口令进行确认。 4、第6步管理员可以修改其他账号口令，且不需要验证旧口令。 | |
| SEC-PasswdSec-010 | 弱口令字典检查 | 手工测试 | Level 4 | 如果用户使用常见的弱口令，攻击者通过字典攻击，口令将被很容易猜测，增加被破解的风险。 说明：弱口令包括：系统默认的口令、简单数字组合、空口令、和用户名相同的口令、长度很短的口令等。常见的弱口令如Password、a123456、abc123等等。 | 1、产品环境可用。 2、获取产品资料。 | 如果产品提供了弱口令字典功能，则需要执行下述验证步骤： 1、查看产品资料中的口令认证说明，看产品进行口令复杂度检查时，是否提供弱口令字典，且是否提供弱口令字典的更新机制。 2、使用管理员账号登陆系统，查看产品提供的弱口令字典，检查是否存在默认弱口令。 3、假设弱口令字典中默认存在弱口令huawei。新建普通账号，尝试使用huawei作为口令，看是否可以配置成功。 4、访问弱口令字典的更新接口，提交一个新的弱口令，例如：Admin@123。 5、再次新建普通账号，尝试使用Admin@123作为口令，看是否可以配置成功。 6、访问弱口令字典的更新接口，删除上面新增的弱口令Admin@123。 7、再次新建普通账号，尝试使用Admin@123作为口令，看是否可以配置成功。 | 1、系统存在默认的弱口令配置，内容不做要求。 2、第3、5步配置不成功。 3、第7步配置成功。 4、第4步新增弱口令成功。 5、第6步删除弱口令成功。 6、产品资料中明确弱口令字典功能及其更新维护方法。 | |
| SEC-PasswdSec-011 | 帐号新旧口令最少不同字符数 | 手工测试 | Level 4 | 根据产品实际情况，可以规定新旧口令之间的最小不同字符数，建议默认：2 | 对产品新旧口令间的最小不同字符数有要求 | 以新旧口令之间不同字符数不少于2为例，通过帐号登录到系统后，访问修改口令的界面，为当前登录设置新口令：假如旧口令为：ABcd_123设置新口令为：Abcd_124 | 新口令与旧口令之间不相同字符数少于2时，口令修改不成功。 | |
| SEC-PasswdSec-016 | 检查密码是否加密存储 | 手工测试 | Level 1 | 密码应该加密处理后存储在系统中，且加密方法应符合要求。 密码：口令、共享密钥、私钥、加密密钥等。 检查点：数据库、安装文件、配置文件、脚本、日志文件等。 | 1.分析系统中所涉及密码的检查点 2.在各个检查点构造相关的密码信息 | 方法一：从存储密码的载体入手，检查是否存在明文存储的问题。 1.遍历数据库中涉及口令存储的表字段，检查口令是否加密存储，且加密算法是否采用合适的单向加密算法保护（比如SHA256、HMAC-SHA1、HMAC-SHA256等）： a.对于新开发产品（资料规范）检查数据库接口说明书，搜索出相关字段； b.oracle数据库使用“SELECT * FROM USER_TAB_COLUMNS where column_name LIKE '%PASS%' ORDER BY TABLE_NAME”，搜索相关字段； c.其他数据库可以飞检或者导出数据库到一个文件中；内存数据库通常有接口文档，搜索相关字段。 2.遍历系统所涉及的所有文件，检查密码是否加密存储，且所使用的加密算法是否符合要求： a.find . -name "*" | xargs grep -i "passw"（举例） 3.遍历版本发布路径中安装在Windows或者其他终端上的程序，检查密码是否都加密存储： a.安装完成或者解压完毕后使用Search and Replace.zip搜索相关字段。 4.遍历日志文件或日志表，搜索密码/口令相关字段，检查是否存在明文打印的密码： a.打开debug日志执行自动化/手工用例保存日志； b.搜索代码类似log_debug、log_echo等打印语句是否涉及密码。 5.遍历其他提供给用服或者定制的软件/工具，只要接入客户网络，都应该满足密码加密存储的要求。 方法二：从源码角度入手，检查是否存在明文存储的密码。 1.整理出系统内使用的口令清单，然后使用Check_code.sh进行检查。 2.检查口令加密所使用的加密算法是否是不可逆的。例如Base64等编码方式是不允许被用来进行加密的。 | 1.密码不能明文存储在系统(物理/内存数据库、配置文件、日志、脚本、jsp.jar包、zip包等)任何地方。 2.不需要还原的口令要求采用单向加密算法进行加密保护，建议优先使用HMAC算法。（推荐的不可逆密码算法： SHA256、SHA384、SHA512、HMAC-SHA256、HMAC-SHA384、HMAC-SHA512，不得采用自研的加密算法） | |
| 验证码 | SEC-CAPTCHA-001 | 操作员或系统最终用户登录/认证页面，必须使用验证码 | 手工测试 | Level 1 | 在 B/S 应用中，网页上的登录/认证表单必须加入验证码。 说明：使用验证码的目的是为了阻止攻击者使用自动登录工具连续尝试登录，从而降低被暴力破解的可能。如果觉得验证码影响用户体验，那么可以在前 3 次登录尝试中不使用验证码，3 次登录失败后必须使用验证码。验证码在设计上必须要考虑到一些安全因素，以免能被轻易地破解。验证码必须符合“验证码”的安全要求。 | 1.应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 方法一：从存储密码的载体入手，检查是否存在明文存储的问题。 1.遍历数据库中涉及口令存储的表字段，检查口令是否加密存储，且加密算法是否采用合适的单向加密算法保护（比如SHA256、HMAC-SHA1、HMAC-SHA256等）： a.对于新开发产品（资料规范）检查数据库接口说明书，搜索出相关字段； b.其他数据库可以飞检或者导出数据库到一个文件中；内存数据库通常有接口文档，搜索相关字段。 2.遍历系统所涉及的所有文件，检查密码是否加密存储，且所使用的加密算法是否符合要求： a.find . -name "*" | xargs grep -i "passw"（举例） 3.遍历版本发布路径中安装在Windows或者其他终端上的程序，检查密码是否都加密存储： a.安装完成或者解压完毕后使用Search and Replace.zip搜索相关字段。 4.遍历日志文件或日志表，搜索密码/口令相关字段，检查是否存在明文打印的密码： a.打开debug日志执行自动化/手工用例保存日志； b.搜索代码类似log_debug、log_echo等打印语句是否涉及密码。 5.遍历其他提供给用服或者定制的软件/工具，只要接入客户网络，都应该满足密码加密存储的要求。 方法二：从源码角度入手，检查是否存在明文存储的密码。 1.整理出系统内使用的口令清单，然后使用Check_code.sh进行检查。 2.检查口令加密所使用的加密算法是否是不可逆的。例如Base64等编码方式是不允许被用来进行加密的。 | 1.登录认证必须提供验证码；或者，多次登录失败后，必须提供验证码。 说明：在提问题的时候，要参照锁定策略，验证码和锁定策略都没有的情况才会成为安全问题 |
| SEC-CAPTCHA-003 | 验证码的每个字符的字体.大小.位置必须随机变化 | 手工测试 | Level 3 | 验证码的每个字符的字体.大小.位置必须随机变化 | 1.应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1.访问带有验证码的页面； 2.不断点击浏览器的“刷新”按钮，请求新的验证码； 3.看看验证码的每个字符的字体.大小.位置是否随机变化。 | 验证码的每个字符的字体.大小.位置随机变化。 | |
| SEC-CAPTCHA-004 | 验证码在服务端生成 | 手工测试 | Level 2 | 验证码模块生成的随机数不能在客户端的静态页面中的网页源代码里出现。 | 1.应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1.访问带有验证码的页面； 2.右键点击页面的空白处，在弹出右键菜单中选择“查看源文件”；或者点击IE的“页面”-->;“查看源文件” 3.在页面源文件中搜索步骤1的验证码字符串； | 在页面源文件中搜索不到步骤1的验证码字符串 说明：在客户端网页上点击鼠标右键.选择“查看源文件”时，必须看不到验证码模块生成的随机数。 | |
| SEC-CAPTCHA-005 | 验证码在一次使用后立即失效 | 手工测试 | Level 2 | 验证码在一次使用后要求立即失效，新的请求需要重新生成验证码。 | 1.应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1.访问带有验证码的登录页面； 2.开启WebScarab，配置对GET.POST和PUT请求进行拦截；并在浏览器中配置代理服务器IP为127.0.0.1，端口为8008； 3.填入错误的用户名和口令，填入正确的验证码，提交表单； 4.在弹出的WebScarab拦截窗口中点击“Raw”TAB页，选择并复制“Raw”TAB页内的所有内容，然后点击“Accept changes”完成登录请求的提交； 5.点击WebScarab的“Manual Request”TAB页，再点击其中的“Raw”TAB页，然后将步骤4拷贝到的内容粘贴进来，并将其中的用户名和口令改为正确的用户名和口令； 6.点击“Fetch Response”按钮； 7.检查“Response”区域中的响应信息是否包含“验证码错误”（或类似）的提示。 | “Response”区域中的响应信息包含“验证码错误”（或类似）的提示。 说明： 进行验证码校验后，立即将会话中的验证码信息清空，而不是等到生成新的验证码时再去覆盖旧的验证码，防止验证码多次有效；注意：当客户端提交的验证码为空，验证不通过。 | |
| SEC-CAPTCHA-006 | 检查验证码是否存在规律 | 手工测试 | Level 2 | 验证码是否存在规律，可预测将带来安全漏洞 | 1.应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1.多次刷新验证码； 2.发现验证码是否存在规律； | 1.验证码没有规律性 | |
| SEC-CAPTCHA-007 | 工具破解验证码 | 手工测试 | Level 3 | 检查验证码复杂度，是否容易通过工具识别 | 1.应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1.获取Web页面中验证码URL和参数； 2.将1步中的URL和参数添加到验证码识别工具VerifyCode.exe（w3可下载）进行识别，如果正确识别率超过50%，说明验证码容易遭受破解。 | 1.验证码识别率低于5% | |
| SEC-UserManagement-003 | 应用系统中的用户不能增加自己的权限 | 手工测试 | Level 2 | 应用系统中，创建的用户不能给自己增加响应的权限。 说明： 1、低权限用户创建一个新用户，通过新建的用户不能为自身增加权限。 2、新建的管理员不能增加自身没有的权限。 | 系统运行正常，系统权限可由管理权分配 | 测试思路： 1.用户管理员，尝试新建比自己高级别权限的账户（使用代理工具拦截创建账户的请求，分析各参数，是否有权限参数，如有，则尝试修改为比自己高级别的权限） 2.管理员尝试修改自己的账号权限，确认是否可以增加自己的权限。管理员配置好代理工具，在修改他人账号权限时尝试提升自己的权限（使用代理工具拦截修改账户的请求，修改被修改账号的参数为自己的账号参数，以此尝试给自己增加权限） | 1、低权限用户创建一个新用户，通过新建的用户不能为自身增加权限。 2、新建的管理员不能增加自身没有的权限。 | |
| SEC-UserManagement-007 | 水平权限管理 | 手工测试 | Level 2 | 用户 A 与用户 B 可都属同一个角色 RoleX，但是用户 A 与用户 B 都各自拥有一些私有数据，在正常情况下，应该只有用户自己才能访问自己的私有数据。 | 1.应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1. 注册系统用户 A和B ，寻找用户的唯一标示。比如，用户 ID 或者用户名。 2.使用用户 A 登陆系统。寻找系统功能中带有用户标示的部分，比如控制面板，密码修改等。 3.抓包，将访问链接中用户 A 的标示更换为用户 B，检查系统返回结果 | 1.不能看到用户 B 的相关信息 | |
| SEC-UserManagement-008 | 分配最小权限给运行程序的帐号 | 手工测试 | Level 2 | 分配最小权限给运行程序的帐号 | 1.被测系统正常运行 | 1.检查运行软件程序的帐号是不是root.administrator或supervisor等高权限帐号； 2.检查运行软件程序的帐号所在的用户组是否是sys，root，adminstrator，super等超级管理员组； 3.检查运行软件程序的帐号的权限 | 运行软件程序的帐号不是操作系统最高权限的帐号，不是超级管理员权限组成员，不具备超级管理员权限组的默认权限，且是一个分配最小权限（只分配了必须的权限）的操作系统帐号。 | |
| 数据加密 | 网络安全-好用的模糊测试器汇总与思考目录内核 && 通用模糊测试器OSS-Fuzz-7.1k stars, 对开源软件进行持续模糊测试，支持多种语言开发的软件，能够构建自己的模糊测试平台，例如结合Jazzer，学习成本较高。 clusterfuzz-4.7k stars,可扩展的模糊测试框架，OSS-Fuzz的后端。 syzkaller - 3.9k stars， 分布式、无监督、基于覆盖度的 Linux 系统调用模糊测试工具 AFL-2.5k stars，可使用QEMU，是一款比较经典的模糊测试器。 AFL++-2.5k stars，是AFL的高级分支，速度更快，变异策略更多更好。 honggfuzz-2.4k stars，支持安卓、windows、mac、linux等多种操作系统，可通过命令行或文件等输入模式，可使用QEMU，多进程、多线程，已发现多个CVE，OSS-Fuzz、go-fuzz等受到它的启发。 Choronzon - 265 stars，基于遗传知识的 Fuzzer gramfuzz - 221 stars,可定义复杂语法来建模文档与二进制数据格式的基于语法的 Fuzzer KernelFuzzer - 424 stars, 跨平台内核 Fuzzer 框架 QuickFuzz - 192 stars,Haskell 写的针对第三方软件使用常见文件格式进行测试的工具，利用现成的、知名的 Fuzzer Hodor Fuzzer - 124 stars, 曾经是另一个通用的 fuzzer radamsa - 通用的测试用例生成器 文件格式模糊测试器对pdf、 mp3、 swf 等文件格式进行模糊测试 Win AFL - 83 stars, Ivan Fratic 开发的针对 Windows 二进制程序 fuzzing 的 AFL 分支版本 AFLGo - 344 stars, 基于 AFL 构建的导向性灰盒 Fuzzing，针对程序特定位置进行模糊测试 Shellphish Fuzzer - 598 stars, 一个操纵 AFL 的 Python 接口，可以简单的写入测试用例与其他功能 zzuf - 366 stars, 一个透明应用输入 fuzzer，可以拦截文件操作、改变程序输入的随机位 binspector - 179 stars, 二进制格式分析与模糊测试工具 grammarinator - 215 stars, 基于 ANTLR v4 语法的文件格式模糊测试工具（ANTLR 项目已有大量的语法） pe-afl-195 stars, 针对 PE 文件进行静态二进制插桩辅助、结合 WinAFL 的 Fuzzer MiniFuzz - Microsoft 出品的基础文件格式 fuzzing 工具 BFF from CERT - 基础文件格式 fuzzing 框架 AFL Fuzzer (Linux only) - Michal Zalewski aka lcamtuf 开发的 Fuzzer TriforceAFL - 一个 AFL 的修正版，支持应用源码无法获得情况下的 fuzzing Peach Fuzzer - 帮助创建传统 dumb 以及小型 fuzzer 的框架 Failure Observation Engine (FOE) - 基于畸形文件的 Windows 程序 Fuzzing 工具 rmadair - 基于畸形文件的 fuzzer，使用 PyDBG 来监视感兴趣的信号 网络协议模糊测试器对 HTTP, SSH, SMTP 等网络协议进行模糊测试 Sulley - 1.3k stars, Michael Sutton 开发，包含多个可扩展组件的 Fuzzer 开发与 Fuzzing 测试框架，不再维护，推荐下面的 boofuzz - 1.5k stars, Sulley 框架的继任者 Spike - 像 sulley 的 fuzzer 开发框架，是 sulley 的前身 Metasploit Framework - 26.3k stars，通过 Auxiliary 模块使其具有了 fuzzing 能力的框架 Nightmare - 362 stars, 一个带有 Web 管理界面的分布式 fuzzing 测试套件，支持对网络协议进行 fuzzing rage_fuzzer - 20 stars, 未知协议包 fuzzer Fuzzotron - 355 stars, 支持 TCP、UDP 的简单多进程网络 Fuzzer Mutiny - 474 stars, 通过重放畸变的 PCAP 数据包来对网络进行 Fuzzer Fuzzing For Worms - 103 stars, 用于网络服务的 Fuzzing 框架 AFL (w/ networking patch) - 188 stars, 用于网络 Fuzzing 的非官方版 AFL AFLNet - 503 stars, 用于网络协议的灰盒 Fuzzer（AFL 的扩展） Jackalope-684 stars, 分布式的，可用于windows和macos的二进制模糊测试器。 Peach Fuzzer - 帮助创建传统 dumb 以及小型 fuzzer 的框架，之前是Python编写的，Peach3使用C#重写了。 浏览器模糊测试器BFuzz - 283 stars, 一款基于输入的模糊测试框架 WEB模糊测试器ffuf-6k stars，go语言编写的快速web模糊测试器，可对get、post数据包进行模糊测试，可使用外部变异器，例如，radamsa，来对种子进行变异生成测试用例。 wfuzz-4.2k stars，WFuzz 是一个用于 Python 的 Web 应用程序安全模糊器工具和库，可对路径、文件、URL参数、POST请求等进行模糊测试。 restler-fuzzer-1.5k stars，RestApi模糊测试器 SSRFmap-1.7k stars，自动的SSRF模糊测试器。 WebScarab-该工具是一个具有模糊测试能力的Web应用审计套件 云模糊测试器在云环境中进行模糊测试的模糊测试工具 Cloudfuzzer - 18 stars，在云环境中自动、便易地进行云 Fuzzing 的框架 Fuzzit - Fuzzit 是一个 Fuzzing 即服务的平台，被 systemd, radare2 等多个开源\\闭源项目使用 某语言的模糊测试器Javajazzer-489 stars，基于libFuzzer的覆盖率指导的JVM软件模糊测试器 C/C++libFuzzer - 面向 C/C++ 程序、基于覆盖度的进化模糊测试工具 Gogo-fuzz - 4.3k star，覆盖度指导的 go 包模糊测试 DOMdomato-1.4k stars，dom模糊测试器 JSfuzzilli-1.4k stars, js引擎模糊测试器 关于模糊测试器的思考模糊测试器的组成部分用例生成器基于变异：有种子文件，变异后生成测试用例 监控器监控被测试程序，获取被测试程序占用的cpu、内存、是否崩溃等情况 过滤器有些崩溃可能上网络波动等造成的，可以过滤 核心部分调用用例生成器生成测试用例，将测试用例通过发送或调用被测试程序的方式传输，接收监控器的结果，指导用例的生成，接收过滤器的结果，生成统计信息 结果统计统计发送的用例数量、崩溃数量、运行耗时等 提高代码覆盖率引导使用分支覆盖率等进行引导，使测试用例尽可能的覆盖更多代码 多进程、多线程模糊测试的一个大问题就是效率太低，通过多进程和多线程可以得到缓解 分布式同样，分布式也可以提高效率，同时，分布在不同机器，省的占用某一台机器过多内存和cpu，而且可以满足高可用。 可视化可通过web界面等进行可视化，实时显示统计信息，有多少生成器在运行等。 更多内容查看：网络安全-自学笔记 喜欢本文的请动动小手点个赞，收藏一下，有问题请下方评论，转载请注明出处，并附有原文链接，谢谢！如有侵权，请及时联系。如果您感觉有所收获，自愿打赏，可选择支付宝18833895206（小于），您的支持是我不断更新的动力。 以上是关于安全测试用例汇总的主要内容，如果未能解决你的问题，请参考以下文章 |