Web安全测试指南--认证

认证：

5.1.1、敏感数据传输：

编号	Web_Authen_01_01
用例名称	敏感数据传输保密性测试
用例描述	测试敏感数据是否经过加密通道进行传输以防止信息泄漏。
严重级别	高
前置条件	一、  已明肯定义出敏感数据范围（好比口令、短信验证码和身份证号等）。 二、  目标web应用可访问，业务正常运行。 三、  已安装http拦截代理（burp、fiddler或webscarab都可）。
执行步骤	一、  开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 二、  访问web页面并提交敏感数据（好比帐户登陆和修改密码等）。 三、  在burp拦截到的http请求中，检查敏感数据是否使用https协议传输。
预期结果	敏感数据是否使用https协议传输
测试结果
备注	常见的敏感数据有用户口令、用户我的信息和session ID等等，但也有一些是和业务强相关的，须要结合业务进行断定。

 

编号	Web_Auth_01_02
用例名称	敏感数据HTTP传输方法测试
用例描述	测试敏感数据是否经过POST方法进行提交以防止信息泄漏。
严重级别	中
前置条件	一、  已明肯定义出敏感数据范围（好比口令、短信验证码和身份证号等）。 二、  目标web应用可访问，业务正常运行。 三、  已安装http拦截代理（burp、fiddler或webscarab都可）。
执行步骤	一、  开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 二、  访问web页面并提交敏感数据（好比登陆和修改密码等）。 三、  在burp拦截到的http请求中，检查敏感数据是否使用POST进行提交。
预期结果	敏感数据使用POST方法进行提交。
测试结果
备注	使用GET提交请求数据可能会被记录在web server日志或缓存在浏览器。

 

5.1.2、锁定策略：

编号	Web_ Authen_02
用例名称	帐户锁定策略测试
用例描述	锁定策略用来缓解口令等敏感数据被恶意攻击者尝试暴力破解。
严重级别	高
前置条件	一、  存在登陆页面。 二、  目标web应用可访问，业务正常运行。 三、  不存在图形验证码等其它防暴力破解措施。
执行步骤	一、  打开登陆页面。 二、  使用正确的帐户名和错误的口令尝试登陆N次。 三、  使用正确的帐户和口令登陆。 四、  若是系统返回相似“帐户被锁定”这样的提示则继续往下测试，不然测试结束。 五、  等待M-1分钟后，从新使用正确的帐户和口令登陆。 六、  若是系统返回相似“帐户被锁定”这样的提示则继续往下测试，不然测试结束。 七、  等待M-1分钟后，从新使用正确的帐户和口令登陆。 八、  检查返回结果。
预期结果	一、  执行步骤4和6中，系统返回相似“帐户被锁定”这样的提示。 二、  执行步骤8中，成功登陆帐户，帐户被解锁。
测试结果
备注	一、  N通常建议取值小于等于10，而M通常建议取值大于等于10。 二、  锁定策略不只仅是针对帐户口令的，而是针对全部可经过暴力破解得到的敏感数据，好比：短信验证码、找回密码的问答等。 三、  锁定策略不只仅针对于web接口，一样适用于其它协议的接口，好比：FTP、SNMP等。

 

5.1.3、认证绕过：

编号	Web_ Authen_03
用例名称	认证绕过测试
用例描述	测试访问受限数据时是否须要认证以及是否能够绕过认证。
严重级别	高
前置条件	一、  已明肯定义出受限数据范围（好比：web页面和静态配置文件等）。 二、  目标web应用可访问，业务正常运行。 三、  拥有登陆访问web服务器后台的权限。
执行步骤	一、  登陆web服务器后台，进入web应用根目录（好比www或ROOT）。 二、  根据web目录结构和受限访问文件的路径构建 HTTP URL。好比：路径为/ROOT/admin/changePwd.php的文件构建出来的HTTP URL可能为：http://www.example.com/admin/changePwd.php。 三、  打开浏览器，并在浏览器中访问由步骤2构建的URL，观察返回结果。
预期结果	服务器返回要求登陆认证或拒绝访问。
测试结果
备注	本测试用例偏向于灰盒测试，即拥有登陆后台的权限，实际也能够用工具进行扫描，但效果没那么明显，具体参考《常见安全工具使用指南》。

