认证:
5.1.1、敏感数据传输:
编号 | 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日志或缓存在浏览器。 |
5.1.2、锁定策略:
编号 | 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等。 |
5.1.3、认证绕过:
编号 | 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,观察返回结果。 |
预期结果 | 服务器返回要求登录认证或拒绝访问。 |
测试结果 |
|
备注 | 本测试用例偏向于灰盒测试,即拥有登录后台的权限,实际也可以用工具进行扫描,但效果没那么明显,具体参考《常见安全工具使用指南》。 |
5.1.4、复杂度策略:
编号 | 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 使用默认口令登录的用户要求强制或提示修改口令。 |
5.1.5、问答策略:
编号 | Web_ Authen_05 |
用例名称 | 修改口令功能安全性测试 |
用例描述 | 测试修改口令功能是否存在缺陷。 |
严重级别 | 高 |
前置条件 |
1、 业务系统存在使用问答策略的功能(比如:注册或找回密码)。 2、 目标web应用可访问,业务正常运行。 |
执行步骤 |
1、 登录业务系统,进入使用问答策略的功能(比如:找回密码)。 2、 检查业务系统预先设定的给用户选择的问题是否存在以下问题: 2.1、问题的答案和家庭成员或者朋友有关。比如某个家庭成员的名字或者用户本人的生日等。 2.2、问题的答案容易猜解或通过搜索引擎获得,比如:“我喜欢的颜色/球队”和“我的第一所学校”等。 3、 检查问答系统是否实施锁定策略以防止暴力破解答案(参考用例:“锁定策略”)。 4、 检查业务系统是否允许自定义问题和答案,如果是,确认是否定义任意简单的问题和答案。比如:“1加1等于几?” |
预期结果 | 1、 业务系统预设问题不存在步骤2所述的问题。 2、 问答系统满足“锁定策略”要求。 3、 问答系统不能任意自定义问题和答案。 |
测试结果 |
|
备注 | 本测试用例带有一定的主观性,当难以对于系统预设问题进行有效判断时,可以尝试多个人一起判断得出结论。 |
5.1.6、短信验证码:
编号 | 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、短信网关接口可通过研发接口人获取。 |
5.1.7、修改密码:
编号 | 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请求中提交,并且满足“敏感数据传输”、“口令复杂度策略”、“锁定策略”和“认证绕过”的要求。 |
测试结果 |
|
备注 |
|
5.1.8、找回密码:
编号 | 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)。 |
5.1.9、图形验证码:
编号 | 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、 目标系统返回类似“验证码错误/失效”的信息或者错误码。 |
测试结果 |
|
备注 |
|
提示:如果IE显示不正常,请使用chrome浏览器