1. 逻辑越权

1.1. 漏洞原理

逻辑越权漏洞就是当用户跳过自己的权限限制,去操作同等级用户或者上级用户。正常的情况下,当一个用户去访问某个资源的时候,首先需要去登录验证自己的权限,其次是对数据的查询,最后返回数据内容。

但是如果在权限验证这里,出现了验证不足或者根本就没有验证,那么就会导致越权漏洞的出现。并且逻辑越权又分为水平越权和垂直越权。

1.2. 漏洞原因

逻辑越权主要是由于开发人员在对数据的增删改查的对人员客户端的请求数据过分相信,未对其进行权限判定而导致的问题。

1.3. 水平越权

1.3.1. 原理

水平越权也就是同等级越权,可以理解为本来A只能够自己的工资,而通过更换某个ID或者其他的验证身份的操作,就能够A去看B的工资。

1.3.2. 漏洞出现位置

水平越权多数会出现在和数据库进行增删改查的地方,若用户在对其进行信息修改的时候,后台没对其进行严格的校验的话或者校验的规则较简单的情况下,就可能会出现越权漏洞。

1.3.3. 危害

水平越权的危害可以导致用户的个人信息泄露,冒充别人等。

1.3.4. 案例

这里使用pikachu靶场做案例演示。

1.3.4.1. 登录账号

这里首先需要登录账号,模拟自己在日常中正常登录账号。这里会发现只能看自己的信息,若你有一个暗恋的女同事,但你又不好意思去找她要联系方式怎么办?

image-20230414131212314

1.3.4.2. 获取信息

像上面提到了,想要获取女同事的联系方式,那么在查看信息的时候对其进行抓包修改,看看是否能够获取到她的信息呢?

可以看到我们抓包后看到username,那么思考我们能够把这个kobe换成lucy吗?

image-20230414131220291

1.3.4.3. 修改信息

可以看到在对username处修改后,就能够获取女同事的联系方式了。

image-20230414131242276

1.4. 垂直越权

1.4.1. 原理

垂直越权就是通过自身低权限账号去执行高权限账号所能执行的操作。

1.4.2. 漏洞出现位置

垂直越权漏洞可以考虑低权限提升为高权限,比如让普通的用户变成管理员用户。

1.4.3. 条件

其实垂直越权漏洞是需要一定的条件的,需要抓取到高权限用户的数据包,而抓取这个数据包是有一定的困难的,比如可以盲猜数据包,或者通过网站获取源码本地搭建去获取。

1.4.4. 危害

垂直越权的危害可以导致普通用户修改他人的密码,篡改他人信息,依旧个人信息泄露等。

1.4.5. 案例

1.4.5.1. 登录admin用户

这里我们要先登录admin用户。

image-20230414131255205

1.4.5.2. 抓取数据

这里我们抓取admin用户添加用户的信息,并放在重放器中。

image-20230414131302899

1.4.5.3. 登录普通用户

这里我们在登录普通用户,可以看到这个用户只能看,并不能添加用户,由于在登录验证的时候,服务端对其认证就是普通用户

image-20230414131311927

1.4.5.4. 抓取普通用户的cookie值

这里在抓取到普通用户的cookie后替换原先放在重放器中admin用户的cookie值,然后发包。

image-20230414131323246

1.4.5.5. 查看效果

这里在登录普通用户的账号,在发包后刷新页面就能够发现添加一个haha用户。

image-20230414131331439

1.5. 墨者靶场案例

1.5.1. 登录靶场

打开靶场,根据要求获取马春生的个人信息,这边给我我们一个测试账号。

image-20230414131339979

1.5.2. 登录测试账号

我们通过登录测试账号,并且在登录过程中对获取到的数据进行抓包。

image-20230414131348354

1.5.3. 分析数据

在对数据进行分析的时候发现,如果修改用户名,但是我们并不知道马春生的用户名,但是我们看到有一个id,那么可否通过对id的修改获取数据呢?并且通过分析发现这个id就是会员号。

image-20230414131357180

1.5.4. 爆破会员号

这里我们对会员号进行爆破,通过爆破我们也发现很多会员号下面是有数据返回的,但是究竟是哪一个我们不知道。

image-20230414131404562

1.5.5. 前端分析

我们在看前端加载的数据中发现,测试账号的头像图片的加载名和刚刚抓包获取到的会员号是一样的。那么会不会图片名和会员号是一样的,便于存放?

image-20230414131412295

1.5.6. 查看目标头像ID

我们这里返回登录的页面,查看马春生的头像ID也就是会员号,这里我们获取到马春生id结尾是16。

image-20230414131422184

1.5.7. 查看信息

