网络安全进阶学习第十七课——业务逻辑漏洞（支付&&认证&&密码找回）

---

一、支付漏洞

1、修改支付价格

– – 在支付当中，购买商品一般分为三步骤：订购、确认信息、付款。
– – 那么这个修改价格具体是修改哪一步时的价格呢？

• 在我看来，你可以在这三个步骤当中的随便一个步骤进行修改价格测试，如果前面两步有验证机制，那么你可在最后一步付款时进行抓包尝试修改金额，如果没有在最后一步做好检验，那么问题就会存在，其修改的金额值你可以尝试小数目或者尝试负数。

2、修改支付状态

– – 存在可修改订单状态的接口，比如确认收货接口，确认收货以后订单状态会变成“已完成”。

– – 例子：有如下接口/setorderstatus?orderid=1093&orderstatus=3，orderstatus=1待支付，orderstatus=2已支付， orderstatus=3已完成。利用上述接口，可直接将待支付的订单状态改成已支付。

3、修改购买数量

– – 例如：我购买两件价格一样的商品，购买数量都一样，其中一件数量不变，另一件数量改成负数，正样子合并付款时候就会互相抵消，价格就变成0。

4、修改附属值

当产品的价格无法修改的时候，我就尝试修改附属值的价值为负值来抵消总费用。

1. 修改优惠劵金额
2. 修改积分金额
3. 修改运费金额

5、修改支付接口

– – 比如一些网站支持很多种支付，比如自家的支付工具，第三方的支付工具，然后每个支付接口值不一样，如果逻辑设计不当，当我随便选择一个点击支付时进行抓包，然后修改其支付接口为一个不存在的接口，如果没做好不存在接口相关处理，那么此时就会支付成功。

6、多重替换支付

– – 首先去产生两个订单，这两个订单商品是不一样的，其价格不一样，如果服务端没有做好这相关的验证，那么在支付的过程当中抓包，修改其订单值为另一个订单值，最后支付，这时就可以用订单一的支付价格买到订单二的商品。

7、重复支付

– – 比如订单支付会返现，或者返积分。重复调用支付成功回调的接口，可实现多次返现，或多次返积分。

8、最小额支付

– – 这个问题如果你在充值时进行修改其支付金额为负数或者0.01等是会显示支付失败的，但是如果你修改其金额为1.00，那么支付就会成功。

– – 这里最低就是1元，1元对应100积分，而你如果修改为0.01，那么对应的积分就是空值了，所以会显示失败，而当你修改为1元，那么1元这个支付接口是存在的，其后面积分数为其它金额的积分数，然后跳转过去支付就会以1元购买到比它多得多的积分数量，也可以是任意积分值。

9、值为最大值支付问题

– – 一些网站比如你购买商品，这里有2个思路修改值，1是直接修改支付金额值为最大值，比如999999999，或者修改附属值，如优惠卷，积分等为999999999，如果这里逻辑设计有问题，那么其支付金额会变为0。

– – 或者利用整数溢出，将购买量改成99999999999999999999999999999999，这样支付金额可能会变成0。

10、越权支付

– – 现在可能很少存在这类问题，在支付当中会出现当前用户的ID，比如：username=XXXXX，如果没有加以验证，其支付也是一次性支付没有要求输入密码什么的机制，那么就可以修改这个用户ID为其它用户ID，达到用其他用户的账号进行支付你的商品。

11、无限制试用

– – 一些网站的一些商品，比如云系列产品支持试用，试用时期一般为7天或者30天，一个账户只能试用一次，试用期间不能再试用，但如果这个试用接口会做好分配那么很容易导致问题的发生。

– – 比如：在支付的时候它URL后面的支付接口是3，而试用接口是4，那么此时你已经使用过了，复制下确认试用时的URL，修改后面的支付接口为3，那么此时就会调用购买支付接口，但是由于你本身这个产品就是试用的，其相应值绑定了这个试用商品，那么金额就肯定是0，那么最后点击支付，你就可以看到支付成功，试用成功，又重复试用了一次，然后他们的试用时间会累加在一起，这就导致了可无限制购买任何产品了。

