逻辑漏洞出现场景、利用方式总结

  • A+
所属分类:安全文章

文章来https://blog.csdn.net/weixin_46022050/article/details/104607097


1、前台模块

1、短信轰炸

  • 参数修改短信轰炸,可以直接修改手机号或者其他参数

  • Cookie短信轰炸

  • 根据业务的判断

2、手机号遍历枚举

  • 绕过风控继续遍历

  • 简单遍历结

绕过风控方法:修改下面参数,让其构成一个正常参数从而实现绕过

逻辑漏洞出现场景、利用方式总结

3、绕过验证

  • 删除参数,删除验证码参数导致验证码被绕过

  • 修改参数将验证码修改成0000,修改参数中的验证码导致逻辑错误绕过

  • 构造验证码key值原理

4、批量初测用户

  • 注册时数据包存在userid 代表一个新用户的诞生,将userid的数进行遍历,可批量注册用户

5、任意用户注册

  • 验证码爆破,验证码没有任何频繁拦截时进行简单爆破

  • 绕过验证码,修改验证码参数,删除参数

  • 返回包中的验证码直接显示


2、密码找回模块

1、短信验证码以及邮箱验证码

  • 修改参数

  • 删除参数

  • 爆破验证码

2、URL参数修改以及绕过步骤找回密码

  • 链接中的参数修改,链接中存在key=xxx以及code=xxx 分为有加密跟无加密的有些直接显示用户名修改直接就重置,有些显示为加密的值将值尝试是否可以组成而达成密码重置

  • 绕过步骤,URL中可能会存在每一个步骤的过程比如 find1 find2 find3 fin4等等,有些步骤会出现在post数据里面绕过,比如find1的时候直接将find1 改为find4 直接进行最后一步修改密码


3、登录模块

  • 任意用户登录,修改参数userid或者其他可疑的参数登录了其他用户的账号

  • 登录凭证劫持,可能在某些app中把用户的token丢在了url中,如果这条链接被利用跟第三方缺陷可能导致用户的token被劫持

  • 短信验证码

4、业务逻辑层模块

  • 个人中心
    url中的参数越权

    逻辑漏洞出现场景、利用方式总结

  • 购物与活动功能
    找到喜欢的商品,添加购物车,提交订单,支付订单,基本的流程是这样的,但是这三个流程可能会存在业务设计的缺陷,其他可以通过修改产品的数量,产品的实践,优惠券,产品的id,sku值等等

  • 修改金额

  • 商城活动
    抽奖、例如商品中的轮盘抽奖可以通过修改后抽中想要的产品

    逻辑漏洞出现场景、利用方式总结

  • 领取优惠券一些领取优惠券,可以通过修改一个用户领取多张


5、案例分享

1、逻辑支付

第一步,打开xx你会发现有一个骑手商城,点进去里面一个最贵的商品,然后支付,支付的时候抓包

逻辑漏洞出现场景、利用方式总结


2、找到最便宜的产品,点击购买抓包,然后将刚才那个数据包,全部内容,替换过去

逻辑漏洞出现场景、利用方式总结


点击提交会显示系统错误,重新支付,但是你多点几次,ok订单价格替换掉,支付价格也替换了

2、密码重置
输入一个正常要重置的手机号,然后抓包将数据包中的重置手机号替换成自己的手机号来接受短信验证码,在获取验证码后直接进入设置新密码
然后再填写的一个新密码的时候抓包,这里有显示一个重置的手机号,直接填写成要重置的手机号直接更换

6、漏洞思考组合拳

1、Self-xss+Csrf组合拳
在商城中我提交订单的同时会弹出一个信息框,这个信息框可以在提交的同时做出修改,将信息框要弹出的信息抓包修改成一句Javascript,存在一个self-xss,那么这个xss并不是毫无意义

逻辑漏洞出现场景、利用方式总结


逻辑漏洞出现场景、利用方式总结


简单的用bp生成的一个poc

逻辑漏洞出现场景、利用方式总结