5.1.4、复杂度策略：

编号	Web_ Authen_04
用例名称	口令复杂度策略测试
用例描述	测试目标系统是否存在足够安全的口令复杂度策略。
严重级别	高
前置条件	一、  已知明确的口令复杂度策略。 二、  目标web应用可访问，业务正常运行。 三、  存在能够设置口令的功能（注册用户、找回和修改密码等）。 四、  拥有常见的弱口令列表（非必须）。
执行步骤	一、  登陆业务系统并打开能够设置口令的页面。 二、  输入任意小于6位长度的字符串（好比abc12）并提交。 三、  输入长度大于等于6位，分别由数字、大写普通字符[A-Z]、小写普通字符[a-z]和特殊字符单独组成的字符串并提交（好比 123456,abcdef和!@#$%^等）。 四、  分别观察步骤2和步骤3的结果。
预期结果	一、  步骤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
用例名称	修改口令功能安全性测试
用例描述	测试修改口令功能是否存在缺陷。
严重级别	高
前置条件	一、  业务系统存在使用问答策略的功能（好比：注册或找回密码）。 二、  目标web应用可访问，业务正常运行。
执行步骤	一、  登陆业务系统，进入使用问答策略的功能（好比：找回密码）。 二、  检查业务系统预先设定的给用户选择的问题是否存在如下问题： 2.1、问题的答案和家庭成员或者朋友有关。好比某个家庭成员的名字或者用户本人的生日等。 2.2、问题的答案容易猜解或经过搜索引擎得到，好比：“我喜欢的颜色/球队”和“个人第一所学校”等。 三、  检查问答系统是否实施锁定策略以防止暴力破解答案（参考用例：“锁定策略”）。 四、  检查业务系统是否容许自定义问题和答案，若是是，确认是否认义任意简单的问题和答案。好比：“1加1等于几？”
预期结果	一、  业务系统预设问题不存在步骤2所述的问题。 二、  问答系统知足“锁定策略”要求。 三、  问答系统不能任意自定义问题和答案。
测试结果
备注	本测试用例带有必定的主观性，当难以对于系统预设问题进行有效判断时，能够尝试多我的一块儿判断得出结论。

5.1.6、短信验证码：

编号	Web_ Authen_06
用例名称	短信验证码安全性测试
用例描述	测试短信验证码的安全性设计是否存在缺陷。
严重级别	高
前置条件	一、  业务系统存在使用短信验证码的功能模块。 二、  目标web应用可访问，业务正常运行。 三、  已安装http拦截代理（burp、fiddler或webscarab都可）。
执行步骤	一、  开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 二、  登陆业务系统，进入使用短信验证码的功能模块（好比：找回密码），并提交获取短信验证码的请求。 三、  将拦截到的http请求转入burp repeater，并在burp repeater中反复提交该请求，检查业务系统是否实施锁定策略来防止恶意滥发短信（参考用例：“锁定策略”）。 四、  尝试屡次提交获取短信验证码，检查短信验证码是否存在复杂度策略（参考备注1）。 五、  在获取到短信验证码后，等待30分钟，而后提交使用该短信验证码，检查是否返回相似“短信验证码过时”的信息。 六、  使用burp将提交使用短信验证码的请求拦截并转入burp repeater，在burp repeater中反复重放该请求，检查服务器是否会返回“短信验证码失效”的信息或者相关错误码。 七、  检查短信网关接口是否对外开放，若是是，检查直接在浏览器上输入短信网关地址是否能够向任意号码发短信。好比，网关地址可能以下： http://www.example.com/sms/smsNetgateServlet?phone=xxx&content=xxx
预期结果	一、  步骤3中，业务系统返回相似“使用过于频繁”的信息。 二、  步骤4中，短信验证码知足备注1的复杂度。 三、  步骤5中，服务器返回相似“短信验证码过时”的信息。 四、  步骤6中，服务器返回“短信验证码失效”的信息或者相关错误码。 五、  步骤7中，服务器网关地址不对外开放，若是开放，只有登陆用户才能够访问。
测试结果
备注	1、出于用户体验考虑，短信验证码的复杂度策略通常是： l  1、4-6位长度。 l  2、由纯数字或者由数字加普通字符组成。 2、短信网关接口可经过研发接口人获取。

 