我们获取到目标的id结尾是16,那么我们去查看爆破中id为16的信息。这里我们通过先前的爆破获取到账号和密码,但是密码是加密的我们对其进行md5解密,获得以下信息:

账号:m233241 密码:9732343

image-20230414131432814

1.5.8. 获取信息

这里我们通过登录,成功获取目标信息。

image-20230414131445756

1.6. 修复防御方案

  1. 前后端同时对用户输入的信息进行校验,双重检验机制。

  2. 调用功能前验证用户是否有权限调用的经验。

  3. 执行关键操作前必须进行用户身份验证,验证用户是否具备操作权限。

  4. 直接对象引用的加密资源ID,防止攻击者对ID进行爆破或者枚举,对敏感数据进行特殊处理。

  5. 对于可控的参数进行严格的检查与过滤。

2. Autorize插件

2.1. 插件介绍

Autorize是一个帮助渗透测试人员检测授权漏洞的扩展,这是Web应用程序渗透测试中比较耗时的任务之一。

只需要将低权限账户的cookie值交个插件,然后用高权限的账号登录网站即可,该插件会自动重复每一个请求与低权限用户的会话并对其进行检测。

2.2. 插件状态

有3种强制状态:

绕过!-红色 强制执行!-绿色 是否强制执行???(请配置强制检测器)-黄色

2.3. 插件安装

2.3.1. 安装Jython环境

Autorize插件使用python写的。所以需要使用Jython环境,简单说就是在Java环境中运行python程序的工具,所以先下载该环境(Jython Standalone即可),然后在下载插件。Jython

若下载慢可以使用我保存的: 提取码:fmvs

image-20230414131455405

2.3.2. Jython配置

image-20230414131503390

2.3.3. 安装Autorize

Autorize是可以在插件库里面直接找到的,bur软件版本态度可能没有插件库,那么就需要直接去下载了,下载地址

这里需要刷新一下,并且点击这个插件,不然可能会出现依旧无法安装的情况。

image-20230414131511242

2.4. 插件案例

2.4.1. 抓取普通用户cookie

首先这里需要抓取普通用户的cookie值,然后把cookie值发送到下面的信息框中。

image-20230414131519679

2.4.2. 高权限用户访问

在把低权限的cookie值发送后,我们开启autorize插件的开关,然后使用高权限进行访问网站。

image-20230414131527075

2.4.3. 插件效果

我们在登录高权限后,进行浏览就会产生效果。

image-20230414131534690

2.4.4. 插件颜色介绍

在结果中看颜色,红色代表存在越权、黄色代表不确定、绿色代表没问题。在左边一列中红色列代表存在越权的可能,右边一列中红色列代表存在未授权访问的可能。

image-20230414131543422

2.4.5. 查看响应数据

可以点击三个数字和后面的效果可以看到相应的响应数据。如果在响应中存在一些相应的敏感数据,或者查看到相关的增删改查的post请求就可以报相应的漏洞问题了。

image-20230414131550431

3. 支付漏洞

3.1. 介绍

支付漏洞在漏洞中一直是处于高风险漏洞,对于企业来说相应的危害是很大的,同样对于用户的风险也很大的,比如当攻击者通过修改,使用他人账号的余额进行购买,那么就属于支付中的越权漏洞了。

3.2. 购买流程

选择商品和数量——产生订单——选择邮寄地址及支付方式——订单支付——完成支付。

3.3. 支付漏洞分类

参考链接:支付漏洞之总结

3.3.1. 修改支付价格

对于修改支付价格,通常来说购买一件物品需要选中自己所需购买的物品,其次确认相关的信息,最后支付价钱,而在这个过程中,可以在选中时就修改价格,若有相关的验证,则可以向后边退,一步一步测试。

3.3.2. 修改支付状态

其实这里的支付状态挺好理解的,把支付未成功修改为支付成功即可,这个也是由于支付的状态未和实际订单的支付状态进行校验而产生的。

3.3.3. 修改购买数量

在支付的过程中,数量也同时决定着价格,比如:1个数量商品对应的是100,2个数据就是200,那么当你修改这个值数量值为负数时,那么其金额也会变为负数,最后就会导致支付问题的产生。

3.3.4. 替换支付

替换支付简单来说,首先去产生两个订单,但是这两个订单的商品是不一样的,其价格也是不一样的,如果服务端未做好相应的验证,那么在支付过程中去替换数据,最后支付,这时候就可以使用订单支付的价格购买到其他贵的物品。

3.3.5. 越权支付

在支付当中会出现当前用户的ID,比如:username=XXXXX,如果没有加以验证,其支付也是一次性支付没有要求输入密码什么的机制,那么就可以修改这个用户ID为其它用户ID,达到用其他用户的账号进行支付你的商品。

