业务逻辑漏洞总结

admin 2020年12月2日08:53:18评论27 views字数 2260阅读7分32秒阅读模式

前言


在平时学习安全中常常会有涉及到sql注入xss文件上传命令执行等等常规的漏洞,但是在如今的环境下,结合当前功能点的作用,虽然不在owasp top10 中提及到,但是往往会存在的,一般叫做逻辑漏洞


本篇文章是根据《web攻防业务安全实战指南》一书的知识进行简要的总结而成的笔记。


归类


逻辑漏洞主要产生的位置

  1. 登录处

  2. 业务办理处

  3. 验证码处

  4. 支付处

  5. 密码找回处


登录处存在的逻辑漏洞


可以暴力破解用户名或密码

没有验证码机制,没有根据用户名限制失败次数,没有根据ip限制失败次数等等


通常思路:

  1. 直接拿密码字典爆破某一个用户名

  2. 拿固定的弱口令密码,去跑top xxx的用户名

  3. 如果只是用户名限制失败次数,可以使用思路2的方法

  4. 在存在返回提示用户名错误或者密码错误的情况下,可以分别爆用户名和密码

常见限制:

  1. 有时候会发现用户名或者密码是密文加密,这时可能是通过前端或者其他方式加密,对于简单的来说base64编码和md5的签名是很好识破的,在爆破的时候可以选择encode和hash

session没有清空

登出后服务器端的session内容没有清除,因此客户端重新带回登出前的session,也能够达到重新登录


通常思路:

  1. 在登出后,拿登出前的session,重新访问需要登录的界面


业务办理处存在的逻辑漏洞


水平越权

通常说的越权一般是修改get或者post参数,导致的查看到他人的业务信息,一般看订单处,个人信息处等位置的参数


通常思路:

  1. 拿2个账号,修改账号1的get或post参数给账号2


篡改手机号

在需要手机号的短信验证处,抓包修改手机号,可能做到非本账号手机号获取能够编辑本账号的验证码


通常思路:

  1. 抓包,查看get或者post参数存在手机号的地方,进行修改


验证码处存在的逻辑漏洞


登录验证码未刷新

没有清空session中的验证码信息


通常思路:

  1. 抓包多次重放,看结果是否会返回验证码错误,如没有返回验证码错误则存在未刷新

  2. 观察检验的处理业务,如果验证码和用户名密码是分2次http请求校验,则也可以爆破用户名和验证码


手机或邮箱验证码可爆破

没有对应的手机号或邮箱,但如果验证码纯数字4,5位左右,没有次数校验,可以爆破


通常思路:

  1. 拿自己的手机号或邮箱先获取验证码查看验证码格式,之后多次提交错误的看是否有次数现在,没有就爆破


手机或邮箱验证码回显到客户端

在发送给手机或者邮箱验证码时,会在response包中有验证码,因此不需要手机和邮箱就可以获取验证码


通常思路:

  1. 发送验证码时抓包,看返回包


修改response包绕过判定

在输入错误的验证码时会返回false之类的字段,如果修改response中的falsetrue,会识别为验证通过

通常思路:

  1. 抓包,选择do intercept-> response to this request ,放包,抓到到下一个包就是response的包,可以修改,重放


支付处存在的逻辑漏洞


修改商品编号

如果业务是通过商品编号来判断价格的话,可能存在只修改A商品编号为B商品编号,做到以A商品的价格购买B商品


通常思路:

  1. 先准备2个商品的编号,将其中一个改为另一个


条件竞争

通过条件竞争使余额达到负数,从而买多个商品


通常思路:

  1. 支付处,多线程请求付款确认,结果如果余额为负数,则存在该漏洞


金额修改

金额直接写在了post或者get请求中,对其进行修改达到修改了商品金额的效果


通常思路:

  1. 抓包修改金额的字段


商品数量修改

在购买时,如果一个商品为负数,那么它的价格则会是负数,如果购买多种商品,将其中一个设为负数,降低整体的价格


通常思路:

  1. 购物车里选取多个商品,修改其中一个商品的数量,在购买后查看最终的价格


通过前端限制限购商品

有些商品限购1个,但是判定是通过前端,因此可以抓包后修改数量


通常思路:

  1. 抓取限购数量内的包,抓取后修改个数,重放


充值中放弃订单未失效

在充值中选取大额充值订单,放弃订单,获得订单号,之后充值小额订单,拿到充值成功的界面,将订单号修改为放弃的大额订单,观察是否成功


通常思路:

1. 看看充值的时候是否有订单号字段,如果有在成功界面修改为未支付的订单号,观察是否充值成功


密码找回处的逻辑漏洞


验证码处的逻辑漏洞在密码找回处存在一样适用
修改发送的验证的目标为攻击者的邮箱或手机

在找回密码处,如果字段带上用户名,校验的邮箱或者手机号,将邮箱或者手机号改为自己的,如果自己的能够收到验证码并重置密码,则该漏洞存在


通常思路:

  1. 抓包,注意找回密码流程中的邮箱号或者手机号字段,修改其为自己即可


session覆盖

已知A的手机号,不知B的手机号,找回A的密码,输入验证码后到了设置新密码设置界面。这时在同一浏览器下重开窗口找回B的密码,获取验证码,刷新A设置新密码的页面,如果此时修改的是B账号的密码,则存在漏洞


通常思路:

  1. 准备2个账号,测试步骤如上所述

  2. 在邮箱收到找回密码连接时,依然可以使用该思路


弱token爆破

有些时候通过找回密码的时候填邮箱,邮箱此时会收到一个带有token的链接,点击链接就能跳转到重置密码的页面,如果token是base64时间戳位数较低的随机数则可以爆破


通常思路:

  1. 正常找回流程获取重置密码的url,了解token的规则后,爆破其他邮箱的重置密码url


密码找回流程绕过

在找回密码处,一般会有三个步骤页面,页面1找回用户的填写,页面2找回时的手机号短信验证码填写,页面3填写新密码,如果填好页面1,直接访问页面3能够重设密码的话,则会存在该漏洞


通常思路:

  1. 在设置好找回用户后,直接访问重设密码的url页面


本文始发于微信公众号(渗透云笔记):业务逻辑漏洞总结

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2020年12月2日08:53:18
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   业务逻辑漏洞总结https://cn-sec.com/archives/194677.html

发表评论

匿名网友 填写信息