5.1.7、修改密码：

编号	Web_ Authen_07
用例名称	修改密码功能安全性测试
用例描述	测试修改密码功能是否存在安全缺陷。
严重级别	高
前置条件	一、  业务系统存在修改密码功能。 二、  目标web应用可访问，业务正常运行。 三、  已安装http拦截代理（burp、fiddler或webscarab都可）。
执行步骤	一、  开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 二、  登陆web应用，并进入到修改密码功能页面。 三、  检查是否须要旧密码才能修改新密码。 四、  输入旧密码和新密码并提交。 五、  在burp拦截到的http请求中，检查旧密码和新密码是否在同一个请求中传输。 六、  检查密码是否经过加密进行传输（参考用例：“敏感数据传输”）。 七、  检查是否存在密码复杂度策略（参考用例：“口令复杂度策略”）。 八、  反复提交错误的旧密码，检查是否对旧密码提交实施锁定策略（参考用例：“锁定策略”）。 九、  检查修改密码的功能页面是否须要认证才可以访问（参考用例：“认证绕过”）。
预期结果	新旧密码在一个http请求中提交，而且知足“敏感数据传输”、“口令复杂度策略”、“锁定策略”和“认证绕过”的要求。
测试结果
备注

5.1.8、找回密码：

编号	Web_ Authen_08
用例名称	找回密码测试
用例描述	测试找回密码功能是否存在安全缺陷。
严重级别	高
前置条件	一、  业务系统存在找回密码功能。 二、  目标web应用可访问，业务正常运行。 三、  已安装http拦截代理（burp、fiddler或webscarab都可）。
执行步骤	一、  开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 二、  登陆web应用，并进入到找回密码页面。 三、  若是系统要求对用户预设的问题给出答案，则检查是否知足问答系统的安全要求（参考用例：“问答策略”）。 四、  若是系统使用短信验证码进行验证，则检查是否知足短信验证码的安全要求（参考用例：“短信验证码”）。 五、  若是在完成步骤3或者步骤4后，检查系统是否会将原始密码（即用户忘记的密码）返回给用户。 六、  若是系统发一个重置密码的连接到用户注册的邮箱，检查该连接是否具备可预测性。好比： http://www.example.com/resetPwd.jsp?token=xxxx，token的值是可预测的，多是对用户名进行MD5的哈希值等等。 七、  若是系统发送一个临时密码给用户，让用户使用该临时密码进行登陆，检查该临时密码具备足够的复杂度（参考用例：复杂度策略）。 八、  检查用户使用临时密码登陆后系统是否强制要求用户修改密码。 九、  若是在完成步骤3或者步骤4后，系统要求用户在当前页面内设置新密码，检查新密码和短信验证码或者问题的答案是否在同一个HTTP请求内进行提交。
预期结果	服务器返回要求登陆认证或拒绝访问。
测试结果	一、  步骤3中，系统知足“问答策略”的安全要求。 二、  步骤4中，系统知足“短信验证码”的安全要求。 三、  步骤5中，系统不会将原始密码返回给用户。 四、  步骤6中，重置密码的连接是不可预测的。 五、  步骤7中，临时密码知足“复杂度策略”的要求。 六、  步骤8中，系统强制要求用户修改临时密码。 七、  步骤9中，新密码和短信验证码或者问题的答案在同一个HTTP请求内进行提交。
备注	步骤6中，重置密码连接的可预测性测试使用黑盒的方式效果并非特别好，最好是跟研发人员一块儿确认生成session id的算法（好比：UUID）。

