逻辑漏洞测试

账户相关逻辑漏洞

覆盖注册

漏洞原理：

一个手机号/邮箱/用户名已经注册了账号，但是由于漏洞，导致可以再利用该手机号进行注册，并且会将之前注册的记录覆盖

挖掘方法：

  1. 用已注册的账号再注册，提示该账号已经存在，抓包修改回传参数，把true修改为false，达到重复注册的目的
  2. 如果是低版本MySQL数据库，可以尝试往用户名/手机/邮箱后面加N个空格
登录认证绕过

漏洞原理：
一般来说用户在登录界面成功登陆后会跳转到主页面，但是如果缺乏正确的校验方式，攻击者可以通过多种手段绕过登录认证过程

挖掘方法：

  1. 直接访问登陆后的界面，一般登录成功后会跳转到主页面，如从login.jsp跳转到index.jsp。如果没有对跳转过程进行会话校验，可以通过直接访问index.jsp主页面绕过登录认证过程
  2. 有时候登录状态是通过前端验证返回包的登录状态码进行判断的，可以通过修改登录状态码进行登录。如对response包的body部分进行修改：{"state":0} 修改为{"state":1}

java代审

图形验证码绕过

挖掘方法：

  1. 图形验证码前端可获取
  2. 图形验证码可使用工具识别
  3. 图形验证码重复利用。有些图形验证码使用过一次之后，只要不访问刷新验证码的页面，就一直可以重复使用。开启burp随意截取一个登录页面的数据包，且一直截断登录包后面跟随的刷新验证码的数据包，多次重放登录数据包，可绕过图形验证码进行账号暴力破解
短信验证码绕过

挖掘方法：

  1. 万能验证码。有时候会出现系统留有测试阶段的挡板信息的情况，这是由于系统上线后没有及时清除测试阶段留下的信息，存在万能验证码，如888888，000000，123456
  2. 短信验证码可爆破
  3. 短信验证码前端回显
  4. 短信验证码未与用户绑定。如果手机短信验证码未与手机号绑定，那么就可以A用户的短信验证码B用户使用。通常验证手机号与验证码的请求包为{"telephone":"158XXXXXXXX", "code":"123456"}，使用自己的手机号获取到验证码后，把code修改为自己手机获取的验证码，telephone修改为其他用户的手机号，然后重放数据包
密码重置

挖掘方法：

  1. 邮箱重置密码链接token可伪造。一般这种情况的找回密码链接的用户标识比较明显，token可能够轻易伪造修改。如http://xxx.com/getbackpasswd.jsp?sendTime=MjAyMS0xMS0yMiAxNzozMw==&userName=YWRtaW4= ，可以通过修改userName去重置其他用户的密码
  2. token验证逻辑在前端。抓包修改response的校验结果可以绕过token校验
  3. 密码重置后新密码在返回包中。可通过抓包获取
  4. 重置密码有时会通过手机号发送验证码，利用短信验证码绕过的手段也可以达到任意账户密码重置的目的
密码修改

挖掘方法：

  1. 验证旧密码与修改新密码异步进行，且可以通过修改用户标识达到修改其他用户密码的目的。可通过使用自己注册的账号，首先输入自己账号的密码通过旧密码验证，如{"oldPassword":"123456","confirmPassword":"123456"}，在通过验证旧密码的流程后，在下一个修改密码的请求包中把修改密码的用户标识修改为其他用户：{"userName":"other_user","newPassword":"654321"}
  2. 流程跳跃。有些密码修改流程采用step=1、step=2类似的方式实现，如果应用校验不全面，攻击者可绕过前面的步骤，直接访问最后一步，输入新密码进行修改／重置
  3. 旧密码验证使用前端校验。直接抓包修改返回包控制校验结果，达到绕过校验的目的
  4. 密码修改有时候会发送修改密码链接到邮箱中，具体挖掘方法可参考密码重置的相关内容
  5. 密码修改与密码重置一样有时候也会使用手机号发送验证码，利用短信验证码绕过的手段也可以达到任意账户密码修改的目的

