渗透测试 是一种合法且授权定位计算机系统，并对其成功实施漏洞攻击的方法，其目是查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力，根据安全指标不同测试策略也不同，如果遵循相同的原则，去证明软件的安全性，将有利于软件安全测试的工作规范的进行，有利于软件安全测试工作的发展。
渗透测试也称为黑客活动、道德黑客、白帽黑客。
安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令;②专门定做软件破坏系统的保护机制;③故意导致系统失败，企图趁恢复之机非法进入;④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。
本文汇总的工作中实际遇到的一些安全测试用例汇总：登录安全，服务端认证，会话管理，口令安全，配置测试，认证不充分，数据加密，文件上传漏洞，验证码，隐私保护，用户权限管理，越权访问，账号管理，注入漏洞，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.其他数据库可以飞检或者导出数据库到一个文件中；内存数据库通常有接口文档，搜索相关字段。 | 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.检查运行软件程序的帐号的权限 | 运行软件程序的帐号不是操作系统最高权限的帐号，不是超级管理员权限组成员，不具备超级管理员权限组的默认权限，且是一个分配最小权限（只分配了必须的权限）的操作系统帐号。 | |
| 数据加密 | SEC-DataEnc-001 | 敏感数据采用加密信道传输 | 手工测试 | Level 1 | 敏感数据本身未加密时，在传输时必须采用安全传输通道保护，比如SSL.FTPS.LDAP over SSL.SSH.HTTPS.IPSec等； | 1.分析系统中所涉及的敏感数据范围及其涉及到传输的通道 | windows嗅探工具使用Wireshark，Suse使用tcpdump， solaris使用snoop。 1.启动Wireshark进行嗅探； 2.访问最终用户登录页面，输入用户名和口令进行登录； 3.查看Wireshark的嗅探记录，选择目的IP为服务器IP）的记录，右键并点击“Follow TCP Stream”，检查是否能够看到明文的敏感信息 | 传输信道加密保护，比如SSL.FTPS.LDAP over SSL.SSH.HTTPS.IPSec等，无法通过嗅探方式获取明文敏感信息 注意： 若所传输的敏感数据本身已经加密了，可不做信道加密要求。 |
| SEC-DataEnc-002 | 敏感信息加密存储 | 手工测试 | Level 1 | 敏感数据需要加密处理，保证敏感数据不会泄露 | 1.建立业务运行环境，构建业务运行所需的各种数据 | 1.梳理产品特性是否涉及的敏感数据（典型的敏感数据包括：口令.银行帐号.大批量个人数据.用户通信内容.密钥.用于认证的证书.License.用于网络通信协议协商的身份认证Key等） 2.检查敏感数据在系统部(物理/内存数据库.配置文件.话单.dedug日志.脚本.Web页面.客户端等等)是否加密存储 | 1.敏感数据已经加密不存在明文存储 备注：不安全加密算法：md5|MD5|Blowfish|DES|DESX|RC2|Skipjack|2TDEA|TEA|SEAL|CYLINK_MEK|RC4|3DES 代码或者系统中搜素密码敏感关键字:pass|password|pwd|passwd|mima|key|sharekey|crypto|fixation|admin|administrator|sysadmin|privilege|manager|passcode|factor 排查敏感文件：*.ini ，*.conf，config.xml | |
| SEC-DataEnc-003 | 敏感信息禁止采用HTTP-GET方式传输 | 手工测试 | Level 2 | HTTP-GET 方法提交敏感数据（比如密码）时，因为该方法使用查询字符串传递表单数据，容易导致敏感信息泄漏，因此敏感数据必须使用HTTP-POST方法提交。 | 1.分析系统中涉及到表单提交的的网页，作为检查对象。 | 1.打开目标网页，页面正常显示。 2.右键点击每一个提交表单数据的页面，选择“查看源文件”； 3.在“源文件”中搜索“method=”的字符串，检查是否存在method为GET的Form（表单）。 | 不存在method为GET的Form（表单） | |
| SEC-DataEnc-005 | 禁止在URL中携带Session标识 | 手工测试 | Level 2 | 在 B/S 应用中，禁止在 URL 中携带会话标识（如 jessionid）。 说明： 由于浏览器会保存 URL 历史记录，如果 URL 中携带会话标识，则在多人共用的 PC 上会话标识容易被其他人看到，一旦该会话标识还在其生命有效期，则恶意用户可以冒充受害用户访问 Web 应用系统。 | 1.系统正常运行 2.系统提供不同的应用服务 | 在整个测试过程中留心查看浏览器的地址栏中的URL是否携带了会话标识（如 jessionid） | URL不携带会话标识 | |
| 隐私保护 | SEC-Privacy-001 | 个人信息修改 | 手工测试 | Level 1 | 个人数据的设计要体现以用户为中心的设计思想，个人有行使数据法规赋予个人的隐私权。大多数国家的隐私法规明确要求提供手段供个人访问、修改、删除、阻塞其个人数据的收集。 | 1、系统运行正常 | 1、访问系统用户注册页面。 2、尝试注册新用户，并填写所有必选和可选的内容。 3、注册成功后，使用新用户登陆系统。 4、访问个人信息页面，看是否可以查看到所有注册时填写的信息。 5、尝试修改所有注册时填写的信息（注册时提示不能修改的除外），看能否修改成功。 6、尝试删除注册时标识为可选的内容，看能否删除成功。 | 1、个人注册信息可以随时提供给用户进行访问、修改、删除等操作。 |
| 配置测试 | SEC-ConfTest-001 | OWASP-ZAP扫描测试 | 自动化 | Level 1 | 利用自动化的Web安全扫描工具OWASP-ZAP进行扫描，以发现Web应用中存在的常见漏洞 | 1、 已知Web服务器域名或IP地址 2、 Web业务运行正常 | 1.使用OWASP对目标站点进行扫描 | 经过对扫描结果分析，确认不存在“中等等级”及以上级别的漏洞。
注意：该用例的执行对被测系统的性能影响比较大，而且可能导致一些垃圾数据，建议只在测试环境执行。 |
| SEC-ConfTest-002 | 运行帐号权限测试 | 手工测试 | Level 2 | 运行Web服务器的操作系统帐号权限越高，那么Web遭到攻击产生的危害就越大。因此，不应使用“root”、“administrator”、等特权帐号或高级别权限的操作系统帐号来运行Web，应该尽可能地使用低级别权限的操作系统帐号。 | 1、 已知Web网站IP地址和OS登陆帐号、密码 | 1、 登陆Web服务器操作系统 2、 查看运行Web服务器的操作系统帐号，不是“root”、“administrator”等特权帐号或高级别权限帐号，如果是则存在漏洞。 window：打开任务管理器，选择“进程”页，勾选左下方的“显示所有用户的进程”，检查运行Web服务器的帐号； unix：使用“ps –ef|grep java”命令，返回结果第一列的操作系统用户就是运行Web服务器的帐号； | 没有使用“root”、“administrator”等特权操作系统帐号运行Web。 | |
| SEC-ConfTest-003 | 不安全的HTTP方法 | 自动化 | Level 2 | 检查是否存在不安全的HTTP方法(DELETE、PUT、TRACE、OPTIONS) | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 1.使用OWASP-ZAP工具检查, 2.如果提示存在不安全的http方法，说明存在问题 | 1.扫描结果不包含高风险漏洞，中低风险漏洞有规避措施 | |
| SEC-ConfTest-004 | Web服务器版本信息收集 | 手工测试 | Level 2 | 一些情况下，Web服务器能通过隐藏或者修改banner信息的方式防止黑客攻击。这时候我们需要使用不依靠服务器Server标题头的扫描方式进行服务器类型、版本判断。 | 1、 Web业务运行正常 2、 已知Web服务器域名或IP地址 3、 测试用机安装了httprint（Windows环境） | 1、 运行Httprint_gui.exe 2、 在Host列中输入主机域名（如果没有域名则输入IP地址），在端口列中输入端口号。 3、 点击程序下方的运行按钮 4、 观察程序输出的结果 | 不能够得到Web服务器准确的版本信息 | |
| 登录安全 | SEC-SecLogin-001 | 认证错误提示 | 手工测试 | Level 1 | 为了进行暴力激活成功教程，攻击者需要知道已存在的用户名，再对该用户名进行攻击。所以，本测试用于确认目标服务器在处理登陆操作时会提示出具体的信息。 | 1.WEB应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1.以错误的用户账号和口令登录系统，查看系统的认证失败提示信息。 2.认证失败后，系统提示：“用户名或者口令错误”；不能提示：“用户不存在”/“用户名错误”。 | 服务器不会针对认证错误的情况提示准确的信息。 |
| SEC-SecLogin-002 | 验证码测试 | 手工测试 | Level 2 | 查看是否有验证码机制，以及验证码机制是否完善 | 1、 已知Web网站地址 2、 Web业务运行正常 3、 存在登陆页面 | 1、 登陆页面是否存在验证码，不存在说明存在漏洞，完成测试 2、 验证码和用户名、密码是否一次性、同时提交给服务器验证，如果是分开提交、分开验证，则存在漏洞 3、 在服务器端，是否只有在验证码检验通过后才进行用户名和密码的检验，如果不是说明存在漏洞。（检测方法：输入错误的用户名或密码、错误的验证码。观察返回信息，是否只提示验证码错误，也就是说当验证码错误时，禁止再判断用户名和密码。） 4、 验证码是否为图片形式且在一张图片中，不为图片形式或不在一张图片中，说明存在漏洞，完成测试 5、 生成的验证码是否可以通过html源代码查看到，如果可以说明存在漏洞，完成测试 6、 生成验证码的模块是否根据提供的参数生成验证码，如果是说明存在漏洞，完成测试 7、 请求10次观察验证码是否随机生成，如果存在一定的规律（例如5次后出现同一验证码）说明存在漏洞，完成测试 8、 观察验证码图片中背景是否存在无规律的点或线条，如果背景为纯色（例如只有白色）说明存在漏洞，完成测试 9、 验证码在认证一次后是否立即失效： • 请求登陆页面，得到生成的验证码 • 开启WebScarab，配置对GET和POST请求进行拦截；并在浏览器中配置代理服务器IP为127.0.0.1，端口为8008 • 填入错误的用户名和口令，填入正确的验证码，提交表单 • 从WebScarab拦截数据中复制对应登陆请求的POST或GET消息（文本格式），将其中的口令更改一个字符 • 在命令行中输入telnet <服务器域名或IP> <端口>，回车 • 将修改的内容粘贴到命令行窗口中，回车 • 判断返回的页面中是否包含“验证码错误”（或类似）的提示，如果没有，说明存在漏洞，完成测试 | 不存在上述漏洞 | |
| SEC-SecLogin-003 | 锁定策略测试 | 手工测试 | Level 2 | 在缺少锁定策略和验证码设计有问题的情况下，攻击者可以通过枚举的方式来进行暴力猜解。本测试用于发现目标系统是否缺少锁定策略。 | 1、 已知Web网站地址 2、 Web业务运行正常 3、 存在登陆页面 | 1、 打开登陆页面 2、 在用户名（或同功能的身份标志）输入框中输入正确的用户名 3、 在口令（或同功能的口令标志）输入框中输入错误的口令 4、 在验证码输入框（如果有的话）中输入正确的验证码 5、 提交表单 6、 重复1～5步骤10次 7、 判断目标系统返回的信息 | 目标系统提示“帐号已锁定”或者“IP已锁定”或者类似“锁定”等之类的信息。 | |
| SEC-SecLogin-004 | web登录提交方式 | 手工测试 | Level 2 | 检查登录是否使用POST表单提交 | 1.WEB应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1.启动WebScarab，并配置对GET.POST和PUT请求进行拦截； 2.访问登录页面，输入用户名.口令.验证码，登录，通过WebScarab拦截登录请求，查看登录认证请求是否为POST，如果用户名和密码使用GET提交，说明存在问题。 | 1.用户登录采用post表单提交 | |
| SEC-SecLogin-005 | 敏感信息加密传输 | 手工测试 | Level 3 | 检查是否采用安全机制传输口令信息 | 1.WEB应用程序存在用户注册.登陆功能，并采取了登陆验证机制； | 1.观察敏感数据（密码）的传输过程是否采用HTTPS方式进行传输。 2.使用wireshark在系统层面进行抓包分析，看是否可以看到明文的用户名和密码。 注意：测试的时候使用Burp.WebScarab等基于代理的方式抓包的情况，获取到明文是正常的，不能作为未加密的依据。 备注：登录过程中，往服务器端传递用户名和口令时，采用安全协议或加密机制，如HTTPS.HTTP digest等。只提供本地接入.登录，做设备管理使用的场景暂时不要求。 | 1.敏感信息加密传输 | |
| SEC-SecLogin-006 | 密码找回 | 手工测试 | Level 3 | 很多网站都会对注册用户提供“忘记密码”这类的密码找回功能，但由于设计的不合理该功能很可能会成为激活成功教程用户密码或重置用户密码的入口。 | 1. Web业务运行正常 2. Web有找回密码功能 | 1.启动WebScarab代理，进入“忘记密码”页面，输入已经用户名，点击找回密码，观察页面提示信息。 l2.如果提示页面显示的是一个邮箱，那么通过WebScarab代理尝试再提交时可否截获修改密码找回的邮箱。 3.如果是安全问题，则观察问题是否过于简单，容易猜想出来。 4.通过WebScarab观察服务器发送到客户端的信息中有无可用于激活成功教程的敏感信息 | 密码找回功能设计合理，无漏洞 | |
| SEC-SecLogin-007 | 修改密码测试 | 手工测试 | Level 2 | 如果修改密码功能存在着缺陷，攻击者可以通过此其缺陷修改其他用户的密码。 | 1、 已知Web网站地址 2、 Web业务正常运行 3、 网站提供修改密码的功能 4、 已知某正确的用户账号 | 1、 登陆网站 2、 进入密码修改页面 3、 查看是否必须提交正确旧密码，如果不需要则存在漏洞 4、 填写并提交修改密码数据，并以WebScarab拦截修改密码请求，观察新旧密码是否通过同一个HTTP请求提交到服务器，如果不是则存在漏洞； 5、 观察是否客户端是否提交用户名或用户ID，如果是则修改为其他用户名或用户ID，看看是否能够成功修改其他用户的密码，如果可以则存在漏洞。 | 用户修改密码时必须提供旧密码，普通用户无法修改其他用户的密码。
如果初始口令为系统提供的默认口令、或者是由管理员设定时，则在用户/操作员使用初始口令成功登录后，系统必须强制用户/操作员更改初始口令，直至更改成功，否则是漏洞。 | |
| SEC-SecLogin-008 | 重复登陆 | 手工测试 | Level 3 | 防止同一账号异地登陆 | 存在登录功能 | 1、账号已登录 2、同一账号在其他PC上登陆 | 存在异地登录提醒 | |
| SEC-Inadequate-002 | 注销功能漏洞 | 手工测试 | Level 3 | 注销功能实现是否存在缺陷，导致用户已退出客户端之后，会话ID还未失效 | 服务正常.网络可到达 | 1.启用客户端包括web浏览器，输入凭证连接到服务器。 2.通过抓包工具获取某个功能的数据报文。 3.点击注销按钮，然后重放第二步捕获的数据报文。如果是web应用，有很多相关的工具可以使用，如burpsuit.fiddle等，如果是C/S架构，可以通过协议结构自己写发包脚本进行测试，也可以直接将抓到的数据报文通过python脚本重放来实现。 4.观察返回结果。 | 返回结果失败，不能得到想要的数据 | |
| 会话管理 | SEC-SessionMgt-001 | Cookie存储方式测试 | 手工测试 | Level 2 | 某些Web应用将SesssionId放到了URL中进行传输，攻击者能够诱使被攻击者访问特定的资源，例如图片。在被攻击者查看资源时获取该SessionID（在HTTP协议中Referer标题头中携带了来源地址），从而导致身份盗用。 | 1、 已知Web网站地址 2、 Web业务运行正常 3、 Web业务存在登陆认证模块 4、 已知正确的用户名、口令 | 1、 登录系统。 2、 请求不同的业务应用 3、 观察URL。 | URL中没有携带Session ID信息（可能是sid,JSESSIONID等形式）。 |
| SEC-SessionMgt-002 | 用户注销登陆的方式测试 | 手工测试 | Level 3 | 查看是否提供注销登陆功能 | 1、 已知Web网站地址 2、 Web业务运行正常 3、 Web业务存在登陆认证模块 4、 已知正确的用户名、口令 | 1、 使用正常的用户、口令登录系统。 2、 查找登陆后的所有页面中是否存在明确的“退出”或“注销”（或类似）的按钮或者链接 | 登陆后的页面中有明确的“退出”或“注销”按钮。 | |
| SEC-SessionMgt-003 | 注销时会话信息清除 | 手工测试 | Level 2 | 由于网站程序在编写上考虑不周，用户注销后会话信息没有清除，导致用户在点击注销按钮之后还能继续访问注销之前（也就是登陆之后）才能访问的页面。我们需要经过测试来判断是否存在此类问题。 | 1、 已知Web网站地址 2、 Web业务正常运行 3、 存在注销功能的页面 | 1、 使用合法的账户口令登陆。 2、 开启WebScarab，配置对GET和POST请求进行拦截 3、 在浏览器中配置代理服务器IP为127.0.0.1，端口为8008 4、 在Web页面中进行一些操作（比如修改个人信息），这些操作都会被WebScarab拦截，不修改，在弹出的WebScarab界面中点击“Accept Changes”按钮。这样请求就被WebScarab记录下来。 5、 然后在Web页面中点击注销/退出（logout）。 6、 点击WebScarab的“Manual Request”TAB页，在Previous Requests的下拉列表框中选择“步骤4”所产生的URL请求，然后点击“Fetch Response”，重新发送“步骤4”的URL请求。 7、 在WebScarab的Response的“Raw”Tab页中观察返回结果，如果还能够正常完成“步骤4”的操作，则存在安全漏洞。 | 在WebScarab的Response的“Raw”Tab页中显示“HTTP/1.1 302 Moved Temporarily”，不能够访问只有登陆才能访问的页面，不能完成只有登陆后才能完成的操作。
如果存在多个注销功能的页面，要重复测试过程把所有有注销功能的页面测试完。 | |
| SEC-SessionMgt-004 | 会话超时时间测试 | 手工测试 | Level 3 | 查看是否存在浏览器窗口闲置超时后需重新登录的机制 | 1、 已知Web网站地址 2、 Web业务运行正常 3、 Web业务存在登陆认证模块 4、 已知正确的用户名、口令 | 1、 使用正常的用户、口令登录系统。 2、 将浏览器窗口闲置11分钟。 3、 刷新浏览器，查看是否需要重新登录。 备注：也可以登陆后台Web服务器，查看对应的web.xml文件中的session-timeout参数值，该值表示会话的超时时间。 | 会话超时时间不大于10分钟，刷新浏览器之后需要重新登录。 | |
| SEC-CookieSec-002 | 会话ID固定 | 手工测试 | Level 2 | 检查登录前和登录后会话ID值是否为固定值 | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 方法一： 1.启动WebScarab，并配置对GET.POST和PUT请求进行拦截； 2.访问登录页面，输入用户名.口令.验证码，登录，通过WebScarab拦截登录请求，查看并记录其中的jsessionid信息； 3.登录成功后，再访问任意功能菜单，并通过WebScarab拦截登录请求，查看并记录其中的jsessionid信息； 4.比较步骤2和步骤3获得的jsessionid是否一致。（也就是登录前和登录后，会话标识是否一致）。 方法二： 利用WebPecker或IBM Appscan对Web应用进行安全扫描，如果存在会话固定漏洞，扫描报告也会列出该漏洞。 | 1.登录前后会话ID不一致 | |
| SEC-CookieSec-003 | 检查会话超时机制 | 手工测试 | Level 3 | 用户的会话需要有超时机制，超时后需要重新登录 | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 1.使用正常的用户.口令登录系统。 2.将浏览器窗口闲置15分钟或30分钟。 3.点击任意操作菜单（注销和帮助菜单除外），如果不需要重新登录，说明存在问题。 备注：也可以登陆后台Web服务器，查看对应的web.xml文件中的session-timeout参数值，该值表示会话的超时时间。 | 1.系统存在超时机制，超时后用户需要重新登录 | |
| XSS漏洞 | SEC-XSS-001 | 反射型XSS | 自动化 | Level 3 | 反射型XSS | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 1.查找带参数的URL或者搜索功能，如http://127.0.0.1/search.jsp?name=abc; 2.在URL中加入XSS常用测试代码（测试代码见最后），如http://127.0.0.1/search.jsp?name=<script>alert(123456)</script>; 3.只要其中一条弹出显示123456的告警框，就说明该点存在反射型XSS漏洞； 4.如果没有弹出告警框，右键查看源代码，搜索“123456”，查看提交的“<>”是否转义为“<>;”； 5.如果没有被转义，通过闭合前边的html标签，改变参数继续循环2.3.4步测试，如果弹出警告框说明存在问题； | 1.不存在XSS漏洞 |
| SEC-XSS-002 | 存储型XSS | 自动化 | Level 3 | 存储型XSS | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 1.找到表单如留言板.私信.评论.订单等具有信息交互的功能（也可以通过WebScarab查找POST请求）； 2.在提交的表单内容中加入XSS常用测试代码，如<script>alert(123456)</script>; 3.访问对应的功能模块，如果弹出显示123456的告警框，说明存在问题； 4.如果没有弹出告警框，查看源代码，搜索“123456”，查看提交的“<>”是否转义为“<>;”； 5.如果没有转义，通过闭合前边的html标签，改变参数继续循环2.3.4步测试，如果弹出警告框说明存在问题； | 1.不存在XSS漏洞 | |
| SEC-XSS-003 | 未验证的输出导致的XSS | 自动化 | Level 3 | 未验证的输出导致的XSS | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 未经验证的表数据或文件数据在输出到客户端前需要进行HTML编码，以防止跨站脚本，测试方法如下： 1.查找存在外部数据调用模块，比如数据来自外部或者其它模块，例如在A模块中输入数据，需要在B模块中调用； 2.在A模块中输入的地方输入常见XSS代码，并提交； 3.观察返回页面的状态，查看A页面中是否弹出对话框，如果弹出告警框说明存在问题； 4.如果未弹出告警框，查看html源码，检查<>是否被转义这 <>;，并进行人工分析确认； 5.同样在B模块中采用步骤3.4测试。 | 1.不存在XSS漏洞 | |
| SEC-XSS-004 | XSS跨站脚本攻击 | 自动化 | Level 3 | HedEx多个页面存在XSS漏洞， | 页面未过滤用户的输入，存在跨站脚本注入漏洞 | 1.分析哪些参数的值来自用户输入，然后又返回到了用户浏览器； 2.对这些参数的值，构造script脚本（如”><script>alert(1);</script>），看是否在浏览器执行,如：如/hedex/hdx.do?fe=0&lib=31185319″><script>alert(1);</script>&v=03&homepage=2 | 注入的脚本无法在浏览器执行。 | |
| 越权访问 | SEC-Excee-001 | URL越权访问 | 手工测试 | Level 1 | URL越权访问 | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 1.登录Web系统，记录订单查询.订单提交.修改密码等重要功能的URL（正常情况下，这些URL只有登录后才能访问）； 2.注销，退出登录； 3.在没有登录的情况下，访问记录的URL，如果访问成功，说明存在问题； | 1.未登录情况下不能访问业务资源 |
| SEC-Excee-002 | 基于用户身份处理的横向越权 | 手工测试 | Level 2 | 基于用户身份处理的横向越权操作测试 | 1、 Web业务运行正常 2、 Web业务存在身份级别控制 3、 已知某页面（假设为http://www.example.com/abc.jsp）.提交的参数中存在着代表用户（假设为userA）身份的标志（假设为operator）， 4、 与userA同级别权限的用户userB 5、 测试用机安装了WebScarab软件 | 1、 运行WebScarab 2、 点击Proxy标签页->Manual Edit标签页 3、 选中Intercept requests 4、 打开浏览器，在代理地址中配置host为127.0.0.1，port为8008 5、 使用userA的身份登陆到Web应用 6、 进入http://www.example.com/abc.jsp页面，提交数据 7、 在弹出的对话框中的URLEncoded页面中，更改operator参数的值为userB，再点击Accept Changes按钮提交 8、 观察服务器处理 | 服务器返回操作失败或者以userA的用户身份操作。
备注：如果参数是基于GET方式的URL传递，则不需要通过WebScarab工具，直接在URL中进行修改提交即可。 | |
| SEC-Excee-003 | 用户纵向越权访问 | 手工测试 | Level 1 | 发现应用中存在的URL纵向越权操作。 | 1、 Web业务运行正常 2、 Web业务存在身份级别控制 3、 拥有超级管理员及普通用户的帐号和密码 | 1、 以超级管理员身份登陆Web网站 2、 单击鼠标右键，选择“查看源文件” 3、 在网页“源文件”中查找重要的管理菜单（比如用户管理）的URL链接，并拷贝URL链接地址 4、 退出登陆 5、 以普通用户身份登陆Web网站 6、 在浏览器地址栏中输入“用户管理”的URL地址（如http://www.exmaple.com/usermanage.do），然后回车 7、 观察普通用户是否能够顺利进入“用户管理”页面，并进行用户管理操作。 | 普通用户不能够通过直接URL访问、使用未授权的功能。 | |
| SEC-Excee-004 | Web权限提升漏洞 | 手工测试 | Level 3 | 拥有监控级别权限的已认证用户可以使用web界面提升权限，查看系统配置，远程重启设备，在设备上下载和上传文件。 | 服务正常.网络可到达 | 1.登陆高权限用户，开启fiddle2抓包，并操作相关的功能，如：查看系统配置.远程重启.下载.上传文件等。 2.注销后通过监控级别权限用户进行登陆，获取会话ID。 3.修改第一步抓到的数据报文中的会话ID字段，然后重放，观察结果。 | 执行失败 | |
| CSRF | SEC-CSRF-001 | 跨站请求伪造CSRF | 自动化 | Level 2 | 跨站请求伪造CSRF | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 1.对于 B/S 应用，访问系统的一些重要操作，比如修改余额.添加用户等，按要求输入相应的数据，并提交； 2.通过WebScarab拦截请求，查看整个交互过程中（有可能一个操作涉及多个步骤）客户端提交参数是否包含token.referer.动态口令以及验证码等信息； 3.如果不存在任何验证信息，说明存在问题； 4.删除token.referer.验证码等验证信息并提交，如果请求成功，说明存在问题。 备注： | 1.系统有防御CSRF的措施，渗透操作失败 |
| SEC-CSRF-002 | 防御CSRF攻击 | 自动化 | Level 1 | 防御CSRF攻击 | web服务正常运行 | 1.检查目标表单是否有有效的token随机串； 2.检查目标表单是否有验证码； 3.检查目标是否核对了 Referer 来源； 4.检查网站根目录下 crossdomain.xml 的”allow-access-from domain” 是否是通配符。 | 1.目标应用程序具备测试步骤中提到的防御 CSRF 措施的一个或多个。 | |
| SEC-CSRF-003 | GET方式跨站脚本测试 | 自动化 | Level 3 | 由于跨站脚本会导致会话被劫持、敏感信息泄漏、账户被盗，严重时甚至造成数据修改、删除，从而导致业务中断，因此需检测跨站脚本是否存在 | 1、 Web业务运行正常 2、 已知待测目标URL，假设为http://www.exmaple.com/page.xxx 3、 待测目标存在参数输入，假设为name=value 4、 在某种情况下，用户输入被重新显示在网页上，包括名字、帐号、检索结果等等（说明目标网站服务器并没有对用户提交数据检测） | 1、 在输入的参数后逐条添加以下语句，以第一条为例，输入http://www.exmaple.com/page.xxx?name=<script>alert(123456)</script>只要其中一条弹出显示123456的告警框，就说明存在跨站漏洞，记录漏洞，停止测试。 2、 如果没有弹出显示123456的告警框，则在返回的页面上单击鼠标右键，选择“查看源文件” 3、 查找网页源文件中是否包含完整的字符串<script>alert(123456)</script>，则不管有没有弹出显示123456的告警框，都表明存在跨站脚本漏洞。 4、 由于有些HTML元素（比如<textarea>或”）会影响脚本的执行，所以不一定能够正确弹出123456告警框，需要根据返回网页源文件的内容，构造value的值，比如 </textarea><script>alert(123456)</script> ‘><script>alert(123456)</script> “><script>alert(123456)</script> </title><script>alert(123456)</script> –><script>alert(123456)</script> [img]javascript:alert(123456)[/img] <scrip<script>t>alert(123456)</scrip</script>t> </div><Script>alert(123456)</script> | 不存在跨站脚本漏洞
备注：需要对页面上所有可以提交参数的地方进行测试。具体跨站脚本的测试语句根据实际情况的不同而不同，这里列出了一些最常见构造语句。 | |
| SEC-CSRF-004 | POST方式跨站脚本测试 | 自动化 | Level 3 | 由于跨站脚本会导致会话被劫持、敏感信息泄漏、账户被盗，严重时甚至造成数据修改、删除，从而导致业务中断，因此需检测跨站脚本是否存在 | 1、 Web业务运行正常 2、 已知待测目标URL，假设为http://www.exmaple.com/page.xxx 3、 待测目标以POST方式提交参数，显示为表单方式 4、 在某种情况下，用户输入被重新显示在网页上，包括名字、帐号、检索结果等等（说明目标网站服务器并没有对用户提交数据检测） | 1、 在POST表单中逐条输入以下语句，只要其中一条弹出显示123456的对话框，就说明存在跨站漏洞，记录漏洞，停止测试。 <script>alert(123456)</script> 2、 如果没有弹出显示123456的告警框，则在返回的页面上单击鼠标右键，选择“查看源文件” 3、 查找网页源文件中是否包含完整的字符串<script>alert(123456)</script>，则不管有没有弹出显示123456的告警框，都表明存在跨站脚本漏洞。 4、 由于有些HTML元素（比如<textarea>或”）会影响脚本的执行，所以不一定能够正确弹出123456告警框，需要根据返回网页源文件的内容，构造value的值，比如 </textarea><script>alert(123456)</script> ‘><script>alert(123456)</script> “><script>alert(123456)</script> </title><script>alert(123456)</script> –><script>alert(123456)</script> [img]javascript:alert(123456)[/img] <scrip<script>t>alert(123456)</scrip</script>t> </div><Script>alert(123456)</script> | 不存在跨站脚本漏洞
备注：需要对页面上所有可以提交参数的地方进行测试。 | |
| 注入漏洞 | SEC-Insert-001 | SQL注入 | 自动化 | Level 1 | 由于SQL注入有可能造成信息泄漏，在严重情况下（根据使用的数据库而定）甚至可能造成数据修改、删除，从而导致业务中断。因此必须发现所有存在的注入点。 | 1、 Web业务运行正常 2、 已知待测目标URL，假设为http://www.exmaple.com/page.xxx 3、 待测目标存在参数输入，假设为name=value | 1、 观察参数的值value是否为数字型。如果是数字型进行数字型测试，否则跳到第4步进行字符型测试（例如如果出现a那说明是字符型，如果出现2则将其当做数字型测试） 2、 将被测参数后加上测试语句“and 1=1”，即：地址栏中填入“http://www.exmaple.com/page.xxx?name=value and 1=1”, 如果返回正确页面则进行下一步操作，否则跳到第4步。 3、 将被测参数后加上测试语句“and 1=2”（这里以第n个参数为例），其他参数保持不变，即：地址栏中填入“http://www.exmaple.com/page.xxx? name=value and 1=2”, 如果返回正确页面则进行下一步操作，否则该参数存在注入漏洞，完成测试 4、 将被测参数后加上测试语句“’ and ‘1’=’1”，即：地址栏中填入“http://www.exmaple.com/page.xxx? name=value’ and ‘1’=’1”, 如果返回正确页面则进行下一步操作，否则该参数存在注入漏洞，完成测试 5、 将被测参数后加上测试语句“’ and ‘1’=’2”，即：地址栏中填入“http://www.exmaple.com/page.xxx? name=value’ and ‘1’=’2”, 如果返回正确页面则不存在漏洞，否则该参数存在注入漏洞，完成测试 | 不存在注入点
备注： |
| SEC-Insert-003 | 命令注入 | 手工测试 | Level 2 | 命令注入 | 1.WEB系统正常运行 2.系统提供不同的应用服务 | 1.启动WebScarab代理，配置对GET和POST方法进行拦截； 2.在浏览器上设置代理服务器为127.0.0.1，端口为8008； 3.对HTTP请求进行过滤和拦截，查找带有敏感的参数的请求如ls.dir.cmd.echo； 4.将参数修改为操作系统命令，如ls /etc/ 5.如果返回etc目录下的文件信息，说明ls命令执行成功，因此存在漏洞； 6.如果未返回etc下的目录信息，继续第4步测试，将参数修改为echo 123456 >>/tmp/tmp.txt 7.查看服务器中是否存在tmp.txt文件，如果存在并且内容相同，说明存在漏洞。 备注：测试不同的操作系统使用不同的参数，同时关注比较“特殊”的URL，如: | 1.系统没有异常响应 | |
| 文件上传漏洞 | SEC-Upload-001 | 文件上传测试 | 手工测试 | Level 1 | 很多网站提供文件上传功能（包括图片上传），如果在服务器端没有对上传文件的类型、大小以及保存的路径及文件名进行严格限制，攻击者就很容易上传后门程序取得WebShell，从而控制服务器。 | 1. Web业务运行正常 2. 待测网站存在文件上传页面 | 1. 登陆网站，并打开文件上传页面 2. 点击“浏览”按钮，并选择本地的一个JSP文件（比如hacker.jsp），确认上传。 3. 如果客户端脚本限制了上传文件的类型（比如允许gif文件），则把hacker.jsp更名为hacker.gif；配置HTTP Proxy（WebScarab）进行http请求拦截；重新点击“浏览”按钮，并选择hacker.gif，确认上传。 4. 在WebScarab拦截的HTTP请求数据中，将hacker.gif修改为hacker.jsp，再发送请求数据。 5. 登陆后台服务器，用命令find / -name hacker.jsp查看hacker.jsp文件存放的路径。如果可以直接以Web方式访问，则构造访问的URL，并通过浏览器访问hacker.jsp，如果可以正常访问，则已经取得WebShell，测试结束。如果hacker.jsp无法通过web方式访问，例如hacker.jsp存放在/home/tmp/目录下，而/home/tomcat/webapps目录对应.http://www.example.com/”>http://www.example.com/</A>，则进行下一步 6. 重复1～3，在WebScarab拦截的HTTP请求数据中，将hacker.gif修改为../tomcat/webapps/hacker.jsp，再发送请求数据。 7. 在浏览器地址栏输入.http://www.example.com/hacker.jsp”>http://www.example.com/hacker.jsp</A>，访问该后门程序，取得WebShell，结束测试。 | 服务器端对上传文件的类型.大小以及保存的路径及文件名进行严格限制，无法上传后门程序。 |
| MySQL | SEC-Mysql-001 | 数据库默认口令检查 | 手工测试 | Level 1 | 产品出厂使用的数据库口令必须符合口令复杂度要求 | 1.数据库稳定运行.可达，各种业务都运行正常 2.测试主机上安装了数据库连接工具 | 1.通过沟通或文档获取出厂时的数据库用户和密码； 2.验证密码正确性，并检查密码是否符合复杂度要求。 | 数据库默认口令符合口令复杂度要求 |
| SEC-Mysql-002 | 数据库账户的权限控制 | 手工测试 | Level 1 | 对数据库帐户授予的权限进行严格清晰的划分，所有数据库帐户只能具备执行其任务的最小权限 | 1.数据库稳定运行.可达，各种业务都运行正常 2.测试主机上安装了数据库连接工具 | 采用NGSSQuirreL进行检查，方法如下： 1.运行数据库对应的NGSSQuirreL软件（例如Oracle对应NGSSQuirreL for Oracle）； 2.根据扫描向导“Scan Wizard”配置扫描对象。以Oracle为例，第一步，直接点击“Next”按钮；第二步，在“Host”中填要扫描的IP地址，在“Port”中填写Oracle的监听端口（默认为1521），点击“Next”按钮；第三步，根据实际情况配置Oracle Listener的密码，然后点击“OK”按钮（如果没有设置密码则直接点击“Cancel”按钮）；第四步，点击下拉列表框选择要扫描的数据库实例，然后点击“OK”；第五步，在“Username”中填“system”，在“Password”中填system用户的实际密码（默认是manager），如果“Instance”为空，则填入要扫描的Oracle实例名，然后点击“Next”按钮；第六步，点击“Scan”按钮，开始扫描。 3.扫描工具窗口底部的状态栏显示“Scan Finished”，表明扫描结束了，点击“File”菜单，选择“Export Report to”-“HTML File”，输出扫描报告。 4.查看数据库扫描报告。 | 1.数据库帐户授予的权限进行严格清晰的划分，所有数据库帐户只能具备执行其任务的最小权限 | |
| SEC-Mysql-003 | 数据库的运行账号 | 手工测试 | Level 2 | 使用单独的操作系统的非管理员权限帐号来运行数据库 | 1.数据库稳定运行.可达，各种业务都运行正常 2.测试主机上安装了数据库连接工具 | 检查数据库的运行权限是否为超级管理员（root/administrator），检查方法如下： Linux: 1.登录操作系统，查看数据库进程信息：ps -ef|grep mysqld； 2.如果数据库进程使用root用户运行，说明存在问题； Windows： 1.登录操作系统，在cmd中输入“services.msc”命令打开服务管理器； 2.选择数据库服务名称，右键属性，查看“登录”选择； 3.如果登录身份为“本地系统账户”，说明存在问题。 | 1.运行数据库需要使用单独的普通用户运行。 | |
| SEC-Mysql-004 | 数据库文件及用户的数据文件的控制访问权限 | 手工测试 | Level 2 | 数据库系统本身的文件及用户的数据文件需要严格控制访问权限，只有数据库进程运行帐户以及管理员帐户才具备读写权限； | 1.数据库稳定运行.可达，各种业务都运行正常 2.测试主机上安装了数据库连接工具 | 检查MySQL数据库本身文件及数据库文件的权限配置，防止未经授权的用户将数据库文件复制或者删除，检查方法如下： 1.$MYSQL_HOME目录下的所有文件属于mysql用户.mysql组，且权限小于等于750； 2.mysql日志文件目录下的所有文件属于mysql用户.mysql组，且权限小于等于750； 3.mysql数据文件/裸设备的属于mysql用户.mysql组，且权限小于等于750。 | 1.只有数据库进程运行帐户以及管理员帐户才具备读写权限； | |
| SEC-OS-002 | 防病毒扫描 | 自动化 | Level 1 | 在软件（含补丁和文档 ）需对其做防病毒扫描 | 1.被测目标系统正常运行 | 1.使用Powersploit、ettercap、卡巴斯基扫描保证软件包中未感染或嵌入病毒/木马。如果防病毒软件产生告警，必需进行规避以消除告警 | 1.不允许存在任何木马后门、挂机、挖矿等恶意程序 | |
| SEC-OS-003 | 操作系统版本 | 自动化 | Level 1 | 低版本操作系统处理 | 1.被测目标系统正常运行 | 1.低版本的操作系统或停止运维的操作系统，应该建议伙伴不继续使用 | 1.停止使用该操作系统版本 | |
| SEC-OS-004 | 主机通信矩阵 | 自动化 | Level 1 | 端口开放 | 1.被测目标系统正常运行 | 1.进入RSAS/HSS工具扫描界面 2.在工具配置界面添加扫描任务 3.启动扫描任务 4.查看扫描结果 | 1.设置合理的访问控制策略，屏蔽高危端口，仅开放需要的端口；建议默认屏蔽所有端口，单独开放需要的端口，比如HTTP 80、SSH 20、RDP 3389、HTTPS 443等，模板请见备注中的附件 |
今天的文章安全测试用例汇总分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/27279.html
