【每天学习一点新知识】常见逻辑漏洞

目录

什么是逻辑漏洞？

1、越权漏洞

2、密码更改

3、密码找回

4、验证码漏洞

5、支付漏洞

6、投票/积分/抽奖

7、短信轰炸

SRC中的逻辑漏洞总结

---

什么是逻辑漏洞？

         逻辑漏洞是指攻击者利用业务/功能上的设计缺陷，获取敏感信息或破坏业务的完整性。一般出现在密码修改，确权访问，密码找回，交易支付金额等功能处。

​         逻辑漏洞的破坏方式并非是向程序添加破坏内容，而是利用逻辑处理不严密或者代码问题或固有不足，操作上并不影响程序的允许，在逻辑上是顺利执行的。

        ​ 这种漏洞一般防护手段或设备无法阻止，因为走的是合法流量也没有防御标准。

1、越权漏洞

该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得地权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。越权漏洞的成因主要时因为开发人员对数据进行增、删、改、查时对客户端请求的数据过分相信而遗漏了权限的判定，一但验证不充分，就容易出现越权漏洞

平行权限跨越

即攻击者能够执行与自己同级别的其他用户能够执行的操作

利用平行越权可能可以达到修改任意账户密码、获取任意账户信息等目的

看一些实战的例子：

平行越权漏洞挖掘-提高漏洞危害_Z.Pandaking的博客-CSDN博客_平行越权漏洞#前言学习web安全3个月，只会挖这个漏洞。。。在漏洞盒子和补天平台一共提交平行越 权漏洞超过50个。这是我写的第一篇文章，没什么技术含量，我自己感觉这些漏洞还比较有趣。大佬勿喷！我是菜鸡！一般的平行越权：具有越权增、删、改、查一项或者多项。以下展示的漏洞案例，可深入拥有被越权用户的所有权限严重可致任意账户密码修改。#只验证username 和 userid可致所有功能...https://blog.csdn.net/qq_44019154/article/details/102640484

垂直权限跨越

即攻击者能够执行更高级别的其他用户能够执行的操作

由于后台应用没有做权限控制，或仅仅在菜单，按钮上做了权限控制，导致了恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或者控制其他角色拥有的数据或页面，达到提权的目的