支付相关逻辑漏洞

交易金额修改

漏洞原理：
开发人员对于支付金额在后端没有做校验，数据传递过程中也没有做签名，导致攻击者可随意修改交易金额，甚至把金额修改为负数

挖掘方法：

  1. 修改商品价格。0元购（一般是虚拟货币，比如用金币、Q币支付），0.01元购（一般是RMB支付，因为银行卡每次转账的金额必须大于等于0.01）
  2. 金额数量大数溢出。int的范围是-2147483648～2147483647，可以看作一个循环，超过最大值后就会从0开始计算。当支付金额为2147483649时，支付金额就变成了1
  3. 有时候在修改支付价格的时候不行，就可以尝试修改一下运费，有些企业在做支付漏洞的防范时可能只着重了支付金额的逻辑，并没有对运费做相关限制
交易数量修改

漏洞原理：
开发人员没有对购买的数量参数进行严格的限制。这种同样是由于数量的参数没有做签名，导致可随意修改，经典的修改方式就是改成负数。当购买的数量是一个负数时，总额的算法仍然是”购买数量x单价=总价”。所以这样就会导致有一个负数的需支付金额。若支付成功，则可能导致购买到了一个负数数量的产品，也有可能返还相应的积分/金币到你的账户上

挖掘方法：

  1. 直接抓包修改商品的数量，有时候可能存在对整一个订单的金额有正数的校验，那就可以加入多个物品进入购物车，价格低的商品数量修改为负数，保证整个订单的价格为正数

image-20230716135822449

  1. 对商品数量的修改是最大数限制突破，比如特价商品限购1件，抓包修改成10件

交易时间修改

起始时间比截止时间晚

支付状态修改

漏洞原理：
造成该漏洞的原因是后端没有对支付状态的值跟实际订单支付状态进行校验，导致点击支付时抓包修改表示支付状态的参数为可以达到支付成功的目的

挖掘方法：
生成两个订单，A订单正常走一遍购买流程然后记住支付成功的状态值，然后用B订单生成时抓包修改状态值为购买成功的状态值

修改订单其他属性值

漏洞原理：
有些支付逻辑会对金额、数量等参数有严格限制，但是对于其他参数，如银行卡号码、用户标识等参数没有做校验，会导致越权支付

挖掘方法：
在支付的数据包中，把用户标志，或者银行卡号等关键参数，修改成其他用户的值

订单替换

漏洞原理：
由于服务端没有做好订单与订单信息之间的校验和绑定，通过订单编号替换的方式可造成使用低价成功下取高价订单的问题

挖掘方法：
订单替换发生在支付之后的事件处理，同时向服务器发起二次支付请求，比如一个订单50000元，一个订单5元，支付金额少的订单，支付之后抓包将5元的订单号改成50000元的订单号

请求重放

漏洞原理：
服务端没有及时更新订单状态，或者未对支付相关的数据包进行签名，导致可重放多次购买成功的数据包以达到重复下单的问题（优惠券领取使用同理）

挖掘方法：
多次重放支付成功的数据包

优惠券枚举

漏洞原理：
由于优惠券的ID是可遍历的或者可猜解的，单个用户领取优惠券的操作没有次数限制，且优惠券没有强绑定用户，在领取优惠券时可通过遍历优惠券ID达到优惠券枚举，刷取优惠券

挖掘方法：
抓取领取优惠券的数据包，然后遍历优惠券ID的参数值，领取多张优惠券

权限相关逻辑漏洞(权限绕过/越权)

水平越权
垂直越权
cookie伪造提权

漏洞原理：
cookie伪造攻击指攻击者通过修改cookie，获得用户未授权信息，进而盗用身份的过程，攻击者利用此漏洞可打开新账号或获取用户已存在账号的访问权限

