码迷,mamicode.com
首页 > Web开发 > 详细

Web安全测试指南--认证

时间:2015-01-04 21:09:18      阅读:359      评论:0      收藏:0      [点我收藏+]

标签:

认证:

5.1.1、敏感数据传输:

编号

Web_Authen_01_01

用例名称

敏感数据传输保密性测试

用例描述

测试敏感数据是否通过加密通道进行传输以防止信息泄漏。

严重级别

前置条件

1、  已明确定义出敏感数据范围(比如口令、短信验证码和身份证号等)。

2、  目标web应用可访问,业务正常运行。

3、  已安装http拦截代理(burpfiddlerwebscarab均可)。

执行步骤

1、  开启burp,设置对http请求进行拦截,并在浏览器中配置代理。

2、  访问web页面并提交敏感数据(比如账户登录和修改密码等)。

3、  burp拦截到的http请求中,检查敏感数据是否使用https协议传输。

预期结果

敏感数据是否使用https协议传输

测试结果

 

备注

常见的敏感数据有用户口令、用户个人信息和session ID等等,但也有一些是和业务强相关的,需要结合业务进行判定。

 

编号

Web_Auth_01_02

用例名称

敏感数据HTTP传输方法测试

用例描述

测试敏感数据是否通过POST方法进行提交以防止信息泄漏。

严重级别

前置条件

1、  已明确定义出敏感数据范围(比如口令、短信验证码和身份证号等)。

2、  目标web应用可访问,业务正常运行。

3、  已安装http拦截代理(burpfiddlerwebscarab均可)。

执行步骤

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、  执行步骤46中,系统返回类似“账户被锁定”这样的提示。

2、  执行步骤8中,成功登录账户,账户被解锁。

测试结果

 

备注

1、  N一般建议取值小于等于10,而M一般建议取值大于等于10

2、  锁定策略不仅仅是针对账户口令的,而是针对所有可通过暴力破解获得的敏感数据,比如:短信验证码、找回密码的问答等。

3、  锁定策略不仅仅针对于web接口,同样适用于其它协议的接口,比如:FTPSNMP等。

 

5.1.3、认证绕过:

编号

Web_ Authen_03

用例名称

认证绕过测试

用例描述

测试访问受限数据时是否需要认证以及是否可以绕过认证。

严重级别

前置条件

1、  已明确定义出受限数据范围(比如:web页面和静态配置文件等)。

2、  目标web应用可访问,业务正常运行。

3、  拥有登录访问web服务器后台的权限。

执行步骤

1、  登录web服务器后台,进入web应用根目录(比如wwwROOT)。

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  口令不存在于常见弱口令列表中(比:abc123qwerty等)。

l  口令不能够和用户名以及用户名的反向字符串相同。

l  使用默认口令登录的用户要求强制或提示修改口令。

5.1.5、问答策略:

编号

Web_ Authen_05

用例名称

修改口令功能安全性测试

用例描述

测试修改口令功能是否存在缺陷。

严重级别

前置条件

1、  业务系统存在使用问答策略的功能(比如:注册或找回密码)。

2、  目标web应用可访问,业务正常运行。

执行步骤

1、  登录业务系统,进入使用问答策略的功能(比如:找回密码)。

2、  检查业务系统预先设定的给用户选择的问题是否存在以下问题:

2.1、问题的答案和家庭成员或者朋友有关。比如某个家庭成员的名字或者用户本人的生日等。

2.2、问题的答案容易猜解或通过搜索引擎获得,比如:“我喜欢的颜色/球队”和“我的第一所学校”等。

3、  检查问答系统是否实施锁定策略以防止暴力破解答案(参考用例:“锁定策略”)。

4、  检查业务系统是否允许自定义问题和答案,如果是,确认是否定义任意简单的问题和答案。比如:“11等于几?”

预期结果

1、  业务系统预设问题不存在步骤2所述的问题。

2、  问答系统满足“锁定策略”要求。

3、  问答系统不能任意自定义问题和答案。

测试结果

 

备注

本测试用例带有一定的主观性,当难以对于系统预设问题进行有效判断时,可以尝试多个人一起判断得出结论。

5.1.6、短信验证码:

编号

Web_ Authen_06

用例名称

短信验证码安全性测试

用例描述

测试短信验证码的安全性设计是否存在缺陷。

严重级别

前置条件

1、  业务系统存在使用短信验证码的功能模块。

2、  目标web应用可访问,业务正常运行。

3、  已安装http拦截代理(burpfiddlerwebscarab均可)。

执行步骤

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  14-6位长度。

l  2、由纯数字或者由数字加普通字符组成。

2、短信网关接口可通过研发接口人获取。

 

5.1.7、修改密码:

编号

Web_ Authen_07

用例名称

修改密码功能安全性测试

用例描述

测试修改密码功能是否存在安全缺陷。

严重级别

前置条件

1、  业务系统存在修改密码功能。

2、  目标web应用可访问,业务正常运行。

3、  已安装http拦截代理(burpfiddlerwebscarab均可)。

执行步骤

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拦截代理(burpfiddlerwebscarab均可)。

执行步骤

1、  开启burp,设置对http请求进行拦截,并在浏览器中配置代理。

2、  登录web应用,并进入到找回密码页面。

3、  如果系统要求对用户预设的问题给出答案,则检查是否满足问答系统的安全要求(参考用例:“问答策略”)。

4、  如果系统使用短信验证码进行验证,则检查是否满足短信验证码的安全要求(参考用例:“短信验证码”)。

5、  如果在完成步骤3或者步骤4后,检查系统是否会将原始密码(即用户忘记的密码)返回给用户。

6、  如果系统发一个重置密码的链接到用户注册的邮箱,检查该链接是否具有可预测性。比如:

http://www.example.com/resetPwd.jsp?token=xxxxtoken的值是可预测的,可能是对用户名进行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中,不存在明显可预测规律,比如:1A1B1A2B2A2B等。

4、  步骤5中,在源文件中查找不到当前显示的图形验证码。

5、  步骤6中,在输入参数不变的情况下,生成的图形验证码随机变化。

测试结果

 

备注

本用例基于IE浏览器攥写,步骤56在其它浏览器上有相对应的选项。

 

编号

Web_ Authen_09_02

用例名称

图形验证码逻辑测试

用例描述

测试图形验证码使用逻辑是否存在安全缺陷。

严重级别

前置条件

1、  目标业务系统存在图形验证码模块,并且能将其激活,比如:连续输错多次密码,频繁进行某个操作等等。

2、  目标web应用可访问,业务正常运行。

3、  已安装http拦截代理(burpfiddlerwebscarab均可)。

执行步骤

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、  目标系统返回类似“验证码错误/失效”的信息或者错误码。

测试结果

 

备注

 

Web安全测试指南--认证

标签:

原文地址:http://www.cnblogs.com/fishou/p/4202223.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!