3.3.6. 修改优化价

比如一些商品有优惠价,优惠多少多少,那么在支付时抓包,修改这个优惠价就可造成支付问题的产生。

3.4. 支付漏洞常见篡改参数

商品的ID编号、购买价格、购买数量、支付方式、订单号、支付状态等。

3.5. 支付漏洞案例

这里我们安装大米cms_5.4,在这个大米5.4电子商城是存在逻辑支付漏洞。

3.5.1. 获取源码

下载链接:大米cms5.4提取码:onew

3.5.2. 大米靶场安装步骤

这里安装靶场很简单直接把里面的内容解压到phpstudy中,然后访问http:你的靶机ip/dami_5.4。

3.5.2.1. 安装靶场

1)由于这里我们还没有开始安装,需要先按照以下步骤进行安装CMS。

image-20230414131604114

2)这里也是选择继续。

image-20230414131613064

3)这里的数据库密码和数据库名字可以根据自己的服务器来设置,如果是服务器的数据库是默认的账号密码,那么密码就是root,至于管理员设定的密码,随便怎么设置吧。

image-20230414131624362

  1. 成功安装。

    image-20230414131635300

3.5.2.2. 注册账号

这里我们需要先注册一个账号,用于来购买物品,这里我就创建一个test/test。

image-20230414131643402

3.5.3. 修改支付价格案例

3.5.3.1. 选择商品

其实这个修改支付价格案例,比较简单,而且正常来说,这个地方应该也是比较难实现的,可以看到大米测试产品是6000元。

image-20230414131651360

3.5.3.2. 抓取数据包

我们通过抓取购买的数据包修改支付价格,可以看到原来是6000元。

image-20230414131702985

3.5.3.3. 修改数据包

这里我们改成100测试一下效果,修改后的数据包就不发了,直接看效果。

image-20230414131710657

3.5.4. 替换支付案例

3.5.4.1. 选择贵的商品

替换支付就是抓取贵的数据包替换便宜的数据库实现使用便宜的价格购买贵的商品,而使用到这种方式就是在假设我们无法直接修改金额的情况下,我们可以使用这种替换方式,这里我们先选择贵的手机。

image-20230414131719956

3.5.4.2. 抓取贵的商品数据包

抓取贵的数据包,然后放在重放器中,暂存。

image-20230414131729653

3.5.4.3. 选择便宜的商品

我们选择购买一个便宜的手机,直接购买,抓取数据包,就不展示便宜的界面了。

image-20230414131738175

3.5.4.4. 对比数据包信息

这里我们对比两个数据包的信息。

5400的数据包 GET /dami_5.4/index.php?m=Member&a=gobuy&iscart=0&id=70&name=%E5%A4%A7%E7%B1%B3%E6%89%8B%E6%9C%BACMS&qty=1&price=5400&gtype=%E7%81%B0%E8%89%B2&pic=/dami_5.4/Public/Uploads/thumb/thumb_1393218295.jpg HTTP/1.1 6000的数据包 GET /dami_5.4/index.php?m=Member&a=gobuy&iscart=0&id=127&name=%E5%A4%A7%E7%B1%B3%E6%B5%8B%E8%AF%95%E4%BA%A7%E5%93%81&qty=1&price=6000&gtype=%E7%81%B0%E8%89%B2&pic=/dami_5.4/Public/Uploads/thumb/thumb_1393218295.jpg HTTP/1.1

3.5.4.5. 修改数据包

这里我们看到只有ID和金钱不同和图片不一样,其他的都是一样的。那么这里我们就修改id,当然为了更只管点,我们替换id和图片来显示。

image-20230414131747561

3.5.4.6. 疑惑

其实到这里就结束了,但是我有一个疑惑的地方,我替换商品后,虽然价格便宜了,会不会导致我购买的物品还是原来便宜的物品?但是后来我考虑到一个问题,我是在同一家购买的,我替换ID后,相当于替换了商品,在后台看到的应该是贵的商品,只是价格便宜了。不知道理解的对不对!

3.6. 修复防御方案

  1. 对商品的价格进行判断,不能为负数。

  2. 商品的价格以数据库的为准,不能以页面为准。

  3. 设置类似的token值来对数据包进行唯一性处理

4. Cookie脆弱性

4.1. cookie原理

  1. 用户在客户端 (一般为浏览器) 中访问某个页面 ,也就是向服务器发送请求。

  2. 服务器收到请求后,会在响应头中设置Set-Cookie字段值,该字段存储相关信息和状态。

  3. 客户端解析服务器HTTP响应头中的Set-Cookie字段,并以key=value的形式保存在本地,之后客户端每次发送HTTP请求时,都会在请求头中增加Cookie字段。

  4. 服务器接收到客户端的HTTP请求之后,会从请求头中取出Cookie数据,来校验客户端状态或身份信息。

