11-逻辑漏洞实战

1、身份验证漏洞

1.1 爆破-验证码爆破试验

使用bp或pkav工具，爆破织梦后台登陆系统

1.2 爆破-IP封锁和密码错误次数

1.2.1 未限制爆破

即对于用户登陆的地方没有做什么限制爆破的策略
可以直接用bp抓包放进intruder模块爆破，参考dvwalow关卡，后者pikachu基于表单的暴力破解

1.2.2 限制IP爆破

针对这种情况，建议自己写脚本，调用git开源的的代理API来爆破，当然也可以直接用别人的轮子

自建轮子方法：首先需要新建一个代理池：现在好用的一般是收费版本，然后使用python调用代理池进行爆破

import requests
import re

def post():
    curl = "http://192.168.1.157/dede/dede/login.php"#织梦后台
    proxy = {'http':'127.0.0.1:8080'}#设置代理池
    header = {'User-Agent':'Mozilla...头'}
    post = requests.get(curl,headerss=header,proxies=proxy).text#请求报文
    print(post)


if __name__ === '__main__':
    post()

什么是代理！相当于先发包给中间人，中间人发包给服务器，再回包
所以可以从代理池中，每次抽取不同IP，从而绕过IP封锁

1.2.3 限制密码错误次数爆破

对于这种情况，通常可以采用弱密码反过来爆破账户的方式，即设置任意不超过爆破次数的弱密码数量，来反过来爆破用户名

1.3 多字段爆破(token爆破)

多字段爆破即需要爆破多个字段大于等于2，比如说：需要同时爆破：账号密码验证码、验证token、cookie或者session

1.3.1 案例(pikachu的token爆破)

选择Pitchfork交叉爆破
爆破的时候，第二个表单，要从返回包中找到token，选择options-Grep-Extract

可以看到第一个token我们得自己输入

并且必须设置单线程，可以使用多进程单线程！

1.3.2 限制登陆频率爆破

比如10分钟内中运行爆破10次，对于这种方式可以采用延时爆破的方式，但是可能需要时间比较久(1000ms=1s)

1.4 密文爆破

比如tomcat的密码在传输的时候，是采用base64编码的，而广义上可以泛指经过编码过后的用户名与密码，下面我们以tomcat的basic爆破举例：

环境采用Kali：vulhub-master/tomcat/tomcat8 #路径
docker-compose up -d #开启环境
http://yourIP:8080/host-manager/html #后台URL

1.4.1 Authorization爆破


账号:密码

选择自定义列表，并且在第二个列表定义为':'

设置编码

发现状态码401，说明网站可能开启了，限制错误次数！

1.4.2 密文传输爆破

首先右键检查，找到输入密码的名字name字段(如：txt_password)
搜索哪些JS代码与txt_password有关，复制出来并查看加密逻辑

1.5 未授权漏洞(cookie和session)

1.5.1 Session固定攻击（未授权）

1.5.2 Cookie欺骗漏洞

1.6 未进行登陆凭证验证

用御剑等扫描工具，发现如main.php页面/admin/main.php未授权登陆了

2、登录验证码安全（图形验证码）

对于简单的图形验证码，验证码可爆破，字符数量少且没干扰

可以使用pkav进行爆破，先用BP抓包，再将抓取的数据包放在pkav

2.1 验证码绕过

验证码绕过，即验证码可以通过逻辑漏洞被绕过，通常分为以下情况

  • 案例一：验证码验证返回状态值
    可BP修改状态值来绕过前端的验证，前提是前端会验证后端传来的Y/N的验证码状态（先抓一个正确的，再抓一个错误的，修改status和url）

  • 案例二：点击获取验证码时，直接在返回包中返回验证码，通过抓包来观察response包（打开拦截，右键拦截response回包）

2.2 客户端验证

之前是，客户端发送报文到服务端，服务端返回一个Y/N，前端来决定过不过。
现在是，客户端在本地进行验证，没有通过服务端，验证码从生成到验证，全部由前端进行。

2.2.1 实例（pikachu靶场）

pikachu验证码绕过(on client)

输入错误的验证码，进行抓包，发现没有报文，说明可能是前端验证。在你输入正确的验证码之前，不会发送报文。

方式一：输入一次正确的验证码，BP进行抓包，发送到repeater。
修改验证码重新发送，发现后端不会二次验证验证码。

方式二：手动删除JS代码

2.3 短信轰炸和无效验证

2.3.1 验证码/旧密码前端验证漏洞

