Web安全测试指南--认证

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

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

3、  已安装http拦截代理（burp、fiddler或webscarab均可）。

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

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

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

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

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

3、  已安装http拦截代理（burp、fiddler或webscarab均可）。

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

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

3、  在burp拦截到的http请求中，检查敏感数据是否使用POST进行提交。

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

3、  不存在图形验证码等其它防暴力破解措施。

2、  使用正确的账户名和错误的口令尝试登录N次。

3、  使用正确的账户和口令登录。

4、  如果系统返回类似“账户被锁定”这样的提示则继续往下测试，否则测试结束。

5、  等待M-1分钟后，重新使用正确的账户和口令登录。

6、  如果系统返回类似“账户被锁定”这样的提示则继续往下测试，否则测试结束。

7、  等待M-1分钟后，重新使用正确的账户和口令登录。

8、  检查返回结果。

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

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

3、  锁定策略不仅仅针对于web接口，同样适用于其它协议的接口，比如：FTP、SNMP等。

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，观察返回结果。

1、  已知明确的口令复杂度策略。

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

3、  存在可以设置口令的功能（注册用户、找回和修改密码等）。

4、  拥有常见的弱口令列表（非必须）。

1、  登录业务系统并打开可以设置口令的页面。

2、  输入任意小于6位长度的字符串（比如abc12）并提交。

3、  输入长度大于等于6位，分别由数字、大写普通字符[A-Z]、小写普通字符[a-z]和特殊字符单独组成的字符串并提交（比如 123456,abcdef和[email protected]#$%^等）。

4、  分别观察步骤2和步骤3的结果。

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  使用默认口令登录的用户要求强制或提示修改口令。

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

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

1、  登录业务系统，进入使用问答策略的功能（比如：找回密码）。

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

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

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

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

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

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

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

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

2、  步骤4中，短信验证码满足备注1的复杂度。

3、  步骤5中，服务器返回类似“短信验证码过期”的信息。

4、  步骤6中，服务器返回“短信验证码失效”的信息或者相关错误码。

5、  步骤7中，服务器网关地址不对外开放，如果开放，只有登录用户才可以访问。

l  1、4-6位长度。

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

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

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

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

3、  已安装http拦截代理（burp、fiddler或webscarab均可）。

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

2、  登录web应用，并进入到修改密码功能页面。

3、  检查是否需要旧密码才能修改新密码。

4、  输入旧密码和新密码并提交。

5、  在burp拦截到的http请求中，检查旧密码和新密码是否在同一个请求中传输。

6、  检查密码是否通过加密进行传输（参考用例：“敏感数据传输”）。

7、  检查是否存在密码复杂度策略（参考用例：“口令复杂度策略”）。

8、  反复提交错误的旧密码，检查是否对旧密码提交实施锁定策略（参考用例：“锁定策略”）。

9、  检查修改密码的功能页面是否需要认证才能够访问（参考用例：“认证绕过”）。

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请求内进行提交。

2、  步骤4中，系统满足“短信验证码”的安全要求。

3、  步骤5中，系统不会将原始密码返回给用户。

4、  步骤6中，重置密码的链接是不可预测的。

5、  步骤7中，临时密码满足“复杂度策略”的要求。

6、  步骤8中，系统强制要求用户修改临时密码。

7、  步骤9中，新密码和短信验证码或者问题的答案在同一个HTTP请求内进行提交。

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

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

1、  使用浏览器打开目标系统的web登录页面，并激活图形验证码。

2、  观察图形验证码字符长度。

3、  检查图形验证码的图片背景是否为单一颜色（比如：纯白色、蓝色等）。

4、  连续20次刷新并记录图形验证码，观察图形验证码的生成规律。

5、  在存在图形验证码的页面上点击右键，选择“查看源文件”，在源文件中搜索当前显示的图像验证码，并观察结果。

6、  在图形验证码图片上点击右键，选择“属性”，复制图形验证码的地址，重新在浏览器上多次刷新访问该地址，观察结果。

2、  步骤3中，图形验证码的图片背景有干扰元素（比如：花点、条纹）。

3、  步骤4中，不存在明显可预测规律，比如：1A1B、1A2B和2A2B等。

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

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

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）并再次提交，观察目标系统的返回结果。

2、  步骤6中，目标系统返回类似“图型验证码错误”的提示信息或者相对应的错误代码，如果返回了类似“用户名或密码错误”的信息则表示后台在处理逻辑上存在漏洞。

3、  目标系统返回类似“验证码错误/失效”的信息或者错误码。