4.2. Cookie案例

这里我们使用熊海v1版本,这个版本上有很多的漏洞,可以直接对其进行深度的挖掘,这里我们就只涉及Cookie脆弱性。

4.2.1. 获取源码

这里找这个熊海v1源码挺麻烦的,找了很多都需要积分才能下载,很多文章只有解释,并不会给下载链接,可能想锻炼我们这些小菜鸟吧。这里呢,我就不锻炼和我一样的小菜鸟了,毕竟都是菜鸟,哈哈哈哈哈.......

下载地址:熊海提取码:lldw

4.2.2. 熊海靶场安装步骤

这里直接把下载的源码解压放到phpstudy中就可以了,然后使用浏览器对其进行访问安装。

4.2.2.1. 靶场安装

  1. 使用浏览器访问:http://你的服务器ip/熊海文件夹名称/install/,即可进入安装界面。这里首先需要创建一个数据库,这里不会找到如何创建数据库的,直接打开phpstudy中phpMyAdmin进行创建。这里的数据库名需要填入下面安装中的。

    image-20230414131757864

  2. 下面的配置就根据自己的服务器信息进行设置。

image-20230414131807149

  1. 到这里就安装成功了。

    image-20230414131814801

4.2.2.2. 访问熊海网站

这里只需要访问http://你的服务器ip/熊海文件夹名/,这样就可以了。

image-20230414131822892

4.2.3. cookie越权登录案例

这个越权登录,其实是基于代码审计获取得,也就相当于是白盒测试,若黑盒测试,基本上应该是测试不出来的。

4.2.3.1. 代码审计

通过查看/inc/checklogin.php,可以看到这里的cookie值就是判断user是否为空,若不为空就跳转登录进去,若为空则会让你进行登录。

image-20230414131831960

4.2.3.2. 抓取登录信息

若直接登录在页面后面加上admin,但是我们之前没有登录,那么在访问admin界面的时候就会跳转至登录界面,这里我们就抓取跳转的登录信息。若这里你抓取到很多的cookie值,那么把浏览器清空,在重新获取。

image-20230414131840181

4.2.3.3. 手动添加cookie值

我们在之前从源码中了解到,只要保证cookie值不为空就能正常跳转,那么我们这里就手动添加一下cookie值。这里我输入的cookie值是cookie=1,当然你也可以换成别的,只要让其不为空即可。

image-20230414131848322

4.2.3.4. 查看跳转情况

可以看到这里,修改过cookie值后,成功跳转至admin用户管理界面,也就是控制台。

image-20230414131855805

4.2.3.5. 问题

通过跳转上去,发现并不能点击信息,当点击信息后会自动跳转回登录界面,关于这个问题其实一开始我也想不通,能登录却不能操作,作用不大呀,想着是不是需要配合其他漏洞。

但是在点击后发现好像没有cookie值,然后添加cookie值后发现能够正常访问了,然后相通后发现访问正常还需要抓新的包把cookie继续添加上去进行放包。

4.2.3.6. 进行评论列表

我们点击后需要在新的数据包中继续添加cookie值,不然就会返回登录界面。

image-20230414131905421

4.2.3.7. 查看评论列表效果

这里可以看到我们已经成功进入评论列表了。

image-20230414131913938

4.3. 越过条件

其实在这里可以看到我们直接输入了cookie: user=1,那么我们该如何知道这个cookie值需要使用到user呢?所以相对来说挺鸡肋的,在实战中若没有源码基本上不可能绕过,所以这多数适合在白盒测试中,如果一定要使用黑盒测试,那么就需要在网上找相应的源码进行分析,但若别人修改了,那么基本上就是凉凉的节奏,不可能被绕过的。

4.4. 修改防御方案

  1. 根据交互所需的传输范围,设置适当的Cookie有效时间

  2. 对cookie加密以及数字签名,并在安全信道中传输

  3. 用URL参数代替cookie中可能包含的敏感信息

  4. 不要在cookie中设置中文

  5. 合理设置Cookies中的安全属性

  6. 服务器不应该在同一个主机上同时运行相互不信任的服务

客户端回显、response状态值、验证码爆破、找回流程绕过等。

5. 找回流程绕过

5.1. 找回流程原理

简单来说就是未验证短信验证码与手机的匹配关系(却验证了短信验证码与图片验证码)服务器端应该是只检查是否发送过验证码,但未验证验证码与手机号的匹配关系,导致任意账号重置