受害者打开 链接后

逻辑漏洞出现场景、利用方式总结

2、逻辑漏洞组合拳
购买一件最便宜的商品,再创建一个高价值的订单,再将订单退货抓取一个数据包,价格参数中的oid修改为高价值的产品订单,那么在订单中就会把一个还未支付的订单给退款了

逻辑漏洞出现场景、利用方式总结


逻辑漏洞出现场景、利用方式总结


逻辑漏洞出现场景、利用方式总结


3、设计缺陷组合拳

因为系统设计的缺陷,可以修改imgurl参数中的链接,但是需要绕过,链接中必须存在白名单url

逻辑漏洞出现场景、利用方式总结

4、第三方登录

逻辑漏洞出现场景、利用方式总结

这里可以修改uri,构造自己payload

逻辑漏洞出现场景、利用方式总结

受害者访问构造的payload,登录了网站,这里就获取到了登录链接受害者所用的token了

逻辑漏洞出现场景、利用方式总结

此外总结了一些思路一 、针对业务处


  • 登录

1.短信轰炸/验证码安全问题/密码爆破/邮箱轰炸
2.SQL注入
3.撞库
4.抓包把password字段修改成空值发送
5.认证凭证替换/比如返回的数据包中包含账号,修改账号就能登陆其他账号
6.Cookie仿冒
7.修改返回包的相关数据,可能会登陆到其他的用户

  • 找回密码

1.短信邮箱轰炸/短信邮箱劫持
2.重置任意用户密码/验证码手机用户未统一验证
3.直接跳过验证步骤

  • 购买支付/充值(主要还是利用抓包需要仔细的去看每一个可用参数)

 
- 交易金额/数量修改,替换支付模块  (这里也就是更换了支付的模块金额)
- 交易信息订单编码/导致信息泄露
- 整数溢出,int最大值为2147483647,超过最大值
- 修改充值账户
- 支付绕过

  • 抽奖活动

 - 刷奖品/积分
- 并发

  • 订单信息

 - 订单信息遍历/泄露
- 订单信息泄露导致用户信息泄露
- 删除他人订单

  • 会员系统

1. 修改个人信息上传文件,上传带弹窗的html
2. 如遇上上传xlsx/docx,可能存在xxe,上传恶意的文档盲测
3. 图片上传也可能遇到imagereagick命令执行,上传恶意图片
4. 视频上传如果使用ffmpeg<3.2.4(视频按帧分割成图片),上传恶意avi盲测ssrf
5. 用户横向越权访问/遍历/导致用户信息泄露
6. SQL注入/个人简介处存储XSS 个人信息注册的名称也可以插入xss
 - 明文传输账号密码
- 修改信息处无session/token导致csrf
- POST/COOKIE注入

  • 评论

 - POST注入/存储XSS
- 无session/token导致CSRF

二、漏洞处

  • 验证码问题

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

  • 短信轰炸

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

  • 水平越权

 - 主要登陆后还是修改参数,主要找到多个接口不断测试
- 关注网页源代码,有时候会有表单,但是被bidden(隐藏标签)给隐藏起来了,可以修改返回包然后尝试获取数据检测
- 多个账号,主要分析请求参数

  • 数据泄露

 - 在找回密码处,填写数据后抓包查看返回信息,有可能存在敏感数据返回

  • 任意用户密码重置

1. 目前大部分都是在修改密码处参数修改
2. 有些是前端验证

三、支付逻辑漏洞

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信息,只要有足够的耐心和时间,就可以翻检足够多的数据,拼凑出户主的银行密码、私信等敏感数据。产生原因:数据在传输的两端是不加密的。一些数据如果在传输过程中不加密则会泄露个人数据等信息。


版权申明:内容来源网络,版权归原创者所有。除非无法确认,都会标明作者及出处,如有侵权烦请告知,我们会立即删除并致歉。谢谢!


原文始发于微信公众号(程序员阿甘):逻辑漏洞出现场景、利用方式总结

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: