逻辑漏洞密码简单爆破、user_token验证爆破和修改商品单价

渗透学习

逻辑漏洞问题

---

---

前言

本系列用于记录本人渗透学习的过程，主要内容围绕Owasp TOP 10展开。

逻辑漏洞问题将会用实验案例的形式演示验证机制问题-暴力破解和业务逻辑问题-支付逻辑，以了解逻辑漏洞方面的安全威胁。

本文只做学习用途，严禁利用本文提到的技术进行非法攻击，否则后果自负，本人不承担任何责任。

一、逻辑漏洞

相比较于SQL注入、XSS漏洞等传统安全漏洞，SQL注入，XSS等漏洞可以通过安全框架等避免，并且攻击流量非法，对原始程序进行了破坏，防火墙可以检测；所以现在的攻击者更倾向于利用业务逻辑层的应用安全问题，逻辑漏洞就是指攻击者利用业务的设计缺陷，获取敏感信息或破坏业务的完整性。

逻辑漏洞分类：
1.验证机制缺陷
2.会话管理缺陷
3.权限控制缺陷
4.业务逻辑缺陷

1.验证机制缺陷

身份验证是核心防御机制中最薄弱的环节，通常表现在弱口令、暴力破解（绕过验证码）、密码重置和找回密码等地方，由于设计者未添加适当的限制，导致攻击者可以利用此缺陷。

暴力破解绕过验证码案例：
用BurpSuite抓包查看其中isVerfi参数，第一次传入1返回3没有得到验证码，但修改参数为0之后返回2，绕过了验证码的限制

常见密码重置问题：
1.用户名枚举：网站反馈多余信息，可猜测用户信息
2.验证码返回前端处理：可截获、修改
3.修改Request：用户名、手机号、Cookie等信息可修改
4.修改Reaponse：操作结果成功/失败可修改
（返回包中具有明显的参数字段，如yes/no，success/failed，0/1等字段。也可以尝试修改成功，或走一遍正常的流程，记录成功的返回包）
5.暴力破解验证码：验证码长度有限，或验证码未设置可靠的失效时间
6.拼凑密码重置链接：重置密码链接有规可循

2.会话管理缺陷

用cookie、session和token等方法维持用户的会话状态（令牌）

令牌存在令牌有含义、令牌可预测、令牌可获取和令牌不失效几大问题

令牌有含义：有些系统会有意设置具有含义的令牌字符
令牌可预测：令牌是有序的字符串（有含义的编号，Unix时间戳）
令牌可获取：令牌在URL里明文传输，URL链接分享时会分享自己的会话。或者将令牌存储在日志文件或其他配置文件中，发生未授权信息访问时泄露
令牌不失效：令牌有效期过长（如cookie的expires属性值），令牌尝试次数过多（同一令牌提交次数），无效的令牌重置的手段

3.权限控制缺陷

从控制力度上来看，权限管理可分为：
1.功能级权限管理
2.数据级权限管理
从控制方向上来看，权限管理可分为：
1.从系统获取数据，比如查询订单、查询客户资料
2.向系统提交数据，比如删除订单、修改客户资料

未授权访问指当客户系统的安全配置或权限认证的地址、授权页面存在缺陷时，有可能出现未授权访问，导致用户可以访问信息系统1，进而操作重要权限、操作数据库、读取网站目录等敏感信息
如：Google-Hacking、域名爆破、端口服务扫描、域名关联

案例：Jenkins未授权访问
Jenjins是一个开源软件项目，是基于Java开发的一种持续集成工具，它能帮你把软件开发过程形成工作流。默认情况下Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令，攻击者可通过未授权访问漏洞或者暴力破解用户密码等进脚本执行界面，从而获取服务器权限。

在Jenkin1.62版本中，将全局授权策略打开，即任意用户可以做任何事，存在未授权访问的问题

越权操作分为水平越权与垂直越权，水平越权指攻击者尝试访问与其具有相同级别的用户资源；垂直越权指攻击者具有低级别权限尝试访问高级别用户的资源

4.业务逻辑缺陷