5.2. 找回流程案例

靶场是墨者学院的一个登录密码重置漏洞分析溯源,由于可能存在一些敏感内容可能过不了审,就不截图了,直接用文字描述吧。

这里其实就是就是重置系统平台中17101304128手机号的登录密码。

5.2.1. 靶场情况分析

正常网站在重置密码的时候,会先验证手机号和验证码是否匹配,当匹配了才会跳转到重置密码的页面。而这个网站重置密码和验证在一个界面,重置的时候以输入的手机号为主,那么就会造成重置错误的出现。同时最大的问题在于重置密码的时候为对手机号和验证码未进行绑定校验。

5.2.2. 靶场操作步骤

5.2.2.1. 获取验证码

这里首先需要先获取已注册手机号在重置密码时的验证码。要把这个验证码进行保存,并且要在5分钟内完成。

image-20230414131927461

5.2.2.2. 填入验证码

把刚刚获取到的验证码填入验证码框中。

image-20230414131940049

5.2.2.3. 重置密码

对现在这个手机号进行重置密码,这里提示不用管,如果按照模拟来说的话,应该是模拟验证成功的情况。

image-20230414131948204

5.2.2.4. 替换目标手机号

这里在替换目标手机号后,点击获取验证码,使其触发验证码中的验证功能。

image-20230414131956208

5.2.2.5. 填入之前验证码

在通过获取验证码后,这里我们是收不到目标的验证码的,所以我们填入我们之前获取的验证码。

image-20230414132004036

5.2.2.6. 重置成功

这样就能够把目标的密码重置了,可以看到我们已经拿到key了。

image-20230414132011865

6. response状态值

6.1. response状态值原理

Response状态值,就是在服务器发送某个密码重置的凭据之后,出现特定的响应值(ture,1,ok,success等等,例如响应头中的HTTP/1.1 200 ok),而且例如如果回显值得校验是发送到客户端进行,通过对校验值得使用规则进行分析后,抓包将Response状态值改为正确的,然后放包,这样就能够从而达到重置密码得效果。

6.2. response状态值前提条件

关于Response状态值的验证需要判断是否为前端验证,如果是后端验证,那么你就算修改成正确的也无法验证成功,如果页面以前端结果进行验证,那么就能够绕过,也就是说需要根据具体的验证情况进行绕过。

6.3. response状态值危害

其实这里的危害和客户端回显差不多,都可以通过这样方式对登录、重置密码等进行操作。

6.4. Response状态值案例

这里的案例操作完好像并不会真正保存,这里就学习一下这个流程,也不错的,至少知道怎么操作。这里使用PHP云人才系统靶场,安装和资源在下面章节。

6.4.1. 查看正确状态值

这里查看正确状态值和客户端回显绑定操作是一样的,因为没有验证码短信系统,只能使用客户端回显进行操作。这里就不操作了直接看状态值。

这里可以看到正确的状态值是1。

image-20230414132026666

看页面也可以看到我们成功绑定了手机号

image-20230414132035050

6.4.2. 查看错误状态值

错误的装填值只需要在验证码处随便输入一些内容,然后保存,发到重放器里面发送,查看状态。这里直接看错误的状态值了。

可以看到我的验证码是随便输入的,错误的状态值是3。

image-20230414132042049

6.4.3. 拦截状态值

这里修改状态值能否成功取决于对方是以什么进行验证,具体解释我在上面Response状态值中已经进行解释了。这里就不解释了,直接操作。

这里随便输入验证码,然后抓包,然后拦截状态值。

image-20230414132050753

6.4.4. 修改状态值

点击完拦截请求响应后,放包就能看见状态值了。

image-20230414132059199

这里我们拦截后,把状态值修改为1,然后一直放包,如果出现拦截不到的情况,清空浏览器记录,可能存在干扰。

image-20230414132108638

6.4.5. 查看效果

这里查看效果,整个操作,有点自欺欺人了,状态值是修改了,但是数据库并不一定会接收这个数据。

image-20230414132121607

7. Token验证

7.1. Token的原理

基于Token的身份验证是无状态的,我们不将用户信息存在服务器中。当第一次登录后,服务器生成一个Token便将此Token返回给客户端,Token是服务端生成的一串字符串,并作为客户端请求的一个身份令牌,以后再登录,只需带上Token请求数据,不需要再次输入用户名和密码

7.2. Token的目的

为了保护凭据的安全,为了减轻服务器的压力,减少频繁的查询数据库……采用了Token进行身份认证,一般会把token二次保存在cookie或session里面,并且根据cookie和session的过期时间去维护token的过期时间