随便输入旧密码，新密码正常输入，发包。
截取回包，将标识符改为true，在放行。

2.3.2 短信轰炸

情况一：
没有限制，任意下发短信，直接放到intruder中即可

情况二：有一定时间间隔，无限下发
每隔60秒下发一条短信，无限下发，短信轰炸
在测试过程中，可通过编写Python脚本来计算短信下发时间间隔，实现短信轰炸。

2.3.3 无效验证

无效验证，网站测试之初，可能验证码无效，几率很低

3、登录前端验证漏洞（忘记密码）

3.0 忘记密码-给邮箱/手机发验证码

当用户输错验证码时，可能需要客户重新填写验证码，60s内验证码都不会改变

3.1 验证码前端绕过和修改他人密码

客户端验证是不安全的，可能导致任意账号注册、登录及重置任意用户密码等问题

1、直接返回明文验证码：输入手机号后，点击获取验证码。按F12调出开发者工具，然后在网络中，监听到两条json数据，发现数据中夹带着验证码

2、返回加密后的密码：同上，方法相似，再回包里面

3、甚至在创建新密码的时候，抓包修改用户名，如果后端没有进行二次验证，则可以修改别人的密码！

3.2 密码找回

在用户更改密码和找回密码时，会发送一个验证码到手机、填写正确的验证码后，后台会在返回的报文中，通过状态码来进行正确的判断。

这个时候可以通过修改返回报文中的参数，使页面跳转到修改密码页面。

也就是说只要知道别人的账号，就可以随意修改别人的密码。

3.3 token参数可逆（链接的形式）

通过邮箱找回密码时，邮件中将出现一个含有token的重置URL。

从经验来看，开发人员习惯以时间戳、递增序号、关键字段(如邮箱地址)等，作为因子，采用某种加密算法或编码生成token，导致token可能可逆！

实验靶场：基于时间戳生成的token
http://lab1.xseclab.com/password1_dc178aa12e73cfc184676a4100e07dac
需要通过忘记密码，来对admin的密码进行修改！

1、用BP进行抓包

可以看到返回包中，邮件已经发送到admin邮箱！但是却看不到session长什么样

2、右键发送repeater查看aaa账号
目的是让我们通过其他用户的token，伪造出admin的token

发现参数sukey：d6e5115913b948a4f19405b749bc0324

3、解密
发现sukey是32位，猜测可能是md5加密
MD5解密结果：失败

发现是一个Linux的时间戳

4、攻击流程
先发送aaa的重置链接，会返回一个时间戳
在输入admin的，不会返回链接
再发送bbb的重置链接，会返回另外时间戳

这时候，admin的时间戳肯定在aaa与bbb之间，只需一个一个试url即可！

有些是通过参数进行token拼接！

3.4 服务器验证、三阶段验证、默认密码

3.4.1 服务器验证逻辑缺陷

在登陆状态下修改自己的密码时，通过修改截获的数据包，将部分参数替换，从而将他人的密码改为自己指定的密码。

4、任意账号注册

4.0 未验证、批量注册、个人信息伪造、前端绕过

未验证邮箱/手机号、批量注册，造成服务器dos应用层攻击，影响网站的正常使用，通常由于上边无验证码或者验证码不安全，导致可以写脚本来批量注册。

个人信息伪造，若出现身份证信息注册，且是前端验证，可以通过抓包绕过

4.1 用户名覆盖

5、权限类漏洞（越权）

5.1 水平越权

5.1.1 基于用户身份ID

在使用某个功能时，通过用户提交的身份ID（用户ID、账号、手机号、证件号等用户唯一标识）来访问或操作对应的数据。

POST请求中存在可修改的参数，可能泄露用户B的订单或信息等

5.1.2 基于对象ID

在使用某个功能时，通过用户提交的对象ID（如订单号、记录号）来访问或操作对应的数据。

GET请求中的参数，oid值等看看能否遍历其他的订单号

5.1.3 基于文件名

在使用某些功能时，通过文件名可直接访问文件，最常见于用户上传文件的场景。

文件上传之后，对图片进行预览的时候，可能会给一个get参数的url！

5.2 垂直越权

如仅使用js跳转来限制未授权的用户访问。

6、其他类型逻辑漏洞

6.0 数据包重放、条件竞争

6.0.1 数据包重放漏洞

通过数据包重放，可以造成短信轰炸、邮件轰炸、重复提交订单等

