| 编号 | Web_Authen_01_01 |
| 用例名称 | 敏感数据传输保密性测试 |
| 用例描述 | 测试敏感数据是否通过加密通道进行传输以防止信息泄漏。 |
| 严重级别 | 高 |
| 前置条件 | 1、 已明确定义出敏感数据范围（比如口令、短信验证码和身份证号等）。 2、 目标web应用可访问，业务正常运行。 3、 已安装http拦截代理（burp、fiddler或webscarab均可）。 |
| 执行步骤 | 1、 开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 2、 访问web页面并提交敏感数据（比如账户登录和修改密码等）。 3、 在burp拦截到的http请求中，检查敏感数据是否使用https协议传输。 |
| 预期结果 | 敏感数据是否使用https协议传输 |
| 测试结果 | |
| 备注 | 常见的敏感数据有用户口令、用户个人信息和session ID等等，但也有一些是和业务强相关的，需要结合业务进行判定。 |
| 编号 | Web_Auth_01_02 |
| 用例名称 | 敏感数据HTTP传输方法测试 |
| 用例描述 | 测试敏感数据是否通过POST方法进行提交以防止信息泄漏。 |
| 严重级别 | 中 |
| 前置条件 | 1、 已明确定义出敏感数据范围（比如口令、短信验证码和身份证号等）。 2、 目标web应用可访问，业务正常运行。 3、 已安装http拦截代理（burp、fiddler或webscarab均可）。 |
| 执行步骤 | 1、 开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 2、 访问web页面并提交敏感数据（比如登录和修改密码等）。 3、 在burp拦截到的http请求中，检查敏感数据是否使用POST进行提交。 |
| 预期结果 | 敏感数据使用POST方法进行提交。 |
| 测试结果 | |
| 备注 | 使用GET提交请求数据可能会被记录在web server日志或缓存在浏览器。 |
| 编号 | Web_ Authen_02 |
| 用例名称 | 账户锁定策略测试 |
| 用例描述 | 锁定策略用来缓解口令等敏感数据被恶意攻击者尝试暴力破解。 |
| 严重级别 | 高 |
| 前置条件 | 1、 存在登录页面。 2、 目标web应用可访问，业务正常运行。 3、 不存在图形验证码等其它防暴力破解措施。 |
| 执行步骤 | 1、 打开登录页面。 2、 使用正确的账户名和错误的口令尝试登录N次。 3、 使用正确的账户和口令登录。 4、 如果系统返回类似“账户被锁定”这样的提示则继续往下测试，否则测试结束。 5、 等待M-1分钟后，重新使用正确的账户和口令登录。 6、 如果系统返回类似“账户被锁定”这样的提示则继续往下测试，否则测试结束。 7、 等待M-1分钟后，重新使用正确的账户和口令登录。 8、 检查返回结果。 |
| 预期结果 | 1、 执行步骤4和6中，系统返回类似“账户被锁定”这样的提示。 2、 执行步骤8中，成功登录账户，账户被解锁。 |
| 测试结果 | |
| 备注 | 1、 N一般建议取值小于等于10，而M一般建议取值大于等于10。 2、 锁定策略不仅仅是针对账户口令的，而是针对所有可通过暴力破解获得的敏感数据，比如：短信验证码、找回密码的问答等。 3、 锁定策略不仅仅针对于web接口，同样适用于其它协议的接口，比如：FTP、SNMP等。 |
| 编号 | Web_ Authen_03 |
| 用例名称 | 认证绕过测试 |
| 用例描述 | 测试访问受限数据时是否需要认证以及是否可以绕过认证。 |
| 严重级别 | 高 |
| 前置条件 | 1、 已明确定义出受限数据范围（比如：web页面和静态配置文件等）。 2、 目标web应用可访问，业务正常运行。 3、 拥有登录访问web服务器后台的权限。 |
| 执行步骤 | 1、 登录web服务器后台，进入web应用根目录（比如www或ROOT）。 2、 根据web目录结构和受限访问文件的路径构建 HTTP URL。比如：路径为/ROOT/admin/changePwd.php的文件构建出来的HTTP URL可能为：http://www.example.com/admin/changePwd.php。 3、 打开浏览器，并在浏览器中访问由步骤2构建的URL，观察返回结果。 |
| 预期结果 | 服务器返回要求登录认证或拒绝访问。 |
| 测试结果 | |
| 备注 | 本测试用例偏向于灰盒测试，即拥有登录后台的权限，实际也可以用工具进行扫描，但效果没那么明显，具体参考《常见安全工具使用指南》。 |
| 编号 | Web_ Authen_04 |
| 用例名称 | 口令复杂度策略测试 |
| 用例描述 | 测试目标系统是否存在足够安全的口令复杂度策略。 |
| 严重级别 | 高 |
| 前置条件 | 1、 已知明确的口令复杂度策略。 2、 目标web应用可访问，业务正常运行。 3、 存在可以设置口令的功能（注册用户、找回和修改密码等）。 4、 拥有常见的弱口令列表（非必须）。 |
| 执行步骤 | 1、 登录业务系统并打开可以设置口令的页面。 2、 输入任意小于6位长度的字符串（比如abc12）并提交。 3、 输入长度大于等于6位，分别由数字、大写普通字符[A-Z]、小写普通字符[a-z]和特殊字符单独组成的字符串并提交（比如 123456,abcdef和!@#$%^等）。 4、 分别观察步骤2和步骤3的结果。 |
| 预期结果 | 1、 步骤2出现类似“口令过短”的提示信息。 2、 步骤3出现类似“不能全为数字/字母”等提示信息。 |
| 测试结果 | |
| 备注 | 1、 口令复杂度不仅仅适用于口令本身，对于可用来鉴别对象身份的任意凭证都需要设置适合的复杂度，比如：短信验证码和设备验证码等。 2、 本用例的口令复杂度策略适用于大多数情况，但其和业务对安全需求的强度有很大的关系，对于安全性高的业务（比如管理系统），可能要求设置更加复杂的口令复杂度，因此，应和业务结合进行测试。 3、 建议口令复杂度策略可配置，可参考的强口令复杂度策略选项如下： l 口令必须包含数字、大写普通字符[A-Z]、小写普通字符[a-z]和特殊字符中的3项。 l 口令存在一个明确的有效期限，建议3个月。 l 最近使用过的N个口令不能在新口令中使用，建议N取值8。 l 口令中不能出现连续N个字符（比如：aaa123），建议N取值3。 l 口令不存在于常见弱口令列表中（比：abc123、qwerty等）。 l 口令不能够和用户名以及用户名的反向字符串相同。 l 使用默认口令登录的用户要求强制或提示修改口令。 |
| 编号 | Web_ Authen_05 |
| 用例名称 | 修改口令功能安全性测试 |
| 用例描述 | 测试修改口令功能是否存在缺陷。 |
| 严重级别 | 高 |
| 前置条件 | 1、 业务系统存在使用问答策略的功能（比如：注册或找回密码）。 2、 目标web应用可访问，业务正常运行。 |
| 执行步骤 | 1、 登录业务系统，进入使用问答策略的功能（比如：找回密码）。 2、 检查业务系统预先设定的给用户选择的问题是否存在以下问题： 2.1、问题的答案和家庭成员或者朋友有关。比如某个家庭成员的名字或者用户本人的生日等。 2.2、问题的答案容易猜解或通过搜索引擎获得，比如：“我喜欢的颜色/球队”和“我的第一所学校”等。 3、 检查问答系统是否实施锁定策略以防止暴力破解答案（参考用例：“锁定策略”）。 4、 检查业务系统是否允许自定义问题和答案，如果是，确认是否定义任意简单的问题和答案。比如：“1加1等于几？” |
| 预期结果 | 1、 业务系统预设问题不存在步骤2所述的问题。 2、 问答系统满足“锁定策略”要求。 3、 问答系统不能任意自定义问题和答案。 |
| 测试结果 | |
| 备注 | 本测试用例带有一定的主观性，当难以对于系统预设问题进行有效判断时，可以尝试多个人一起判断得出结论。 |
| 编号 | Web_ Authen_06 |
| 用例名称 | 短信验证码安全性测试 |
| 用例描述 | 测试短信验证码的安全性设计是否存在缺陷。 |
| 严重级别 | 高 |
| 前置条件 | 1、 业务系统存在使用短信验证码的功能模块。 2、 目标web应用可访问，业务正常运行。 3、 已安装http拦截代理（burp、fiddler或webscarab均可）。 |
| 执行步骤 | 1、 开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 2、 登录业务系统，进入使用短信验证码的功能模块（比如：找回密码），并提交获取短信验证码的请求。 3、 将拦截到的http请求转入burp repeater，并在burp repeater中反复提交该请求，检查业务系统是否实施锁定策略来防止恶意滥发短信（参考用例：“锁定策略”）。 4、 尝试多次提交获取短信验证码，检查短信验证码是否存在复杂度策略（参考备注1）。 5、 在获取到短信验证码后，等待30分钟，然后提交使用该短信验证码，检查是否返回类似“短信验证码过期”的信息。 6、 使用burp将提交使用短信验证码的请求拦截并转入burp repeater，在burp repeater中反复重放该请求，检查服务器是否会返回“短信验证码失效”的信息或者相关错误码。 7、 检查短信网关接口是否对外开放，如果是，检查直接在浏览器上输入短信网关地址是否可以向任意号码发短信。比如，网关地址可能如下： http://www.example.com/sms/smsNetgateServlet?phone=xxx&content=xxx |
| 预期结果 | 1、 步骤3中，业务系统返回类似“使用过于频繁”的信息。 2、 步骤4中，短信验证码满足备注1的复杂度。 3、 步骤5中，服务器返回类似“短信验证码过期”的信息。 4、 步骤6中，服务器返回“短信验证码失效”的信息或者相关错误码。 5、 步骤7中，服务器网关地址不对外开放，如果开放，只有登录用户才可以访问。 |
| 测试结果 | |
| 备注 | 1、出于用户体验考虑，短信验证码的复杂度策略一般是： l 1、4-6位长度。 l 2、由纯数字或者由数字加普通字符组成。 2、短信网关接口可通过研发接口人获取。 |
| 编号 | Web_ Authen_07 |
| 用例名称 | 修改密码功能安全性测试 |
| 用例描述 | 测试修改密码功能是否存在安全缺陷。 |
| 严重级别 | 高 |
| 前置条件 | 1、 业务系统存在修改密码功能。 2、 目标web应用可访问，业务正常运行。 3、 已安装http拦截代理（burp、fiddler或webscarab均可）。 |
| 执行步骤 | 1、 开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 2、 登录web应用，并进入到修改密码功能页面。 3、 检查是否需要旧密码才能修改新密码。 4、 输入旧密码和新密码并提交。 5、 在burp拦截到的http请求中，检查旧密码和新密码是否在同一个请求中传输。 6、 检查密码是否通过加密进行传输（参考用例：“敏感数据传输”）。 7、 检查是否存在密码复杂度策略（参考用例：“口令复杂度策略”）。 8、 反复提交错误的旧密码，检查是否对旧密码提交实施锁定策略（参考用例：“锁定策略”）。 9、 检查修改密码的功能页面是否需要认证才能够访问（参考用例：“认证绕过”）。 |
| 预期结果 | 新旧密码在一个http请求中提交，并且满足“敏感数据传输”、“口令复杂度策略”、“锁定策略”和“认证绕过”的要求。 |
| 测试结果 | |
| 备注 | |
| 编号 | Web_ Authen_08 |
| 用例名称 | 找回密码测试 |
| 用例描述 | 测试找回密码功能是否存在安全缺陷。 |
| 严重级别 | 高 |
| 前置条件 | 1、 业务系统存在找回密码功能。 2、 目标web应用可访问，业务正常运行。 3、 已安装http拦截代理（burp、fiddler或webscarab均可）。 |
| 执行步骤 | 1、 开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 2、 登录web应用，并进入到找回密码页面。 3、 如果系统要求对用户预设的问题给出答案，则检查是否满足问答系统的安全要求（参考用例：“问答策略”）。 4、 如果系统使用短信验证码进行验证，则检查是否满足短信验证码的安全要求（参考用例：“短信验证码”）。 5、 如果在完成步骤3或者步骤4后，检查系统是否会将原始密码（即用户忘记的密码）返回给用户。 6、 如果系统发一个重置密码的链接到用户注册的邮箱，检查该链接是否具有可预测性。比如： http://www.example.com/resetPwd.jsp?token=xxxx，token的值是可预测的，可能是对用户名进行MD5的哈希值等等。 7、 如果系统发送一个临时密码给用户，让用户使用该临时密码进行登录，检查该临时密码具有足够的复杂度（参考用例：复杂度策略）。 8、 检查用户使用临时密码登录后系统是否强制要求用户修改密码。 9、 如果在完成步骤3或者步骤4后，系统要求用户在当前页面内设置新密码，检查新密码和短信验证码或者问题的答案是否在同一个HTTP请求内进行提交。 |
| 预期结果 | 服务器返回要求登录认证或拒绝访问。 |
| 测试结果 | 1、 步骤3中，系统满足“问答策略”的安全要求。 2、 步骤4中，系统满足“短信验证码”的安全要求。 3、 步骤5中，系统不会将原始密码返回给用户。 4、 步骤6中，重置密码的链接是不可预测的。 5、 步骤7中，临时密码满足“复杂度策略”的要求。 6、 步骤8中，系统强制要求用户修改临时密码。 7、 步骤9中，新密码和短信验证码或者问题的答案在同一个HTTP请求内进行提交。 |
| 备注 | 步骤6中，重置密码链接的可预测性测试使用黑盒的方式效果并不是特别好，最好是跟研发人员一起确认生成session id的算法（比如：UUID）。 |
| 编号 | Web_ Authen_09_01 |
| 用例名称 | 图形验证码设计测试 |
| 用例描述 | 测试图形验证码设计是否存在安全缺陷。 |
| 严重级别 | 高 |
| 前置条件 | 1、 目标业务系统存在图形验证码模块，并且能将其激活，比如：连续输错多次密码，频繁进行某个操作等等。 2、 目标web应用可访问，业务正常运行。 |
| 执行步骤 | 1、 使用浏览器打开目标系统的web登录页面，并激活图形验证码。 2、 观察图形验证码字符长度。 3、 检查图形验证码的图片背景是否为单一颜色（比如：纯白色、蓝色等）。 4、 连续20次刷新并记录图形验证码，观察图形验证码的生成规律。 5、 在存在图形验证码的页面上点击右键，选择“查看源文件”，在源文件中搜索当前显示的图像验证码，并观察结果。 6、 在图形验证码图片上点击右键，选择“属性”，复制图形验证码的地址，重新在浏览器上多次刷新访问该地址，观察结果。 |
| 预期结果 | 1、 步骤2中，图形验证码长度应大于等于4。 2、 步骤3中，图形验证码的图片背景有干扰元素（比如：花点、条纹）。 3、 步骤4中，不存在明显可预测规律，比如：1A1B、1A2B和2A2B等。 4、 步骤5中，在源文件中查找不到当前显示的图形验证码。 5、 步骤6中，在输入参数不变的情况下，生成的图形验证码随机变化。 |
| 测试结果 | |
| 备注 | 本用例基于IE浏览器攥写，步骤5、6在其它浏览器上有相对应的选项。 |
| 编号 | Web_ Authen_09_02 |
| 用例名称 | 图形验证码逻辑测试 |
| 用例描述 | 测试图形验证码使用逻辑是否存在安全缺陷。 |
| 严重级别 | 高 |
| 前置条件 | 1、 目标业务系统存在图形验证码模块，并且能将其激活，比如：连续输错多次密码，频繁进行某个操作等等。 2、 目标web应用可访问，业务正常运行。 3、 已安装http拦截代理（burp、fiddler或webscarab均可）。 |
| 执行步骤 | 1、 开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 2、 使用浏览器打开目标系统的web登录页面，并激活图形验证码。 3、 输入正确的用户名、密码和正确的图形验证码并提交。 4、 在burp拦截到的http请求中观察用户名、密码和图形验证码是否在同一个http请求内提交，比如： POST /login.jsp HTTP/1.1 #登录接口 Host: www.example.com [other HTTP headers] userName=admin&password=RightPwd& captcha=B8TP 5、 将burp拦截到的http请求转入burp repeater。 6、 在burp repeater中将http请求中的用户名或密码以及图形验证码修改成错误的值，并重新提交，观察返回结果，比如： POST /login.jsp HTTP/1.1 #登录接口 Host: www.example.com [other HTTP headers] userName=admin&password=WrongPwd& captcha=1234 7、 在burp repeater中将http请求中设置使用正确的用户名和图形验证码以及错误的密码并提交，比如： POST /login.jsp HTTP/1.1 #登录接口 Host: www.example.com [other HTTP headers] userName=admin&password=WrongPwd& captcha= B8TP 8、 重新将密码修改成正确的值（本例为RightPwd）并再次提交，观察目标系统的返回结果。 |
| 预期结果 | 1、 步骤4中，用户名、密码和图形验证码是在同一个http请求内提交。 2、 步骤6中，目标系统返回类似“图型验证码错误”的提示信息或者相对应的错误代码，如果返回了类似“用户名或密码错误”的信息则表示后台在处理逻辑上存在漏洞。 3、 目标系统返回类似“验证码错误/失效”的信息或者错误码。 |
| 测试结果 | |
| 备注 | |
原文：http://www.cnblogs.com/fishou/p/4202223.html