7.3. Token暴力破解

7.3.1. 前提条件

如果服务器检测到频繁的错误登录后,就会将该账户锁定,那么就无法再爆破了,而且这个案例的Token值是由前端生成的,也就是说在页面中回显,就像之前提到的客户端回显一样。相当于这里也需要借助Token回显。

简单来说就是第一次登录给你一个token值,这个token值是用于下一次登录的,这样就避免了数据库来回访问对比,而且这里还在数据包中回显了,并且没有加密,就导致这个漏洞了。

7.3.1.1. Token回显

这里回显就相当于,这此回显的内容,会成为下次发送的token值。

image-20230414132131209

7.3.1.2. 验证Token回显

这里为了验证我们先重新获取一个数据包,然后拦截返回的请求情况。

image-20230414132141065

查看返回的情况,看看token值是多少?这里可以看到token是49373639c355293c49560529267。

image-20230414132149554

我们再看从新情况的包是否token值等于刚刚获取到的值,可以看到是等于之前获取到的token值,所以就验证了我们的猜想。

image-20230414132157583

7.3.2. 正式爆破

7.3.2.1. 获取数据包

这里我们抓取一个数据包即可。

image-20230414132205379

7.3.2.2. 加载测试器

这里我们把数据包发到测试器中,在位置中,我们首先清除所有,然后选择音叉(pichfork)。

image-20230414132212795

添加需要爆破的参数,这里我们假设我们的用户名是对的,所以我们只爆破密码和token值。

image-20230414132223819

7.3.2.3. 设置载荷1

这里我们先设置1的载荷就是我们的密码,由于我知道账号和密码,所以我就直接随便写了几个,当然你也可以调用外部密码表进行爆破

image-20230414132231522

7.3.2.4. 设置载荷2

这里把原来的有效负载集设置成1,这个页面我就不展示了,然后进入选项,把线程调整为1,由于是一个匹配一个的,不能一个线程发多个。

image-20230414132239678

7.3.2.5. 设置重定向

我们一直向下翻,翻到最下面有一个设置重定向把它设置为仅限范围。

image-20230414132248176

7.3.2.6. 设置响应值

注意这个都是基于载荷2的基础上设置的,不要设置成载荷1了。

这里找到Grep-Extract—点击添加(add)—点击获得回复,如果点击过了就是显示重新获得回复—找到Token值,双击这个值会自动添加的—点击OK。

image-20230414132255594

7.3.2.7. 设置载荷类型

这里我们需要把载荷类型设置为递归搜索,英文我忘记了,尴尬了,burp软件我找到的一直都是中文的,英文的都是高版本的,我发现挺难用的,而且一些特定的参数,输入了没效果。然后下面的框中的内容在设置完上一步后会自动添加的,然后下面的值我们把刚刚抓包获取到的token值输入进去即可,然后开始攻击。

image-20230414132303447

7.3.2.8. 查看攻击效果

这里找查看攻击的内容就可以了, 如果多的话,可以使用过滤器进行查找。至于burp的过滤器设置可以百度搜索一下。

image-20230414132318580

8. 验证码安全—客户端回显

8.1. 客户端回显原理

这种就是再调用短信平台或者邮箱平台的时候,没有判定验证码和手机号或者邮件进行绑定,并且把验证码检验直接放在客户端的返回数据包中,从而导致验证码在客户端中显示。但是也存在对内容进行加密的情况,若遇到加密,先看看是否能够解密,若无法解密再想其他办法。

8.2. 客户端回显危害

这个危害就会导致可以随意的进行登录、绑定、重置其他人的密码等。

8.3. 客户端回显案例

这里由于没有网站进行测试,那么这里就口述这个情况。

8.3.1. 发送验证码

在部分网站中会使用现验证邮箱获取验证码或者验证手机号获取验证码,但是在这些验证处会出现,在客户端中进行回显,也就是按F12看网络回显。

8.3.2. 回显效果

这里截取一下小迪视频中的演示情况。

image-20230414132328502

8.4. PHP云人才系统靶场安装

这里还是和上面一样直接把下载的源码解压放到phpstudy中就可以了,然后使用浏览器对其进行访问安装。

8.4.1. 获取源码

下载地址:php云人才系统3.2提取码:qc8y

8.4.2. 安装注意

这个云人才系统,不知道我是把虚拟机玩坏了还是怎么了,使用phpstudy2018版本的,切换各种版本都不行,后来下载phpstudy v8.1版本然后调整好了,搞了我一天都怀疑是源码问题。

8.4.3. 安装路径问题1

这里的安装路径一定要看清楚了,解压包里面有一个upload文件夹,把文件夹里面的内容放到根目录中,不要放文件夹。