修复方法：
1、建立token机制或验证码机制，一次有效。
2、计算两次发送的时间间隔，时间过短则不能继续发送。
3、构造一个Hashmap<String, shot>，存放邮箱或电话号码 及 对应次数，只要某个邮箱或电话号码次数够了，就崩继续发送

6.0.2 条件竞争

如文件上传靶场第十八关。 尤其是当前系统中大量对资源进行共享，如果处理不当的话，就会产生条件竞争漏洞。通俗的说，条件竞争涉及到的就是操作系统中所提到的进程或者线程同步的问题，当一个程序的运行结果依赖于线程顺序，处理不当就会产生条件竞争。

6.1 订单金额和端口无线枚举

6.1.1 订单金额任意修改

再提交订单的时候，抓取数据包或者直接修改前端代码，然后对订单金额进行修改
常见参数：rmb、value、amount、cash、fee、money
思路：相同价格增加订单数量，相同订单数量减少产品价格，订单价格设定为负数（负数跟正数相加等于0），无限叠加优惠券等等

6.1.2 接口无限制枚举

有些关键性的接口因为没有做验证或者其它预防机制，容易遭到爆破攻击。
优惠券枚举、会员卡号枚举等等

6.2 支付漏洞

浏览器跳转通知

基于用户访问的浏览器：如果用户在银行页面支付成功后，直接关闭了页面，并未等待银行跳转到支付结果页面，那么用户网站就收不到支付结果的通知，导致支付结果难以处理。二七七浏览器数据和容易被篡改而降低安全性（这种方式数据经过了客户端浏览器，极大的可能性被第三方恶意修改）

服务器端异步通知：该方式是支付公司服务器后台直接向用户指定的异步通知URL发送参数，采用POST或者GET的方式。商户网站接受异步参数的URL对应的程序中，要对支付公司返回的支付结果进行签名验证，成功后进行支付逻辑处理，如验证金额、订单信息是否与发起支付时一致，验证正常则对订单进行状态处理或为用户进行网站内入账等。

6.3 越权支付、无限制试用、总结

1、越权支付
通过修改一些特殊的传参（如:id,username,openid）来达到用他人的资金来购买自己想要的商品

2、无限制试用
通过修改特殊参数（如:id,pay,test）来达到无限制试用
“只验证了信用卡的有效期限”

7、SRC中逻辑漏洞的检查总结！

7.1 支付漏洞总结

1、找到关键的数据包
可能一个支付操作有三四个数据包，我们要对数据包进行挑选
2、分析数据包
支付数据包中会包含很多的敏感信息（账号、金额、余额、优惠），要尝试对数据包中的各个参数进行分析。
3、不按套路出牌
多去想想开发者没有想到的地方
4、pc端尝试过，wap端也看看，app也看看

7.2 防御方法

1、在后端检查订单的每一个值，包括支付状态；
2、校验价格、数量参数，比如产品数量只能为整数，并限制最大购买数量；
3、与第三方支付平台检查，实际支付的金额是否与订单金额一致；
4、如果给用户退款，要使用原路、原订单返回，比如：退押金，按用户原支付订单原路返回；
5、MD5加密、解密、数字签名及验证，这个可以有效的避免数据修改，重放攻击中的各种问题；
6、金额超过指定值，进行人工审核等。

7.3 逻辑漏洞checklist！

7.3.1 注册：

  • 短信轰炸
  • 验证码安全问题
  • 密码爆破
  • 邮箱轰炸
  • 用户任意注册、批量注册
  • 用户名枚举
  • XSS（有框的地方就可以尝试插XSS）（一切前端和后端交互的地方）

7.3.2 登录

  • 短信轰炸、验证码安全、密码爆破、邮箱轰炸
  • SQL注入
  • 撞库
  • 抓包把password字段修改为空值发送
  • 认证凭证替换：比如返回的数据包中包含账号，修改账号就能登陆到其他账号
  • Cookie仿冒
  • 修改返回包的相关数据，可能会登录到其他的用户

7.3.3 找回密码

  • 短信邮件轰炸、短信邮箱劫持
  • 重置任意用户账号密码、验证码手机用户未统一验证
  • 直接跳过验证步骤