1. 通常先登录超级管理员，执行添加用户、删除用户等只有超级管理员有权限进行的操作。
2. 将相关操作的数据包进行抓包处理。
3. 退出超级管理员账号，并使用之前抓取的数据包进行只有超级管理员有权限进行的操作。(不可行）
4. 登陆普通管理员的账号，使用bp获取当前的登陆态，寻找到之前超级管理员添加用户的POST请求。将超级管理员的登陆态换成当前普通用户的登陆态，意为使用普通用户的登录状态来执行超级管理员的权限，刷新后发现用户列表已完成之前的操作，可见存在垂直越权漏洞。

垂直越权漏洞原理和测试流程案例_。北冥有鱼的博客-CSDN博客_垂直越权我们先把垂直越权漏洞的思路理一下首先我们先用一个超级管理员的账号去登陆一下然后我们对超级管理员的账号独一无二的权力去进行操作然后我们把这个操作的数据包给抓下来抓下来之后 我们就退出超级管理员的登陆，我们用普通账号，来进行一次这个超级操作如果这个操作可以成功，就意味着这个操作存在着垂直越权的漏洞我们来演示一遍首先超级管理员身份登陆进来以后我们可以看到，超级管理员可以添加删除用户...https://blog.csdn.net/weixin_43915842/article/details/90645378 

2、密码更改

如果后台没有对旧密码进行验证，就直接让输入新密码

1.如果存在csrf漏洞我们就可以直接修改一波

2.如果存在越权漏洞就可以直接修改其他人的密码

3.点击修改后抓包测试，观察数据包有没有验证类似cookie随机数，如果没有的话可以尝试修改用户名，手机号或者uid来尝试重置其他密码

​ 如果后台是通过向注册手机或者注册邮箱来重置密码的，关于验证码的漏洞我们都可以尝试，这种方式的前提是你已经通过某种方式进入到了对方的个人中心所以意义不大。
 

3、密码找回

攻击者通过密码找回逻辑漏洞，可以重置他人账号密码，危害他人账号安全。

其实属于是验证码的漏洞

1.验证码发送后前端返回

2.验证码时效导致验证码爆破

3.验证码有规律可控

4.验证码被放回在返回包中

5.输入验证码后通过修改响应包的状态来重置密码

6.验证码为空（原理就是后台未考虑验证码为空的情况，直接就是如果存在，然后下面仅判断了存在的情况）绕过或使用万能密码

7.拦截数据包，发送验证码时可以向多个手机号发送验证码，这个时候就可以添加个云短信，直接接受验证码完成修改

【逻辑漏洞】任意账号密码重置 - Carrypan - 博客园0x00 短信验证码回传 1、原理 通过手机找回密码，响应包中包含短信验证码 2、案例 某网站选择用手机找回密码： 点击发送按钮，拦截回包，可以查看到短信验证码，如下图所示： 3、修复建议 响应包中去https://www.cnblogs.com/peterpan0707007/p/8721094.html 

4、验证码漏洞

同上

5、支付漏洞

修改支付价格

支付三步曲——订购、订单、付款

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

修改支付状态

把未完成的订单号修改给已完成的订单 

修改订单数量

修改附属值（优惠劵）

优惠劵其基本都是优惠一半，一般用优惠劵进行消费一般出现在第二个步骤当中：确认购买信息，在这个步骤页面当中，你可以选择相关优惠劵，然后直接修改金额大于或等于商品的价格就可以，或者直接修改其为负值进行尝试，最后进行支付，如果对这点没有加以验证，那么问题就会产生，直接支付成功 

越权支付

例如：username=XXXXX，如果没有加以验证，其支付也是一次性支付没有要求输入密码什么的机制，那么就可以修改这个用户ID为其它用户ID，达到用其他用户的账号进行支付你的商品 

修改支付接口

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

多重替换

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

6、投票/积分/抽奖

投票和抽奖以及积分在很多促销活动或者推广手段上都经常用到，背后的奖品成本可能上数十万，如果这些奖品被恶意用户刷走了，不仅推广的效果没有，而且浪费了成本投入。

不管是投票、积分还是抽奖，都存在一个公共点：即单个用户次数存在限制，比如一场活动中一个用户只能抽奖一次。这样的限制也会存在很多绕过方式。

1.cookie和POST请求正文绕过

有的应用将验证是否抽奖或者领取积分的判断值放置在cookie或者POST的请求正文里，服务器端获取到这个结果后判断是否还有机会抽奖，而这个数据我们是可以直接在数据包中修改的，所以就会产生绕过，比如cookie中isok=1代表已经抽奖，isok=0代表还没有抽奖， 而我们只要再点击抽奖，然后把isok的值改为0即可一直抽奖。

2.基于IP验证

做的比较弱的统计是直接基于IP验证，像访问量、推广获取积分等，这类要看程序获取IP的方式，如果是client-ip或者x_forword_for获取IP，则可以直接伪造IP绕过。

3.基于用户认证

也有一部分应用需要登陆以后才能抽奖或者投票，这类可以结合看看能不能批量注册，如果可以，则可以用程序实现批量登陆刷票，或者投票的时候POST包或者cookie里面的当前uid\ 用户名等是否可以随意修改绕过用户单次限制。

7、短信轰炸

由于短信业务逻辑设计缺陷，没对短信发送次数做限制，导致可以大量重复发送短信验证码。该漏洞会对其他用户造成骚扰或使厂商的运营商短信费用的增加，造成损失。

逻辑漏洞之短信轰炸（原创） - FreeBuf网络安全行业门户本人在挖掘漏洞的过程中，遇到的逻辑漏洞还是比较多的，其中就有不少短信轰炸漏洞。今天就以我挖掘到的一些短信轰炸漏洞为例子，主要是分享一些思路，还请大佬们多多包涵。由于实际到真实厂商，对一些敏感信息进行了打码，大家伙看看思路即可。短信轰炸漏洞，顾名思义就是可以无限制地发送短信，原理由于短信业务逻辑设计缺陷，没对短信发送次数做限制，导致可以大量重复发送短信验证码。该漏洞会对其他用户造成骚扰或使厂商的运营https://www.freebuf.com/articles/web/288626.html 

 

SRC中的逻辑漏洞总结

附上链接：逻辑漏洞梳理与总结 - FreeBuf网络安全行业门户

1. 注册：
   1. 短信轰炸
   2. 验证码安全问题
   3. 密码爆破
   4. 邮箱轰炸
2. 用户任意注册、批量注册
3. 用户名枚举
4. XSS（有框的地方就可以尝试插XSS）
5. 登录：
   1. 短信轰炸、验证码安全问题、密码爆破、邮箱轰炸
   2. SQL注入
   3. 撞库
   4. 抓包把password字段修改为空值发送
   5. 认证凭证替换、比如返回的数据包中包含账号，修改账号就能登录到其他账号
   6. Cookie仿冒
   7. 修改返回包的相关数据，可能会登陆到其他的用户
6. 找回密码：
   1. 短信邮箱轰炸、短信邮箱劫持
   2. 重置任意用户账户密码、验证码手机用户未统一验证
   3. 直接跳过验证步骤
7. 购买支付、充值（要利用抓包去仔细查看每一个可用的参数）
   1. 交易金额、数量修改、更换支付模块（比如更换支付的模块金额）
   2. 交易信息订单编码/导致信息泄露
   3. 整数溢出，int最大值为2147483647，超过最大值
   4. 修改充值账户
   5. 支付绕过
8. 抽奖活动
   1. 刷奖品、积分
   2. 并发
9. 优惠卷、代金卷
   1. 并发逻辑漏洞（burp批量获取优惠券）
   2. 修改优惠券金额、数量
10. 订单信息
    1. 订单信息遍历、泄露
    2. 订单信息泄露导致用户信息泄露
    3. 删除他人订单
11. 会员系统
    1. 修改个人信息上传文件，上传带弹窗的html
    2. 如遇上上传xlsx、docx，可能存在XXE，上传恶意的文档盲测
    3. 图片上传也可能遇到imagereagick命令执行，上传恶意图片
    4. 视频上传如果使用ffmpeg<3.2.4（视频按帧分割成图片），上传恶意avi盲测ssrf
    5. 用户横向越权访问、遍历、导致用户信息泄露
    6. SQL注入、个人简历处存储XSS个人信息注册的名称也可以插入XSS

12.传输过程

1.  明文传输账户密码
2. 修改信息处无session/token导致csrf
3. POST/COOKIE注入

13.评论

1. POST注入
2. 存储型XSS
3. 无session/token导致CSRF

14.验证码问题

1. 万能验证码
2. 返回包中存在验证码
3. 删除验证码或者cookie中的值可以爆破账号密码

15.短信轰炸

1. 一直重放
2. 删除修改cookie，重放数据包
3. 遍历参数发送数据包
4. 手机号后面加空格或者前面加其他的比如+86或者逗号分号等，然后重发数据包
5. 请求参数修改大小写，或者添加请求参数比如&id=1
6. 一个站的登录处可能做了防护，但是再找回密码处可能没有安全防护，或者在注册流程中没有安全防护，所以说多测试接口
7. 如果对手机号一天的次数进行了限制，还可以再发一次短信，DO intercept之后修改为成功回显

16.水平越权

1. 主要登陆后还是修改参数，主要找到多个接口不断测试
2. 关注网页源代码，有时候会有表单，但被bidden（隐藏标签）给隐藏起来了，可以修改返回包然后尝试获取数据检测
3. 多个账号，主要分析请求参数
4. 数据泄露
   1. 再找回密码处，填写数据后抓包查看返回信息，有可能存在敏感数据返回
5. 任意用户密码重置
   1. 目前大部分都是在修改密码处参数修改
   2. 有些是前端验证

17.支付逻辑漏洞

1. 边界值问题 : 正常的逻辑是用户购买商品，然后价格累加得到一个总价进行扣款。这个时候就会产生逻辑问题：如果说用户购买的商品是负数了，那么计算的总数就是负数。反过来钱给用户
2. 顺序执行缺陷：正常的逻辑是a-b-c-d 循环渐进的进行流程操作。这个时候就会产生逻辑问题：可以直接从中绕过某一个过程进入到下一步操作。如果说有一项是支付的操作，那么也就会产生支付绕过，如果说有一项是验证机制，就会绕过验证直接进入下一步。
3. 金额直接传输导致篡改：直接对下单的金额进行修改值，这里可以使用fd或者burp抓包
4. 确定支付之后还可以加入购物车：把商品放入购物车点击下单支付，会跳转到微信，支付宝等第三方支付平台。这个时候还可以继续在购物车中加入商品，支付结束之后，商家发放的商品是现在的购物车里面的东西。
5. 请求重放：购买成功之后，继续重放请求，可以让购买的商品一直增加。购买成功之后，会有一个银行对商户网站跳转的过程，如果反复进行操作，有几率会导致商品反复购买和增加，但是不需要付更多的钱。
6. 请求参数干扰：金钱做了签名认证之后，修改后不通过，但是在里面仍然会有一个参数对金额产生影响导致问题产生。
7. 订单替换：订单替换发生在支付之后的事件处理，同时向服务器发起二次支付请求一个多一个少，支付金额少的，然后支付之后进行替换，告知服务器订单支付完成，并且过程可以反复的回放。
8. 欺诈:需要两个收款人，一个是正常的商家，一个是伪造的商家
9. 单位替换：产生在paypal类似的国际支付的场景。
10. 用户替换：在支付过程中发生用户替换现象，首先登陆自己的账户，然后取得另外一个人的账户名等有效信息，在业务流程中用对方的用户名替换自己的用户名，用对方的余额购买完成后，再替换自己的账户名，这样就形成别人的钱买自己的东西
11. 强制攻击：强制攻击发生在暴力破解的情况下，如果一个商家运用一个自己的网店，接入第三方支付接口，由于设计上的不当导致商家与第三方支付约定的密钥Key可以单独被MD5加密，导致可以使用MD5碰撞技术对密钥进行破解，攻击者可以设计简单的密钥加密信息使得MD5加密是可以用MD5碰撞技术进行暴力破解。
12. 秘钥泄漏：内置支付功能的app为了设计上的方便有可能会把Md5或者是RSA的私钥泄漏导致攻击者反编译apk之后获取密钥信息使得交易信息可以被篡改。
13. 函数修改：apk反编译之后的函数修改，可能导致商家在最后一步向支付方提交订单时未验证信息的准确性，仍然被篡改。
14. heart bleed：SSL（安全套接层）协议是使用最为普遍网站加密技术，而OpenSSL则是开源的 SSL 套件，为全球成千上万的web服务器所使用。Web服务器正是通过它来将密钥发送给访客然后在双方的连接之间对信息进行加密。URL中使用 https打头的连接都采用了SSL加密技术。在线购物、网银等活动均采用SSL技术来防止窃密及避免中间人攻击。

该漏洞被归为缓冲过度读取。缓冲过度读取错误是软件可以读取比应该被允许还多的数据。漏洞让特定版本的openSSL成为无需钥匙即可开启的“废锁”，入侵者每次可以翻检户主的64K信息，只要有足够的耐心和时间，就可以翻检足够多的数据，拼凑出户主的银行密码、私信等敏感数据。产生原因：数据在传输的两端是不加密的。一些数据如果在传输过程中不加密则会泄露个人数据等信息。

1. 修改返回包的越权
   1. 修改手机号

一般的逻辑为：认证原手机号-> 填写新手机号-> 提交修改

如果在下一步操作时，没有校验上一步的认证是否成功时，就会存在逻辑缺陷绕过

比如在进行第一步认证原手机号时，随意输入验证码，将response包中的相关字段进行修改，比如0改成1，false改成true，即可绕过第一步验证，进入填写新手机号界面，如果第三步提交修改时没有验证第一步的结果，就会造成逻辑漏洞

1. 登录绕过

部分网站的身份验证放在了前端，因此只需要将response包中的相关字段进行修改，比如0改成1，false改成true，就可以登录任意用户账号

1. 水平越权
   1. 遍历ID

在一些请求中，GET和POST中有明显的ID数字参数（手机号、员工号、账单号、银行卡号、订单号等等），可以尝试进行遍历，如果程序没有对当前权限进行判断，就会存在水平越权问题

1. ID替换

如果程序对用户标识进行了hash或者加密，而无法破解用的什么方式的话，就无法通过遍历ID来获取其它用户的信息了，此时可以尝试注册两个账号，通过替换两个ID加密后的值，判断程序是否对权限进行了验证，如果没有，也会存在越权问题

1. 垂直越权

观察cookie中的session字段，可能某些字段或者参数代表身份，尝试修改