image-20230414132336646

8.4.4. 安装路径问题2

把里面的内容解压到根目录,其他不用动,整体看一下流程吧,以免出错误。先看一下这个小皮软件的首页设置。

image-20230414132345916

这里点击网站点击管理,管理里面有一个打开根目录,然后把刚刚的upload解压到根目录下面,就可以了。

image-20230414132353665

至于访问,如果放在根目录的话,可以直接访问服务器的ip就可以了,它会自动跳转。

image-20230414132401248

8.4.5. 靶场安装

  1. 使用浏览器访问:http://你的服务器,这里会自动跳转到安装解密,如果没跳转那么在后面再添加一个/install/index.php就可以了,这里点击同意。

    image-20230414132409394

  2. 这里会自动对其进行检测,我们这里直接点击下一步。

    image-20230414132417840

3)这里只需要添加一个数据库的账号密码,根据你的实际需求填写,不要填写错了。填写完就可以点击确定了。

image-20230414132426413

4)这里会自动创建数据,稍等一会之后就会跳转到完成安装了。

image-20230414132435585

8.4.6. 访问PHP云人才系统

这里的直接点击就可以了,若退出了,那么可以访问http://你的服务器ip/upload/index.php即可。

image-20230414132444345

8.5. PHP云人才系统案例

8.5.1. 注册账号

这里我们首先要注册一个账号。

image-20230414132451769

8.5.2. 完善个人信息

这里我们按照需求完善个人信息,这里手机号可能要按照固定格式填写,有检测,如果不想用自己的从网上随便找一个。

image-20230414132459503

8.5.3. 绑定手机号

这里需要可能有点小问题,这里只能够回显手机号的验证码,但是替换手机号可能还是不行。不知道是操作问题还是什么。

image-20230414132507962

8.5.4. 发送验证码

这里发送验证码需要发送两次,第一次可能不会出现。

image-20230414132516493

8.5.5. 输入验证码

这里就需要把刚刚获取到的验证码输入进去,然后点击保存。

image-20230414132528539

8.5.6. 替换验证码

把刚刚获取的验证码替换成新的验证码。

image-20230414132537705

8.5.7. 成功绑定

这里试了,替换手机号,一直出错,无法进行绑定,不知道是不是操作错误了,这里不用管,但是成功绑定原先的手机号也验证了客户端回显。

image-20230414132545892

9. 验证码安全—验证码爆破

9.1. 前提条件

短信验证码一般由4位后者6位数字组成(还有特殊情况,字母数字组合等等),若服务器未对验证时间,次数进行限制,则存在爆破的可能;

9.2. 验证码爆破案例

这里只是举例子,不代表一定是这样的,只是了解一些爆破的流程。这里还是使用我们的PHP云人才系统靶场。

9.2.1. 抓验证码包

可以看到我们这里获取到的验证码是116836。假设我们不知道验证码,我设置个116830开始。

image-20230414132554874

9.2.2. 开始爆破

我们针对这个验证码开始爆破添加数字,这里我修改成116830开始,我们知道验证码是116836,我们就添加到116840吧。

image-20230414132603295

9.2.3. 查找成功情况

这里查找成功其实挺麻烦的,正常情况下还是使用脚本吧,这里是正确的情况,当然我们是已经知道36了。

image-20230414132611442

这个是错误的情况。

image-20230414132619188

9.2.4. 修改验证码

我们知道验证码后,我们修改一下我们的数据包,把验证码改成116836,然后放包。

image-20230414132627827

9.2.5. 查看效果

这里我们能看到我们已经成功绑定了

image-20230414132634550

10. 验证码安全—验证码复用(服务端)

10.1. 验证码复用原理

服务器验证码复用原理其实简单来说就是再某种条件下验证码并没有被刷新,然后被恶意利用,或者再使用完后并未被销毁,而被重复利用。

10.2. 验证码复用危害

既然验证码可以复用,那么我们是不是就可以考虑使用撞库的方式进行测试,反正验证码不变,那么就可以随便测试了,但是前提也是登录不能有次数限制,不然还是不行。

10.3. 验证码复用案例(服务端)

这里也是看效果,主要让其了解相关的原理和方式,这里使用皮卡丘靶场。

10.3.1. 验证码错误信息

这里我们先来看一下验证码错误的信息,可以看到当输错验证码后,会提示验证码错误。

image-20230414132644307

10.3.2. 验证码正确信息

这里为了保证验证码正确,能够出现提示信息,那么我们这里就把密码输入错误。可以看到验证码正确后,那么这里就会显示账号或者密码错误。

image-20230414132651503

10.3.3. 抓包修改