12、多线程并发

• 模拟一个场景：
  从网站去提现金钱

  • 正常请求：用户A在一个网站上提款，发送了提款请求，后台显示一条提款请求，审核了然后顺利提到了。
  • 并发请求：用户A在一个网站上提款，同步发送了多个提款请求，后台显示多条提款请求，审核了然后顺利的提到了几倍的bounty。

• 总的来说就是提现的请求一次性发送多个，让后台同时处理，这就达到了几倍提款的目的。

• 换另一种思路，正常在余额上进行提现的时候取消提现，这样子钱就会返回余额中。当我们尝试在取消提现操作上拦截了请求包，然后利用重放模块一次性重新发送多个的取消提现请求，服务器就会同时处理这些请求，利用这方法达到增加账户的余额。

---

二、验证安全

1、常见的验证码类型：

2、图形验证码绕过

1）图形验证码不刷新或无效

– – 手工尝试一次登录后，在某一时间段内无论登录失败多少次，只要不刷新页面 Session 不过期，就可以无限次的使用同一个验证码来对一个或多个用户帐号进行暴力猜解。

2）图形验证码值可直接获取

– – 验证码通常会被隐藏在网站的源码中或者在请求的 Cookie 中，或在 response 数据包中返回。

3）图形验证码参数绕过

登录请求包数据: user=admin&pass=1234&vcode=brln
可尝试如下两种绕过方法：

1. 验证码空值绕过，改成user=admin&pass=1234&vcode=
2. 直接删除验证码参数，改成 user=admin&pass=1234

登录请求包数据: user=admin&pass=1234&needcode=1&vcode=brln
可尝试将needcode参数的值改成0

4）存在无验证码页面

– – 经过测试，如果我们发现网站验证码自身并不存在缺陷，那我们接下来就可以尝试寻找一些其他的登录页面或接口来尝试暴力破解。如隐藏的页面、测试页面、老旧版本的页面等。

5）万能验证码

– – 渗透测试的过程中，有时候会出现这种情况，系统存在一个万能验证码，如0000、9999，只要输入万能验证码，就可以无视验证码进行暴力破解。这种万能验证码一般是开发人员测试时忘记删掉留下的。

6）验证码数量有限

– – 多见于计算类型的验证码，如 1+2=？，这种类型的验证码严格意义上来说不能叫做验证码，多刷新几次验证码，我们可能会发现系统中的算数题目只有那么几道，这种情况下只要将验证码全部下载下来，生成一个 md5 库，然后将前端生成的验证码与本地文件进行对比即可。

7）简单验证码识别

– – 在平常的漏洞挖掘过程中，如果我们发现登录的验证码非常简单且易于识别，那我们就可以尝试使用自动化工具来进行登录破解了，如 PKAV 的 HTTP Fuzzer、bp插件等。

8）验证码复用

– – 当你打开常见的一些需要登录之类的系统,通常系统会自动请求一次验证码,抓包,抓住别放,保持Session不变。

3、短信验证码绕过

1）短信验证码生命期限内可暴力枚举

– – 不多说，就是趁着验证码还没过期来进行暴力破解账号密码。

2）短信验证码在数据包中返回

3）修改请求数据包参数或 Cookie 值绕过

– – 比如有 post 数据包：mobile=18888888888&userid=00001, Cookie中有：codetype=1

– – 在特定步骤，修改 mobile=自己的手机号，自己手机就可以收到别人的验证码，后面再用别人的手机号和接收到的验证码登录；

– – 修改 Cookie 中可疑的参数和值，进行绕过，比如上面修改 codetype=0

4）修改返回包绕过

– – 举个简单的例子：提交错误的短信验证码，返回包中有： status=false，用 Burpsuite 的 “Do intercept” 功能来拦截响应包，修改响应包 status=true，即可绕过前端判断，成功进入系统。具体还要结合实际的场景，灵活操作。