7.3.4 支付

  • 购买支付、充值（要利用抓包去仔细查看每一个可用的参数）
  • 交易金额、数量修改、更改支付模块（比如更改支付的模块金额）
  • 交易信息订单编码，导致信息泄露
  • 整数溢出，int最大值为2147483647，超过最大值
  • 修改充值账户
  • 支付绕过
  • 抽奖活动
  • 刷奖品、积分
  • 并发
  • 优惠券、代金券
  • 并发逻辑漏洞（burp爆破批量获取优惠券）
  • 修改优惠券金额、数量
  • 订单信息
  • 订单信息遍历、泄露
  • 订单信息泄露，导致用户信息泄露
  • 删除他人订单

7.3.5 会员系统

  • 修改个人信息上传头像，文件上传漏洞
  • 如遇上xlsx、docx，可能存在XXE，上传恶意的文档盲测
  • 图片上传可能遇到imagereagick命令执行，上传恶意图片 或 图片马
  • 视频上传如果使用ffmpeg<3.2.4（视频按帧分割成图片），上传恶意avi盲测ssrf
  • 用户横向越权访问、遍历、导致用户信息泄露
  • SQL注入、个人简历存储处(存储型XSS)、个人信息注册的名称也可以插入XSS

7.3.6 传输过程、评论区

  • 明文传输账号密码
  • 修改信息处无session/token导致csrf
  • POST/COOKIE的SQL注入
  • POST的SQL注入
  • 存储型XSS
  • 无session/token导致CSRF

7.3.7 验证码问题、短信轰炸

  • 前端验证码（验证码一直有效）
  • 返回包中存在验证码
  • 删除验证码 或者 cookie/token中的值可以爆破账号密码
  • 一直重复
  • 删除修改cookie，重放数据包
  • 遍历参数发送数据包
  • 手机号后面加空格 或者 前面加其他的比如+86或者逗号分号等，然后重发数据包
  • 请求参数修改大小写，或者添加请求参数比如&id=1

一个站的登录处可能做了防护，但是在找回密码处可能没有安全防护，或者在注册流程中没有安全防护，所以说多测试接口。

如果对手机号一天的次数进行了限制，还可以再发一次短信，通过修改前端 或者 后端返回的状态码进行绕过

7.3.8 水平越权、数据泄露、任意用户密码重置

  • 主要是登陆后，看能否修改参数，主要要找到多个接口不断测试
  • 关注网页源代码，有时候会有表单，但被hidden（隐藏标签）给隐藏起来了，可以修改返回包然后尝试获取数据检测（如：Type:password改成txt）
  • 多个账号，主要分析请求参数
  • 在找回密码处，填写数据后抓包查看返回信息，有可能存在敏感数据返回。或者删除修改cookie，重放数据包
  • 目前大部分都是在修改密码处，进行参数修改
  • 有些是前端验证

7.3.9 支付逻辑漏洞

  • 金额直接传输导致篡改：直接对下单的金额进行修改值，可以使用fd或者burp抓包
  • 确定支付之后还可以加入购物车：把商品放入购物车点击下单支付，会跳转到微信，支付宝等第三方支付平台（两种支付方式）
  • 请求重放：购买成功之后，继续重放请求，可以让购买的商品一直增加
  • 请求参数干扰：金钱做了签名认证之后，修改后不通过，但是在里面仍然会有一个参数对金额产生影响导致问题产生。
  • 订单替换：订单替换发生在支付之后的事件处理，同时向服务器发起二次支付请求，一个多一个少，支付金额少的，然后支付之后进行替换，告知服务器订单支付完成，并且过程可以反复的回放。
  • 用户替换：在支付过程中发生用户替换现象，首先登陆自己的账户，然后取得另一个人的账户名等有效信息，在业务流程中用对方的用户名替换自己的用户名，用对方的余额购买完成后，再替换自己的账号名，这样就形成了别人的钱买自己的东西

7.3.10 登陆绕过、水平越权、垂直越权

  • 部分网站的身份验证放在前端，因此只要将response包中的相关字段进行修改，比如0改成1，flase改成true，就可以登陆任意用户账号
  • 遍历ID。在一些请求中GET和POST有明显的ID数字参数（手机号、员工号、账单号、银行卡号、订单号等等）
  • ID替换。如果程序对用户表示进行了hash加密，而无法破解用的什么方式的话，就无法通过遍历ID来获取其他用户的信息了，此时可以尝试注册两个账号，通过替换两个ID加密后的值，判断程序是否对权限进行了验证，如果没有，也会存在越权问题
  • 观察cookie中的session字段，可能某些字段存在参数代表admin身份。
posted @   xmh666  阅读(18)  评论(0)  编辑  收藏  举报
努力加载评论中...
点击右上角即可分享
微信分享提示