短信发送/支付/密码重置逻辑漏洞学习

————

web漏洞产生的原因
通过输入提交特殊数据，特殊数据在数据量的每个单元里处理，如果某个单元没处理好，在单元输出的时候，就会出现相应单元的安全问题。

——

什么是逻辑漏洞

防火墙、WAF 是无法挖掘逻辑漏洞的。因为逻辑漏洞是通过合法的方式来达到破坏的，与传统漏洞不同（如ssrf、RCE 等）。比如密码找回，用户登录验证等功能由于程序设计的不足，产生了很多问题，这一类漏洞一般的防护手段或者设备无法阻止，漏洞扫描器也难以发现。

逻辑漏洞是因为程序员在编写程序的时候，跟随着人的思维逻辑产生的不足。

——

产生原因

程序逻辑不严或逻辑太复杂，导致一些逻辑分支不能正常处理或处理错误，一般出现在任意密码修改（没有旧密码验证）、越权访问、密码找回、交易支付金额、身份证认证、实名认证等。

——

逻辑漏洞场景

逻辑漏洞应用场景：逻辑漏洞的挖掘，大部分出现在我们的互联网等大企业上面，特别是业务越多，逻辑混乱的可能性就越大。

与传统漏洞的挖掘不同，逻辑漏洞需要更多的是细心、对业务的熟悉，以及知识面的场景。
逻辑漏洞里面最经典的一句话：挖不到漏洞怎么办，那就瞎想，瞎试。

除了常规的思路，还有更多的就是自己对于业务的思考，逻辑漏洞更多的使用范围是大型的互联网公司项目。

逻辑漏洞并未违反网站的某些操作，只是利用了其规则，获取原本无法得到的验证码。

下面举三种逻辑漏洞，存在于我们日常的使用功能中。不过现在的页面这些漏洞当然已经被修复了，这里只是对其原理进行一些学习。

——
——

一、短信发送漏洞

什么是短信轰炸？
厂商在对信息发送的次数、时间没有做限制，或者只在前端做了限制，导致可以无限制发送信息，简单地说就是发送短信/邮件的包可以无限制地发送。

所谓限制，在我们正常的使用中就会遇到，比如修改密码发送完验证码后，按钮的位置会出现倒计时：60~ 59 ~ 58 ~
这个就是限制的一种—时间的限制。

短信轰炸漏洞产生的位置

登录
注册
找回密码
绑定手机/邮箱
修改信息
免费试用/活动领取/独特功能/反馈处
……
一切需要验证的位置。

简单绕过限制的思路
1、尝试在 mobile 参数后面加 %20（即空格）

2、尝试在 mobile 参数后面加字母等

3、尝试对参数进行多次叠加
比如此处重复叠加可能能达到多次请求的效果。

4、利用调用接口绕过短信&邮箱发送限制。
比如一个网站有登录/注册等多个页面，每个页面对于我们用户是不同的接口，或许可以修改接口的信息，让注册的接口成为登录的接口。

5、修改 Cookie 值绕过短信&邮箱发送限制。

6、修改 IP 绕过短信&邮箱发送限制。

7、利用大小写绕过邮箱发送限制。

8、修改返回值绕过短信&邮箱发送限制。

——
——

二、支付逻辑漏洞

背景
随着互联网的发展，生活变得越来越方便，如今只要在网上下个订单就可以送到家中。网上购物带来极大的便利的同时也带来了安全风险，而支付漏洞就是影响我们网上购物的安全风险之一。

产生原因
开发人员往往会为了方便，直接在支付的关键步骤数据包中直接传递需要支付的金额。
而这个金额后端没有进行校验，传递过程中也没有进行签名，导致可以随意修改金额再提交。
修改步骤只需抓包找到金额的参数进行修改即可。

场景举例

1、修改购买数量
在进行支付订单的时候，可以修改物品的数量来进行操作，可以通过支付一件的价格去购买多件，或者把数量改为负数而导致资金增加。

2、修改支付价格
抓包修改价格参数的内容。
在购买商品一般分为三个步骤：点击购买、确认信息、付款，这三个步骤中都可能存在漏洞，都可能可以修改金额大小。

3、修改支付对应的商品
不同的商品可能对应不同的 id 号，在数据包中可以发现每个商品不同的地方，而找到商品 id 号。
如果修改商品对应的 id 号，可以用低价购买高价格的商品。

4、修改支付的状态
没有对支付状态的值与实际订单支付状态进行校验，导致点击支付试抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功。

5、修改附属优惠/状态
修改优惠卷金额
修改积分金额
无限制使用
修改优惠价
一些商品在购买时，会有优惠选项，那么在支付时抓包，修改这个优惠价就可以造成支付问题的产生。

6、测试数据包未删除
开发在进行测试的时候有一些数据未删除，导致用户可以购买测试数据，或者领取测试的优惠券。

——
——

三、密码重置逻辑漏洞

原理
厂商在对密码修改的时候，未对修改密码的凭证做严格的限制，导致可以被绕过进行任意的密码修改。

漏洞场景

验证码课爆破
验证码回传
验证码未绑定用户
本地验证绕过
跳过验证步骤
凭证可预测
同时向多个账号发送凭证

在进行密码重置的时候，一般是直接发送手机验证码，有的地方验证码为四位，可能可以直接用 burp 爆破出来。

不过，现在的验证机制都已经有很多限制了。
如：

服务端对验证时间次数限制。
验证码有效期时间的限制。
验证码位数加多而变得更复杂（六位）。

可能存在的案例分析
1、
输入手机号和验证码进行重置密码时，仅对验证码是否正确进行了判断，未对验证码是否与手机号匹配做验证。
那就可以用 A 手机号获取的验证码，放在 B 手机号进行密码重置验证框内。
修复
在服务器进行有效验证，手机号和验证码在服务器进行唯一性绑定验证。
在服务端限制验证码发送周期，设置时效，限制时长和次数。

2、
本地验证绕过：客户端在进行本地进行验证码是否正确的判断，而判断结果也可以在本地进行修改，最终达到欺骗客户端，误以为已经输入了正确的验证码场景：
验证码返回在前台进行比对
验证码在 js 里面直接进行对比
验证码的账号由客户端决定

3、
跳过验证步骤
在对修改密码的步骤，没有做校验，导致可以输入最终修改密码的网址，直接跳转到该页面，然后输入新密码达到重置密码的目的。
重置密码可能存在的几个步骤：

了解每个页面的链接格式，当重置另一个账号密码时，直接进入到对应的链接而达到验证步骤的跳过。

4、
token可预测：使用邮件接收重置密码的链接时，一般会有一个 token 用于判断链接是否被攻击过。如果 token 可预测，那么攻击者可以通过构造链接来重置用户密码。
表现：
基于时间戳生成的 token 。
基于递增序号生成的 token 。
基于关键字段生成的 token 。
token 有规律。

5、
同时向多个账户发送凭证：就像前面的短信发送漏洞一样，将发送验证码的包截获，修改字段添加多个账户，再进行发包
发现所写的有效字段均发送了凭证。