渗透测试之Web应用业务逻辑测试

介绍：这里对Web应用业务逻辑方面的安全缺陷进行介绍和常见案例讲解。

任意用户密码重置

常见的缺陷

* 1.验证码类缺陷

• 场景：

1.1 验证码回显在客户端(响应主体、Set-Cookie等等...)。

1.2 验证码过于简易时效性过长，接口未做限制(一般为纯数字4-8位数，时效性长达30分钟以上可以对验证码进行枚举)。

* 2.未校验权限/前端校验/越权

• 场景：

2.1 任意手机号验证码都可重置任意账号。

2.2 修改响应包的主体(根据实际情况来修改 例如验证请求对应的响应报文的主体为false 你可以修改为true)。

2.3 同一浏览器进入A用户的重置，然后关闭再进入B用户的重置 而实际上重置A用户。

2.4 修改重置密码的相关参数(例如 userid等等...)。

* 3.HOST头伪造

• 场景：

3.1 在邮箱找回密码的时候，可以简单替换Host部分进行Fuzz，看看找回密码的链接中的域名是否是根据Host来生成的如果是可以替换成自己的域名。但是这种思路很鸡肋，因为需要用户的点击，这样才可以根据日志看到重置密码的链接，万一重置密码的链接时效性过去就无奈了。

* 4.找回密码的凭证脆弱

• 场景：

4.1 见过最多的是找回密码的token是base64编码的，而解码后的明文根据其规则修改就可以成为别人用户找回密码的凭证了。

验证码绕过

常见的缺陷

图形类验证码绕过

* 1.图形验证码可复用

• 场景：

3.1 验证码刷新之后，而历史刷新的验证码还是可以继续使用。

3.2 验证码使用过后不刷新，时效性不过期，可以一直复用。

* 2.图形验证码易识别

• 场景

4.1 很多验证码的显示很简单，容易被机器识别。

短信类验证码绕过

* 1.验证码过于简易&接口未限制

• 场景：

1.1 有些手机短信验证码都为 4-8位 纯数字的验证码，在接口没有任何限制的情况下是可以直接爆破的。

* 2.验证码发送复用&时效性过长&接口未限制

• 场景：

2.1 6位数验证码时效性为5分钟，但是在这里同一手机号发送的验证码都是一样的，所以可以在4分钟的时候重新发送一次验证码这样验证码就又有效了，因为验证码一直在被复用，所以可以爆破。

* 3.万能验证码

• 场景：

3.1 这是很多大企业的诟病，在未上线前为了方便测试加了888888、000000这样的万能验证码但是上线后没去删除测试的内容导致被恶意利用。

短信/语音验证码重放

无论是发送短信还是语音验证码来做验证，都是需要手机号的，而发送验证码实际上是需要成本的，需要跟运营商或者是第三方验证码平台进行合作，多数验证码为0.01元一条，当然也有更便宜的，所以这边的问题也会影响到一个企业的资产方面。

常见缺陷

* 1.无限制发送

• 场景：

1.1 厂商对验证码发送这一块并没有进行限制时间发送

* 2.代码层逻辑校验问题

• 场景：

2.1 很多厂商会对手机号进行限制，如果60秒内发送过就不会发送，但是程序员在设计代码层的逻辑时会出现很多奇葩的问题，例如其为了方便用户体验，正常的代码层的流程为：

a.去除用户手误输入的空格以及一些特殊符号

b.验证手机号是否发送过验证码

某些程序员会这样设计流程：

a.验证手机号是否发送过验证码（发送过则不放行 没发送过则进入下一步）

b.去除用户手误输入的空格以及一些特殊符号

c.发送手机号验证码

* 3.手机号可遍历发送

• 场景：

3.1 我之前有提到验证码发送会影响到企业资产，那么发送验证码限制就不能仅仅针对于单一手机号的限制，例如我可以载入一堆手机号的字典，然后直接遍历发送验证码，这也是危害之一。

业务流程绕过

常见缺陷

* 1.无验证步骤跳跃

• 场景：

1.1 出现的场景很多：密码重置步骤、支付步骤，对于这种的测试方法有很多中：

a.对比法，使用A、B两个账号，A账号先正常走一遍流程，然后记录流程的请求报文跟响应报文，使用B账号来测试是否能绕过直接进入最后一步骤。

b.第六感，假设步骤1的网址为:http://www.test.com/step1，这时候你可以凭借你的第六感修改下链接为/step2之类的来测试。

加密算法脆弱

常见缺陷

* 1.前端呈现加密算法代码

• 场景：

1.1 很多厂商算法写的很好，可没用，因为他用的是JS代码，在前端会直接能看见，而尝试跟踪JS的代码就会知道是怎么加密的从而可以直接绕过。

* 2.算法脆弱，明文可判断

• 场景：

2.1 这是一个看运气的问题，一段密文为md5的，这时候你要做好自己的分析明文到底是什么，然后去碰撞，例如可能是md5(用户名+邮箱)这样的的组合。

支付逻辑漏洞

常见缺陷

* 1.金额修改

• 场景：

1.1 支付的过程中有很多涉及金额的元素可以修改运费、优惠价、折扣等，可以修改为负数金额也可以修改金额为小于原金额的数进行测试，有时候会遇到溢出，你修改金额为较大的数看你会出现只支付1元的情况。

* 2.数量修改

• 场景：

2.1 修改购买物品的数量为小数或者负数，同上，有时候会遇到溢出，你修改数量为较大的数看你会出现只支付1元的情况。

* 3.sign值可逆

• 场景：

3.1 这是一个看运气的问题，sign多数为对比确认金额的一段内容，很多都是md5加密的，这时候你要做好自己的分析明文到底是什么，然后去碰撞，例如可能是md5(订单号+金额)这样的的组合，然后修改金额重新生成sign就可以绕过金额固定的限制了。

条件竞争(HTTP并发)

常见缺陷

* 1.条件竞争（HTTP并发）

• 场景：

1.1 在签到、转账、兑换、购买等场景是最容易出现这样的问题，而并发测试的方法可以使用Fiddler也可以使用BurpSuite Intruder模块。

这里例举下Fiddler测试方法（BurpSuite测试很简单就不说明了）