高级利用：
jwt token伪造。有时候某些站点会使用jwt生成的token作为用户凭证。这时候可以通过jwt 的token伪造来获取其他用户的用户凭证

  1. 修改jwt算法为none
  2. 暴破密钥
  3. jwt签名算法未生效
未授权访问

漏洞原理：
未授权访问漏洞指在攻击者没有获取到登录权限或未授权的情况下，不需要输入密码即可通过直接输入网站控制台主页面地址进行访问，同时进行操作

挖掘方法：
可对登录后的页面进行抓包，将抓取到的功能链接，在其他浏览器打开。或者通过目录扫描工具进行扫描，爬虫得到相关地址链接，直接访问。如果未进行跳转到登录页面，则可判断为存在未授权访问漏洞

常见的未授权访问漏洞：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Redis 未授权访问漏洞
MongoDB 未授权访问漏洞
Jenkins 未授权访问漏洞
Memcached 未授权访问漏洞
JBOSS 未授权访问漏洞
VNC 未授权访问漏洞
Docker 未授权访问漏洞
ZooKeeper 未授权访问漏洞
Rsync 未授权访问漏洞
Atlassian Crowd 未授权访问漏洞
CouchDB 未授权访问漏洞
Elasticsearch 未授权访问漏洞
Hadoop 未授权访问漏洞
Jupyter Notebook 未授权访问漏洞

参考链接：https://xz.aliyun.com/t/6103

权限滥用攻击及防御案例: https://security.tencent.com/index.php/blog/msg/101

二次认证绕过漏洞

认证结果前端校验

漏洞原理：
有些系统对于二次认证的结果使用前端校验的手段，导致可以通过修改认证结果的参数绕过二次认证

挖掘方法：
首先正常过一遍流程，记录成功认证的参数值，然后注销退出，在二次认证的时候输出错误的验证码/令牌码，然后截取response，把认证结果修改为之前记录的认证成功的值

CSRF关闭二次验证功能

漏洞原理：
在使用CSRF攻击禁用二次验证功能时，防止CSRF的token令牌永远不会过期，或者甚至没有token。可结合钓鱼功能去禁用另一个帐户上的二次验证功能

挖掘方法：
注册两个帐户，登录到A帐户并捕获与禁用二次认证有关的请求，据此生成用于CSRF攻击的HTML页面，然后登录到B帐户并访问恶意页面，这样就可以在B用户不知情的情况下禁用了B账号的二次验证功能，从而成功绕过
参考链接：https://vbharad.medium.com/2-fa-bypass-via-csrf-attack-8f2f6a6e3871

敏感信息泄漏

oss accesskey

漏洞原理：
当采用JavaScript客户端直接签名时，AccessKeyID和AcessKeySecret会暴露在前端页面，存在严重的安全隐患

挖掘方法：
翻找js文件，检查js代码里是否泄露了AccessKey

image-20230716145435609

可通过API接口，通过调用API完成对服务器ECS实例的管理和运维操作；或者也可以通过行云管家直接导入AccessKey，可重置服务器密码，接管服务器

高级利用：
1、利用行云管家接管云主机
2、利用oss客户端或者api查看对象存储上的文件以查找敏感信息等

高并发相关漏洞

高并发提现

漏洞原理：
如果单纯的按照业务逻辑先查询余额再扣除余额进行提现，请求少的时候不会有问题。一旦出现高并发或者用户恶意提现，那么就可能导致多次提现但是余额只扣了很少。这是由于高并发环境下，操作同一个用户的资金，一个线程进入读取余额100，还没更新完余额100-20，另一个请求就进入读取余额100(正常应该是80)

挖掘方法：
截取扣除余额的数据包，然后使用burp的intruder或者fiddler，调高线程，多次快速得重放同一个扣除余额数据包

高并发领取金币、积分等

漏洞原理：
与高并发提现漏洞原因差不多，都是多个并发线程对同一个资源进行访问修改，可能会出现资源异常的问题

挖掘方法：
测试方法与高并发提现一样，都是使用burp或者fiddler调高线程多次快速重放领取金币/积分的数据包