5.1.9、图形验证码：

编号	Web_ Authen_09_01
用例名称	图形验证码设计测试
用例描述	测试图形验证码设计是否存在安全缺陷。
严重级别	高
前置条件	一、  目标业务系统存在图形验证码模块，而且能将其激活，好比：连续输错屡次密码，频繁进行某个操做等等。 二、  目标web应用可访问，业务正常运行。
执行步骤	一、  使用浏览器打开目标系统的web登陆页面，并激活图形验证码。 二、  观察图形验证码字符长度。 三、  检查图形验证码的图片背景是否为单一颜色（好比：纯白色、蓝色等）。 四、  连续20次刷新并记录图形验证码，观察图形验证码的生成规律。 五、  在存在图形验证码的页面上点击右键，选择“查看源文件”，在源文件中搜索当前显示的图像验证码，并观察结果。 六、  在图形验证码图片上点击右键，选择“属性”，复制图形验证码的地址，从新在浏览器上屡次刷新访问该地址，观察结果。
预期结果	一、  步骤2中，图形验证码长度应大于等于4。 二、  步骤3中，图形验证码的图片背景有干扰元素（好比：花点、条纹）。 三、  步骤4中，不存在明显可预测规律，好比：1A1B、1A2B和2A2B等。 四、  步骤5中，在源文件中查找不到当前显示的图形验证码。 五、  步骤6中，在输入参数不变的状况下，生成的图形验证码随机变化。
测试结果
备注	本用例基于IE浏览器攥写，步骤5、6在其它浏览器上有相对应的选项。

 

编号	Web_ Authen_09_02
用例名称	图形验证码逻辑测试
用例描述	测试图形验证码使用逻辑是否存在安全缺陷。
严重级别	高
前置条件	一、  目标业务系统存在图形验证码模块，而且能将其激活，好比：连续输错屡次密码，频繁进行某个操做等等。 二、  目标web应用可访问，业务正常运行。 三、  已安装http拦截代理（burp、fiddler或webscarab都可）。
执行步骤	一、  开启burp，设置对http请求进行拦截，并在浏览器中配置代理。 二、  使用浏览器打开目标系统的web登陆页面，并激活图形验证码。 三、  输入正确的用户名、密码和正确的图形验证码并提交。 四、  在burp拦截到的http请求中观察用户名、密码和图形验证码是否在同一个http请求内提交，好比： POST /login.jsp HTTP/1.1  #登陆接口 Host: www.example.com [other HTTP headers] userName=admin&password=RightPwd& captcha=B8TP 五、  将burp拦截到的http请求转入burp repeater。 六、  在burp repeater中将http请求中的用户名或密码以及图形验证码修改为错误的值，并从新提交，观察返回结果，好比： POST /login.jsp HTTP/1.1  #登陆接口 Host: www.example.com [other HTTP headers] userName=admin&password=WrongPwd& captcha=1234 七、  在burp repeater中将http请求中设置使用正确的用户名和图形验证码以及错误的密码并提交，好比： POST /login.jsp HTTP/1.1  #登陆接口 Host: www.example.com [other HTTP headers] userName=admin&password=WrongPwd& captcha= B8TP 八、  从新将密码修改为正确的值（本例为RightPwd）并再次提交，观察目标系统的返回结果。
预期结果	一、  步骤4中，用户名、密码和图形验证码是在同一个http请求内提交。 二、  步骤6中，目标系统返回相似“图型验证码错误”的提示信息或者相对应的错误代码，若是返回了相似“用户名或密码错误”的信息则表示后台在处理逻辑上存在漏洞。 三、  目标系统返回相似“验证码错误/失效”的信息或者错误码。
测试结果
备注

提示：若是IE显示不正常，请使用chrome浏览器