业务逻辑漏洞只出现在业务流程中（模块功能），其内容包括：
1.领域实体：定义了业务中的对象，对象有属性和行为
2.业务规则：定义了需要完成一个动作，必须满足的条件
3.数据完整性：某些数据不可少
4.工作流：定义了领域实体之间的交互关系
以用户网购衣服为例：
领域实体：用户、资金账户、订单、衣服、发货单
业务规则：用户点击购买就会生成订单，但必须付了钱才会发货，生成发货单
数据完整性：网购必须登录网购平台账号，，没有账号就不能成功购买
工作流：搜索衣服——找到合适衣服——下单购买——付款——收货

业务逻辑问题包括支付逻辑漏洞和其他业务逻辑问题。

支付逻辑漏洞是指系统的支付流程中存在业务逻辑层面的漏洞，一般在电子商务网站上容易出现，在支付流程中由于没有对客户端请求数据中的金额、数量等敏感信息作校验，带来“0元购”、“1分购”等漏洞，会对商家带来大量经济损失。（支付过程中修改支付金额、支付过程中修改商品数量、支付过程中修改商品编号）

其他业务逻辑问题有API逻辑漏洞（参数校验，短信，邮箱炸弹，关键参数不加密），客户端与API通信无加密（未加密风险：凭据、传输数据公开、资源信息泄露，中间人攻击）和客户端与API通信无身份验证（信息泄露，应用程序被克隆，难以应对大规模拒绝服务攻击）。

二、实验步骤

1.验证机制之暴力破解用户名密码

该实验将介绍使用字典暴力破解绕过登录验证

实验原理：登录页面在设置用户名和密码的时候，没有遵循密码设置规则，借助字典利用穷举法将所有可能的用户名和密码一一尝试，进行蛮力攻击，最后暴力破解出用户名和密码，绕过验证机制。

实验步骤：
随便输入用户名为：“root”，密码为“123456”提交

登陆失败

还是用户名为：“root”，密码为“123456”提交，用BurpSuite抓包

选择“Send to Intruder”，将数据包发送到暴力破解模块，攻击模式选择集束炸弹模式

切换到“Payloads”，设置攻击载荷。设置攻击位置1的payload类型为"Simple list"，并加载用户名字典

同理，设置攻击位置2的payload类型为"Simple list"，并加载密码字典
，点击开始爆破。

通过length筛选出爆破到的结果

进阶user-token攻击：
使用DVWA靶场高级难度：

先输入用户名密码测试，发现有一个user_token：

第二次测试时表单中多了上一次的user_token，因为此次提交中的user_token和表单中存在的user_token不匹配，因此及时账号密码正确也无法通过

因此在爆破时需要提取user_token，先把表单发到Intruder模块

将攻击模式换成草叉模式，清除原来的爆破位置并改为以下位置

首先设置第一个位置，payload类型为Custom iterator（自定义迭代器）

配置三个占位，第一个占位为用户名集合（此处已知用户名和密码，仅加入少量密码集加快结果出现）

第二个占位固定为&password=

第三个占位为密码集：

在Payload Encoding处，禁用对=和&进行URL编码

然后设置第二个位置，payload type为Recursive grep(递归提取）

在Option的request engine处将线程数设置为1

在Grep-Extract处设置递归提取的内容（加载repense的数据将user_taken设为提取内容，上方开头和结尾会在选中后自动生成）

将redirections设为always

回到payload，将第一个user_token复制到指定位置，然后开始攻击

爆破成功

2.业务逻辑问题-支付逻辑之修改商品单价

在系统的支付流程中由于服务器端没有对客户端请求数据中金额、单价、数量等敏感信息做校验，造成商家的经济损失，导致产生支付逻辑漏洞。

实验场景：

选择购买数量，用BurpSuite抓包

把数据包中的bill1和bill2修改为0，实现0元购

---

总结

以上介绍了逻辑漏洞问题的验证机制问题-暴力破解和业务逻辑问题-支付逻辑，其中暴力破解还演示了遇到user_token验证的场景时如何巧妙的利用BurpSuite继续完成爆破，逻辑漏洞问题相比与SQL注入和XSS攻击之类的漏洞更难防范，值得关注。