5）攻破短信验证码接口

– – 相当于我再测试平安保险的，发现验证码接口时移动公司的，为了获取验证码就把移动公司给打了。

6）默认万能验证码

– – 之前遇到过短信验证码输入9999，就可以登录任意用户账号的漏洞。
为了方便测试以及维护，有的系统会留有万能验证码，上线后还保留着。可能是固定的写在配置文件、js文件或代码中，也可能是随时间变化的。

4、身份认证安全

1）暴力破解

– – 在没有验证码限制或者一次验证码可以多次使用的地方，使用已知用户对密码进行暴力破解或者用一个通用密码对用户进行暴力破解。
简单的验证码爆破。

2）session & cookie类

– – 会话固定攻击：利用服务器的session不变机制，借他人之手获得认证和授权，冒充他人。

– – Cookie仿冒：修改cookie中的某个参数可以登录其他用户（Chrome插件： EditThisCookie ）。

3）弱加密

– – 前端加密，可破解，或者根本就不是加密。

---

三、密码找回漏洞

1、密码找回逻辑测试一般流程

1. 首先尝试正常密码找回流程，选择不同找回方式，记录所有数据包
2. 分析数据包，找到敏感部分
3. 分析后台找回机制所采用的验证手段
4. 修改数据包验证推测

2、密码找回漏洞分类

1）验证码暴力破解

• 一般手机密码是6位纯数字，存活时间是十分钟以上的就可以尝试暴力破解。

2）验证码直接返回

• 服务器直接将验证码返回，例如某APP找回密码返回包。

3）跳过验证步骤

• 输入重置账号后，跳过验证步骤，直接访问重置密码页面。这时不必输入验证码，直接将链接中的 step2 改为 step3，如下图：

4）利用邮箱、手机号绑定

• 绑定用户邮箱的时候，可以通过修改uid将其他用户的邮箱绑定为自己的，从而任意重置用户密码。相当于是利用充值密码步骤，把受害者的绑定的手机改成我的，那么我就可以用我自己手机来登录别人的账号。

5）第三方登录绑定其他用户

• 例如：绑定微博账号的时候，先登录微博并且获取code，然后绑定code和UID的请求如下：
  • thirdPartyType=1&uid=60570181&state=test&code=fb3a6454736e15534486c5a214067943
• 通过修改uid可以将自己的微博绑定到其他用户账号，然后通过微博登录就可以登录任意用户账号。

6）没有验证验证码接受手机号是否与username或者session一致

• 例如发送验证码的请求如下：
  username=***&mobilePhone=***&randcodeAjax=6119
• 没有验证username是否和mobilePhone一致，通过修改mobilePhone为自己的手机号接受验证码。

7）本地验证绕过

• 客户端在本地进行验证码是否正确的判断，而该判断结果也可以在本地修改，最终导致欺骗客户端，误以为我们已经输入了正确的验证码。
• 例如将返回包中的0修改为1即可绕过验证。

8）重置密码最后一步uid或者username可控

• 重置密码最后一步，重置账户通过用户传递的uid或者username控制，导致修改该UID即可重置其他用户密码。

9）个人中心修改密码逻辑错误

• 当前密码的校验和修改新密码是单独分开的两个包。所以可以理解为没有校验当前密码。
• 修改密码的请求中如下：
  ssouid=***&passwd=***
• 修改该ssouid即可。

10）利用session重新绑定用户

• 重置密码最后一步是通过session获取用户名，然后再重置。
• 而用户名是在重置密码第一步时与session进行绑定；
  那么如果重置密码的最后一步程序并没有验证该用户是否走完了验证流程，那么就可以通过重新绑定session为其他账号，从而达到任意密码重置目的。

11）去掉验证参数绕过验证

• 邮件系统取回密码功能设计逻辑错误，存在认证绕过漏洞；
• 通过抓取数据包可通过修改报文，将找回问题答案参数删除后，直接进行对密码更改。也就是抓包，把包中验证码等验证字段去掉，再重新放包。

---