其实从上面的情况我们能看到是先验证验证码,验证码正确后才会去验证账号密码。

所以这里我们先把验证码输入正确,把账号和密码输入错误,然后验证码不变,修改账号和密码,我们看两次提示的信息。

第一次信息我们能看到,验证码正确的情况下,是提示了账号和密码不对。

image-20230414132658551

第二次我们修改了账号和密码,验证码没有改,但是理论的情况下,应该是出现验证码错误的情况,但是这里还是存在账号和密码错的情况。那么就证实了,验证码复用的情况。

image-20230414132717150

10.3.4. 验证情况

这里我们安装上面的情况,我们来输入正确的账号和密码,看看能不能成功登录。

可以看到我们这里提示我们账号密码错误。

image-20230414132740086

这里我们使用皮卡丘靶场中的账号密码登录,我们验证码不改,只该了账号和密码,我们成功登录。

image-20230414132751677

11. 验证码安全—验证码复用(客户端)

11.1. 验证码复用原理

客户端的复用是由于验证码的校验和生成都是在前端进行的,而且使用抓包软件后,发送的数据校验是在后端,不用经过前端的验证码的检查。

11.2. 验证码复用危害

这里的危害和服务端的验证码危害还是不是一回事,服务端至少可以设置一个验证码使用时间或者次数限制,而客户端直接就跳过前端验证,只要有验证码就可以了。

11.3. 验证码复用案例(客户端)

11.3.1. 抓取数据包

这里我们直接抓包看看,可以看到我们正常发包后显示账号或者密码错误。证明验证码是正确的。

image-20230414132805565

11.3.2. 修改数据包

这里我们改了一下验证码,并且输入正确的账号密码,发现能够正常登录,这就验证了之前提到的,前端的验证,当后端发送返回包后,不经过前端验证。

image-20230414132815184

11.3.3. 验证情况

这里我们看一下放包后的验证情况,可以看到成功登录。

image-20230414132824489

12. 验证码安全—爆破工具

这个爆破工具,现在已经不更新了,而且是经过封装的,无法二次开发,这里,并且验证的成功率比较低,这里就不演示了,感兴趣可以去搜索一下。

下载链接:PKAV HTTP Fuzzer 1.5.6提取码:ct7u

网上还有很多的爆破工具,但是想要爆破准确率高,当然还是免不了~~~~

13. 短信轰炸

这里就不具体演示细说了,免得过不了审。

短信轰炸时手机验证码中最常见的一种漏洞类型,在测试过程中,对短信验证码接口进行重发数据包,导致大量发送恶意短信,而通常短信发送是有60秒的等待,那么就需要调用很多的接口已经数据包来进行发送,这个就需要收集大量的数据了,比较复杂了。

14. Callback调用

14.1. callback解释

回调函数就是一个通过函数指针调用的函数。如果你把函数的指针(地址)作为参数传递给另一个函数,当这个指针被用为调用它所指向的函数时,我们就说这是回调函数。回调函数不是由该函数的实现方直接调用,而是在特定的事件或条件发生时由另外的一方调用的,用于对该事件或条件进行响应。

如果callback的数据能够被修改,那么就可以和跨站漏洞相结合,当然需要在页面源码中搜索传递的参数,如果存在,就意味着传递的参数会在前端显示,也就可以构造xss漏洞。

当然前提添加很多,而且这类都是大站,并去本地靶场由于无法调用接口,所以就无法模拟,具体的可以去百度搜索一下。

15. 如何发现这些漏洞

15.1. 解释

在日常测试漏洞的时候,如果我们对网站一个一个页面进行测试,那么很费时间,这样就比较麻烦,而在burp软件中可以使用爬虫来爬这个网站,这样我们再对这些数据包进行搜索相关数据就可以了。

15.2. 具体操作

15.2.1. 抓取网站数据包

这里我们直接在进入页面的时候对数据进行抓取,然后发送给扫描。

image-20230414132840632

15.2.2. 设置扫描

这里我们设置选择审计项目,然后点击ok。

image-20230414132849858

15.2.3. 查看情况

这里我们到目标—网站地图—内容中查看,注意burp版本不同可能地方也不同哦,需要注意。

image-20230414132856899

15.2.4. 搜索内容

这里我们点击空白的地方,就会弹出搜索框,我们输入比如id、user、callback,filename,uid等等。

image-20230414132922194

15.2.5. 搜索结果

这里我们搜索id,可以看到有id的是亮的,没id的是灰色的。

image-20230414132930430

16. 最后

如果有内容错误,或者解释不到位的还请各位指出,也是互相学习。

本文作者:剁椒鱼头没剁椒, 转自FreeBuf