Web应用安全测试-防护功能失效

1、账号弱锁定机制

漏洞描述：系统帐号锁定时间太短

测试方法：登录时多次输入错误密码，触发账户锁定机制，查看锁定时间是否低于3分钟。

风险分析：若账户锁定时间过短，攻击者仍可利用其进行暴力破解。

风险等级：

【低危】：账户在多次尝试失败后锁定时间低于 3 分钟

修复方案：建议在不影响业务的前提下，账户在多次尝试失败后锁定时间不低于3分钟。

注意事项：暂无

2、图形验证码可自动获取

漏洞描述：图形验证码过于简单，可使用工具自动化识别。

测试方法：利用Python Image Library、tesseract-ocr、pytesser等python第三方库，经过二值化、文字分割等操作识别验证码。

风险分析：验证码通常使用一些线条和一些不规则的字符组成，这些字符通常同时包含字母和数字。但有些Web程序设计的验证码较简单，仅由数字或字母组成，且生成的验证码字符排列规整，很容易被程序自动识别。

风险等级：

【中危】：图形验证码可被自动化识别，且成功率高于95%。

修复方案：使用安全性强的验证码，验证码应从以下方面保证其安全性：验证码长度不低于4位，至少同时包含数字、字母或汉字，增加干扰因素比如线条，避免使用容易被程序自动识别的验证码，验证码不应返回到客户端。

注意事项：暂无

3、图形验证码绕过

漏洞描述：图形验证码可被绕过，执行暴力破解等操作。

测试方法：

验证码和用户名、密码是否一次性、同时提交给服务器验证，如果是分开提交、分开验证，则存在漏洞。
在服务器端，是否只有在验证码检验通过后才进行用户名和密码的检验，如果不是说明存在漏洞。（检测方法：输入错误的用户名或密码、错误的验证码。观察返回信息，是否只提示验证码错误，也就是说当验证码错误时，禁止再判断用户名和密码。）
验证码是否为图片形式且在一张图片中，不为图片形式或不在一张图片中，说明存在漏洞，完成检测。
生成的验证码是否可以通过html源代码查看到，如果可以说明存在漏洞，完成检测。
生成验证码的模块是否根据提供的参数生成验证码，如果是说明存在漏洞，完成检测。
请求10次观察验证码是否随机生成，如果存在一定的规律（例如5次后出现同一验证码）说明存在漏洞，完成检测。
验证码在认证一次后是否立即失效。

风险分析：图形验证码一般是防止使用程序恶意注册、暴力破解用户名密码或者批量发帖而设置的。在页面初始化时服务器向页面发送一个随机字符串，同时在Session里也保存一份，当用户提交时将随机数一起post到后台，通过与Session中保存的值对比，如果不相同，则有可能是恶意攻击。

风险等级：

【中危】：验证码可多次使用、发现特权验证码、前端校验、返回验证码、返回带有验证码信息的图片。

修复方案：

系统在开发时注意验证识别后销毁session中的验证码。
限制用户提交的验证码不能为空
判断提交的验证码与服务器上存储的是否一致
禁止将验证码明文信息发送至客户端

注意事项：暂无

4、短信验证码绕过

漏洞描述：短信验证码可被绕过，执行其他操作。

测试方法：

请求发送短信，填写任意验证码，然后提交其他操作请求，将验证码参数置空或删除，测试是否可绕过检测；
尝试特权验证码，如000000、111111等；
同一个短信验证码是否能使用多次；

风险分析：修改／重置密码、交易操作等功能通常需要短信验证码，若验证码可绕过，攻击者可利用该漏洞进行重置他人密码或转账等危险操作。

风险等级：

【中危】：验证码可多次使用或发现特权验证码

修复方案：

若存在特权验证码，建议将其删除；
应用服务端应严格校验验证码参数是否为空，格式是否正确；
关键操作每提交一次请求，应发送新的短信验证码，并且不可继续使用旧的验证码。

注意事项：暂无

5、短信验证码可暴力破解

漏洞描述：短信验证码位数太短或有效期太长导致可暴力破解

测试方法：点击发送短信验证码，输入任意验证码，提交请求，使用burpsuite拦截请求，在intruder模块设置验证码参数为枚举变量，这是payload类型为numbers，对验证码进行暴力破解。

风险分析：修改／重置密码、交易操作等功能通常需要短信验证码，若验证码可暴力破解，攻击者可利用该漏洞进行重置他人密码或转账等危险操作。

风险等级：

【中危】：手机短信验证码小于 6 位、有效期大于 1 分钟、验证错误次数无限制

修复方案：

短信验证码不少于6位；
有效期不超过1分钟；
验证码错误次数超过上限应采取账户锁定策略。

注意事项：暂无

6、参数覆盖

漏洞描述：参数覆盖，也叫对象自动绑定漏洞。许多框架均支持对象自动绑定，比如Spring MCV, 它允许将HTTP请求参数自动的绑定到对象，攻击者可以添加额外的HTTP请求参数，如果开发人员在处理业务逻辑时缺少安全校验就会导致参数覆盖问题。

测试方法：下面举一个具体的攻击场景：

这是国内某p2p平台账户余额功能

在账户余额的首页我们注册了账号进去以后发现余额是0元，需要充值才能进行投资理财然后提现。

在充值的页面可以同步余额，经过分析发现这个功能就是把平台上的钱和银行里账户的钱同步一致。这个p2p平台使用的是江西银行来保存客户资金所以最终同步的结果就是江西银行账号的钱和平台的钱一样。经过长期分析发现这个地方不存任何漏洞，然后继续往下看。

找到了一个用户地址的设置功能。

这是从burp response回来的数据包，通过对这个数据包的分析，发现请求的数据包和返回的数据包参数不一致。换句话说返回的数据包里面参数比请求的数据包多了几个字段其中有email字段和jdbalance字段。具体的测试操作就是在请求的数据包中把多出来的字段加入进去然后观察。

上面是请求的数据包，用burp截断返回数据包的方式看下返回的数据包

返回的金额变成了100.00。这个时候并不代表真的达到了数据污染的目的。然后去余额账户里面看一下。

点击刷新以后我们发现余额和总资产已经变成了100。后面我们重复了前面开始的操作同步平台上账户里面的钱到银行然后在通过平台成功提现100。

风险分析：常见的所有输入的地方都会出现这个漏洞，攻击者可利用该漏洞修改任意用户信息，篡改金额等。

风险等级：

【高危】

修复方案：建议从以下三个方面进行修复：

DTO

public class companyInfo {

private String xxx;

private String xxx;

     //private String companyName;

  

     //Getters & Setters

   }

白名单

@Controller

  public class companyInfoController

  {

     @InitBinder

     public void initBinder(WebDataBinder binder, WebRequest request)

     {

        binder.setAllowedFields(["xxx","xxx","xxx"]);

     }

 

     ...

  }

黑名单

@Controller

  public class companyInfoController

  {

     @InitBinder

     public void initBinder(WebDataBinder binder, WebRequest request)

     {

        binder.setDisallowedFields(["companyName"]);

     }

 

     ...

  }

注意事项：暂无