21-逻辑越权

思维导图

逻辑漏洞就是指攻击者利用业务的设计缺陷，获取敏感信息或破坏业务的完整性。一般出现在密码修改、越权访问、密码找回、交易支付金额等功能处。其中越权访问又有水平越权和垂直越权两种。

越权分为水平越权和垂直越权。

水平越权：通过更换的某个ID之类的身份标识，从而使得A账号获取（修改，删除等）B账号的数据。
     
垂直越权：通过低权限身份的账号，发送高权限账号才能有的请求，获得其高权限的操作。

未授权访问：通过删除请求中的认证信息后重放该请求，依旧可以访问或者完成操作。

WEB漏洞-逻辑越权

一、简介

什么是垂直越权：

通过低权限账户身份的账户，发送高权限账号才能有的请求，获取更高权限的操作。

垂直越权测试思路：看看低权限用户是否能越权使用高权限用户的功能，比如普通用户可以使用管理员的功能。

什么是水平越权:

指相同权限下不同的用户可以互相访问

水平越权测试方法：主要通过看看能否通过A用户操作影响到B用户

二、案例1：pikachu-本地水平垂直越权演示-漏洞成因

1.水平越权演示

<1>kobe登录系统后，点击查看个人信息，可以看到自己的手机，住址，邮箱等敏感信息。

<2>点击查看个人信息抓取数据包，通过更换username，进入其他用户信息，将username改为lucy，页面显示lucy的个人信息，成功水平越权。

查看到了lucy个人信息

原理：登录时判断级别，根据级别不同，显示不同的功能页面。在添加用户时，后台只判断了用户登录状态，并未验证级别，所以存在越权漏洞。

2.垂直越权演示

A用户的权限高于B用户，B用户越权操作A用户的权限的情况称为垂直越权

需要注意的

1、一般情况下要知道后台登录页面的地址（对方添加账号的链接地址）

2、对方相关信息用户名 后台页面地址

<1>登录管理员账户发现有查看、添加、删除用户的权限，而普通用户只有查看权限。

<2>管理员登录系统，添加一个用户，抓包发送到repeater中记录下来，然后在丢弃数据包。得到添加请求A。

<3>注销管理员，登录普通用户，得到普通用户的PHPSESSID。

<4>在请求A中替换PHPSESSID值为普通用户的PHPSESSID，成功添加用户。存在垂直越权。

这里的前提条件：要获取到添加用户的数据包。

那么数据包是怎么样才能获取呢？

• 普通用户在前端有操作界面可以抓取数据包
• 通过网站源码本地自己搭建去抓取
• 盲猜

三、案例2：

墨者学院-身份认证失效漏洞实战-漏洞成因

靶场地址：https://www.mozhe.cn/bug/detail/eUM3SktudHdrUVh6eFloU0VERzB4Zz09bW96aGUmozhe

任务目标：需要获取马春生的个人信息

<1>进入靶场后，界面如下，登录已知测试账户test/test。

<3>刷新test抓包分析，

抓取的第一个包

重要信息：

Cookie: PHPSESSID=hctpgubp06a5gkf3r317ktoe42; uid=test; mid=6927071f788211ee17211be0b89ef1e6

再查看第二个数据包：

GET /json.php?card_id=20128880322 HTTP/1.1

这时候思考是不是可以通过修改card_id值的最后2位，相应地会返回不用用户的个人信息。

返回了个人信息

<4>查看前端首页代码，可以找到马春生用户的ID

<5>修改card_id值为20128880316，成功获取到马春生的的个人信息。

<6>可以看到用户密码是用md5加密的，去加密网站解密，成功得到马春生的密码。

<7>使用账号m233241/9732343登录，确认是马春生账户，成功拿到本关key。

<8>还可以使用bp的intruder模块，将card_id值的最后2位改为00-99，可以遍历所有的用户。

造成当前漏洞原因

1、前端安全造成：界面

只判断用户等级后，代码界面部分进行可选直接显示 。

2、后端安全造成：数据库

以user表为例（管理员和普通用户同表）

id,username,password,usertype 
1,  admin,  123456,  1 
2, 	xiaodi,	11111,   2 

//登录用户 admin 或 xiaodi 时，代码是如何验证这个级别？（usertype 判断）通过usertype类型判断登录用户

如果在访问数据包中有传输用户的编号、用户组编号或类型编号的时候，那么尝试对这个值进行修 改，就是测试越权漏洞的基本。

burpsuit2020.x光标聚焦点与输入点不一致

四、案例3：越权检测-小米范越权漏洞检测工具-工具使用

小米范越权漏洞检测工具主要是检测网站越权漏洞的工具。

工具privilegechecker下载地址：

http://pan.baidu.com/s/1pLjaQKF

此工具请使用Java 1.8以上版本运行。

检测原理：

此工具内置了三个浏览器，三个浏览器完全独立，目前采用的是chrome内核，我们可以为三个浏览器使用不同的用户登录目标网站，或者为三个浏览器设置不同的cookie，然后让他们同时去访问同一个url或者发送同样的请求，观察三个浏览器的页面变化。

假如某个URL本应只有1号浏览器的用户有权限查看，但是2、3号浏览器的用户也正常访问了URL，并获取了不该获取的数据，则可能存在越权漏洞。界面如下：

目前操作模式主要有两种：

一、2、3号浏览器与1号浏览器同步。

这种情况我们只要操作1号浏览器，2、3号浏览器会跟随1号浏览器访问同样的地址，这样我们可以为1号浏览器设置更高权限的用户即可检测垂直越权。

为三个浏览器设置同样级别的用户即可检测水平越权。

二、所有浏览器与表格同步。

这种情况主要针对ajax、post、手机app等情况，开启代理功能，类似burp，浏览器或者手机app设置代理为此工具，则会抓下所有的请求，然后我们点击表格中的任意请求，三个

浏览器会以各自的身份去发送这个请求，同样我们观察页面变化来判断是否存在越权问题。

另外此工具也可用于检测csrf漏洞。

操作方法：

1、在三个浏览器各自的文本输入框输入cookie，点击设置cookie，即可为对应的浏览器设置cookie。

2、点击三个浏览器上方的清除cookie，即可清除已经设置的cookie。

3、点击 启动即可启动代理，默认为监听 。0.0.0.0:8088端口。

4、在搜索框内输入关键字，点击搜索即可对表格内所有记录的请求进行搜索。

下载地址：http://www.cnblogs.com/SEC-fsq/p/5736675.html 文件名 privilegecheck.jar 目前只做了windows版本

五、案例4：越权检测-Burpsuite插件Authz安装测试-插件使用

Authz工作原理：将用户认证的HTTP请求头进行修改(Cookie等)，然后通过响应长度、响应状态码判断是否存在越权。

安装：Extender > BApp Store > Authz > install > 安装成功。

安装好之后出现

使用前提：同个业务系统中两个测试账号A、B

使用方法：A账户机进行功能操作，抓包，将待测请求包发送给Authz模块

修改cookie值（或者其他的用户身份凭证请求头）为B账户凭证，运行，当原响应内容长度、响应状态码和被修改后请求的响应内容长度、响应状态码一致则会绿，代表存在越权。

优缺点：

• 优点：使用简单、省时省力。
• 缺点：只是适用于检测越权读取类操作，删除编辑类操作还需人工判断。

bp中还有一个插件AuthMatrix可用来检测越权漏洞，这个插件比Authz更新更好用，但是需要下载Jython，比较麻烦。感兴趣的同学可以试试。

六、案例5：越权检测-secscan-authcheck安装测试-工具使用

下载地址：https://github.com/ztosec/secscan-authcheck

secscan-authcheck工具比较强大，安装也比较麻烦，需要搭建自己的服务器，将工具安装在服务器上，然后需要在浏览器安装插件，将浏览器访问流量导入自己的服务器上，使用该工具检测是否有越权漏洞。

修复建议：

垂直越权：配置权限时，应该遵循“最小原则”，并且使用“默认拒绝所有权限”，只对有需要的主体单独配置权限。

水平越权：创建一个规则库，将访问控制写入配置文件中，通过规则对数据的访问进行控制，如用户过多可考虑“用户组”

1.前后端同时对用户输入信息进行校验，双重验证机制

2.调用功能前验证用户是否有权限调用相关功能

3.执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限

4.直接对象引用的加密资源 ID，防止攻击者枚举 ID，敏感数据特殊化处理

5.永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤

逻辑越权之登录脆弱及支付篡改

一、登录应用功能点安全问题

常见问题：

1.登录点暴力破解
2.HTTP/HTTPS 传输
3.Cookie 脆弱点验证
4.Session 固定点测试
5.验证密文比对安全测试

补充常见的可判定为账号可能存在被盗取的场景：

1. 同一个密码&不同账号，出现错误多次
2. 同一个账号&不同密码，出现错误多次
3. 频繁获取短信验证码

以上的场景存在两个共性，分别是“短时间范围内” and“同一个设备”，因为黑客或者其他不法分子，在不断尝试获取用户账号密码信息时基本是在同一个设备且短时间内高频的尝试不同的账号密码组合。

解决方案

基于上面的常见登录安全问题的共性（“短时间范围内” and“同一个设备”），有其对应的明确的解决方案：

1. 通过ip限制同一个用户的短信的请求上限
2. 通过ip限制同一个用户密码错误次数上限
3. 通过账号限制同一个用户密码错误的上限

二、案例1：HTTP/HTTPS 协议密文抓取

主要还是判断密码是否加密，用什么方式加密，能否构造后进行暴力破解等。

http协议：

可以看到http有的是以明文的方式显示出来的，有的也是加密的。如果以http方式提交的，有加密是在前端进行加密的。

HTTPS协议：

加密的复杂

三、Cookie 脆弱点验证

案例以本地搭建得熊海网站内容cms系统为例

下载地址：https://down.chinaz.com/soft/36930.htm

安装好cms之后我们访问后台登录地址

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-THiE8CFt-1680444531884)(21-%E9%80%BB%E8%BE%91%E8%B6%8A%E6%9D%83%E6%BC%8F%E6%B4%9E.assets/1629342100718-c69a8764-d316-4aa9-adf1-089eff46e25c.png)]

白盒情况下：

<1>审计网站源码，发现登录时存在逻辑漏洞，只要cookie的user值不为空，即判断登录成功。

只做了空判断。

<2>抓包尝试进入首页，删除原有cookie，在cookie中加入user=a字段，发现成功进入首页。

黑盒情况下：

<1>抓包分析，这一串的cookie是浏览器的缓存信息

直接访问前台是没有带cookie的，当我们登录之前是没有任何的cookie的信息

<2>在干净没有访问的过的环境当中是没有带cookie

我们观察到时用用户名作为cookie的信息，是相当的不安全也就是说这是一个可以伪造的cookie信息。

总结：因为这个网站后台的首页的是index通过传参的方式验证登录。登录之前会对cookie进行验证验证由于方式很过于简单只是对cookie是否为空进行判断，也就是说传递的值不是为空程序就认为你是登录了，因此这就形成了弱cookie登录的漏洞。

一般发生在有源码的情况下，我们可以在cookie中加一个user=xx字段，绕过登录。但是黑盒测试时，我们很难发现这种漏洞。一般都是cookie中原先有一个字段user=test，我们将其修改为user=admin，测试是否能拿到admin的权限。

四、某商城系统商品支付逻辑测试-数量,订单

可利用漏洞：

https://www.secpulse.com/archives/67080.html

<1>数量修改造成金额偏差，修改商品数量为-1

<2>商品信息里，支付金额显示为-1000

<3>最终结算时，结算金额为0元。

也通过修改订单编号把购买数量多的订单变成少的订单。

<1>首先抓取到购买数量少的包

在抓取数量多的包，修改订单编号为少的将发送出去，金额发送修改。

五、某建站系统商品支付逻辑测试-价格,订单

<1>抓包分析数据包中有哪些参数。

可以看到当中有数量和价格两个参数。

商品单价原来是6000元，修改商品单价为1元

<2>最终结算时以单价1元购得了手机。

<4>还可以修改支付接口参数值，使用其他的支付方式支付。

逻辑漏洞修复建议：

金额，以及数量，单价，快递费等支付时需要输入的一些数值，尽量的进行安全过滤与判断，严格控制用户从GET、POST、Cookies等的提交方式去篡改数值，再一个支付的加密算法，尽肯能在程序代码里，服务器端里做过滤。

支付逻辑漏洞的修复方法：

（1）在请求数据中对对涉及金额、数量等敏感信息进行加密，保证加密算法不可猜解。并在服务器端对其进行校验.

（2）支付交易请求数据中加入token，防止重放攻击

• 对支付流程的每个环节进行校验，并且防止跳过某一个环节。
• 用户确认购买后，立即验证商品价格（商品单价、商品数量、折扣优惠）、订单价格和到账金额。
• 对一些优惠券、折扣券的使用方式进行测试。
• 修复防范网站其他漏洞。

逻辑越权之找回机制及接口安全

知识点

找回重置机制

• 客户端回显：验证码在客户端浏览器或数据包中回显
• Response状态值：单独请求回复状态值判断验证码是否正确
• 验证码爆破：验证码纯数字过于简单
• 找回流程绕过：跳过中间验证步骤，直接抓包最后一步

接口调用乱用

• 短信轰炸，来电轰炸等

一、墨者靶场密码重置-验证码套用-靶场

靶场地址：https://www.mozhe.cn/bug/detail/66

打开靶场进入操作界面，发现有一个已经注册的手机号

绕过思路：攻击者先用手机号A发送一条正确的验证码，然后将手机号改为B，实现用A的验证码重置B账户密码。

绕过原理：服务器只查询输入的短信验证码与服务器发送过的，不会把短信验证码和手机号绑在一起。

过程：

<1>打开页面，输入18868345809，向服务器请求短信验证码。

<2>新开页面输入17101304128，向服务器请求短信验证码。

<3>将18868345809的短信验证码输入到17101304128的短信验证码处。

<4>将17101304128原本的图片验证码输入。

<5>点击重置，获取key。

其短信验证码5分钟内有效，只验证验证码的有效性，而没有验证验证码和手机号的一致性。所以可以越权重置。

漏洞分析原因

第一个页面：第一个页面输入手机号，验证码
第二个页面：重置密码

刚好靶场是这么一个流程 手机号 新密码 图片验证码,短信验证码

这样就行了一个后台更改数据包发送的手机号也就获取到了验证码。

二、手机邮箱验证码逻辑-客户端回显-实例

案例演示1：真实案例

该网站邮箱验证处，短信验证码在客户端回显。

案例演示2：PHP云系统

该系统有绑定手机号功能

发送验证码时抓包，发现验证码在cookie中回显

三、绑定手机验证码逻辑-Rep状态值篡改-实例

<1>某真实案例，以模拟器app中软件为案例

<2>该APP有修改密码功能

、

<3>输入正确的手机号，错误的验证码，点击下一步，截断响应。

可以看到错误信息回复的状态码。

<4>抓取正确的响应码，将刚才错误的响应修改为验证码正确时的响应（前期测试获取）。

<5>直接跳过验证了，进入下一步重置密码

<6>输入新密码，点击确定，密码重置成功

<7>使用新密码，成功登录系统。

结果就是强制修改了对方密码。

绕过原理：该APP重置密码功能分为2个页面，第一个页面，输入手机号、验证码，第二个页面，重置密码，我们可以通过修改第一个页面的响应数据来绕过验证码验证，直接进入下一个页面重置密码。

上面的漏洞涉及到，这个web应用到底是怎么验证的，是以返回包来验证，还是在服务器端验证。在服务器验证的话，改为正确也没用。

就是说的判断是在客户端验证还是服务端验证。

补充知识

要修改响应值需要使用到 burpsuit里面的一个功能：

do intercept 来抓取到服务端回应给客户端的响应值。

四、找回密码验证码逻辑-爆破测试-实例

PHP云人才系统(Phpyun) V3.2下载：

• http://downcode.com/downcode/j_16621.shtml
• https://pan.baidu.com/s/1P73QFmEhY6f350CvmnOJNg 提取码：xiao

该系统有绑定手机号功能，绑定时，需要验证码，可以配合bp的Intruder模块对验证码进行暴力破解

暴力破解时需要考虑

• 验证码的复杂度：验证码越复杂，成功率越低
• 验证码的时效性：验证码一般都有有效时间，比如1分钟/5分钟，想想你能不能在验证码有效时间内将验证码爆破出来
• 绑定失败锁定策略：有的系统可能会有限制，比如绑定3次失败则不能再绑定
• 如果有图片验证码，考虑是否可以使用工具识别

五、某APP短信轰炸接口乱用-实例接口调用发包

漏洞原理

在绝大部分网站中，都提供短信来进行用户验证，如注册、登陆、修改密码、转账等功能。通过短信可以简单便捷地进行用户验证，但是，如果验证逻辑存在缺陷，导致用户可以无限制请求短信接口，就会造成短信轰炸漏洞，也属于防护功能滥用类漏洞。

该漏洞的利用过程也比较简单，即伪装成正常用户，向短信接口发起大量的请求，即可完成攻击过程。短信轰炸漏洞也能造成不小的危害，如会造成短信通道阻塞、短信资源被恶意消耗，如果被灰黑产利用，制作成短信轰炸机，还会造成企业形象受损，若被用户投诉还可能造成接口封禁等威胁。

案例：

某系统注册账号功能处存在短信轰炸漏洞

在BurpSuite设置代理，抓取发送短信的数据包到Repeater器中，重复点击Go，可以一直发送数据包，则说明短信轰炸漏洞存在

抓取发送短信的数据包，重放N次，可以对该手机号发送N条验证码

手机短时间内收到了大量短信

绕过手法

上面演示的就是最基本的漏洞形式，但更多情况下，服务器会采取一些防护手段来限制你发送次数，但一些防护不严格的话还是绕过的，下面我就分享一些案例来说一下一些绕过手法

1. 修改Cookie值绕过

下面演示实际挖掘过的一些真实网站，该网站一开始发送验证码是可以成功发送的，状态码为1

发送多次后，发现被限制发送次数了，状态码为0发送失败，但可以发现服务器返回了一个Cookie，猜测是根据Cookie值对发送者进行限制

删掉Cookie值后，发现能继续发送，成功绕过了防护，一些情况下不能直接删除Cookie值，要根据情况进行修改

1. 修改IP值绕过

与上面修改Cookie值类似，有些服务器也会通过IP进行限制，特征使用了XXF头

如下面这个例子一样，该网站正常发送验证码，返回包信息为success|success

多次发送后，返回error，但发现存在XXF头，下面尝试修改XXF头进行绕过

随便修改个其他的IP,发现又可以继续发送了，绕过检测IP防护

添加到爆破模块，进行批量发送短信

全部发送成功，发送了大量短信，短信轰炸漏洞存在

1. 修改返回值绕过

某网站成功发送验证码抓包如下，返回值为0

尝试多次发送失败，返回值为9

在BP中抓取响应包，尝试修改返回值进行绕过

抓取到的返回包

将返回信息替换为正确的，并点击Forward发送

成功在短时间内接受到多条短信

1. 尝试添加其他字符绕过

对一些根据相同手机号进行过滤的情况下，然后尝试添加一些字符在后面试试看是否能绕过

1. 多次叠加参数绕过

这种情况比较少见，但也可以试一试。叠加多个参数，看能否发送多条短信验证码

结尾

最后短信轰炸比较好的修复方式还是添加文字验证码，并且随着每次发送而刷新

以上就是我碰到的一些关于短信轰炸漏洞的情况，仅以个人拙见论述，大佬们见笑了。希望大家可以从中学习到一些挖掘漏洞的思路。

防御思路

短信轰炸漏洞造成的原因大概可以总结为两个，一是没有验证用户是否为正常用户，二是没有限制短信下发的频率，而防御思路也可以根据这两个方面来展开。

针对于用户校验方面，可以通过在发送短信验证之前，增加图形验证码或者是滑块验证码。而短信下发频率方面，可以限制单个IP请求频率、限制单个手机号请求频率等等。

图形验证码

造成短信轰炸漏洞的主要原因是攻击者可以编写成自动利用脚本工具，对短信接口进行大量的调用。如果再获取短信验证码前，增加一个图形验证码，只有校验成功才能进行后续操作，也能有效的防御漏洞。

如果图形验证码功能增加的逻辑不当，仍然会造成短信轰炸漏洞：

前端验证：图形验证码必须在服务端生成和校验

验证码复用：验证码必须单次有效，有合理的失效机制

图形过于简单：可以使用OCR进行图形识别，验证作用也就不复存在了，可以使用需要逻辑判断的图形验证码，如简单的算式等等，都可以增加攻击者自动化攻击的成本

转载来自FreeBuf.COM

地址：逻辑漏洞之短信轰炸（原创） - FreeBuf网络安全行业门户

逻辑越权之验证码与Token及接口

一、简介

Token安全

Token的含义：

用户身份验证的令牌——Token

1、Token的引入：
Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。
2、Token的定义：
Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。

3、使用Token的目的：

• Token具有随机性、不可预测性、时效性、无状态、跨域等特点。
• Token完全由应用管理，所以它可以避开同源策略
• Token可以避免CSRF攻击
• Token可以是无状态的，可以在多个服务间共享
• Token是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回Token给前端。前端可以在每次请求的时候带上Token证明自己的合法地位。如果这个Token在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。

4.Token 的优点：

token具有生命周期，会进行更换。

扩展性更强，也更安全点，非常适合用在 Web 应用或者移动应用上。Token 的中文有人翻译成 “令牌”，我觉得挺好，意思就是，你拿着这个令牌，才能过一些关卡。
5.Token一般用在三个地方:
①防止表单重复提交
②anti csrf攻击（跨站点请求伪造）
③身份验证（单点登录）

使用Token常用的两种方式：

1、用设备号/设备mac地址作为Token（推荐）
客户端：客户端在登录的时候获取设备的设备号/mac地址，并将其作为参数传递到服务端。
服务端：服务端接收到该参数后，便用一个变量来接收同时将其作为Token保存在数据库，并将该Token设置到session中，客户端每次请求的时候都要统一拦截，并将客户端传递的token和服务器端session中的token进行对比，如果相同则放行，不同则拒绝。 分析：此刻客户端和服务器端就统一了一个唯一的标识Token，而且保证了每一个设备拥有了一个唯一的会话。该方法的缺点是客户端需要带设备号/mac地址作为参数传递，而且服务器端还需要保存；优点是客户端不需重新登录，只要登录一次以后一直可以使用，至于超时的问题是有服务器这边来处理，如何处理？若服务器的Token超时后，服务器只需将客户端传递的Token向数据库中查询，同时并赋值给变量Token，如此，Token的超时又重新计时。
2、用session值作为Token
客户端：客户端只需携带用户名和密码登陆即可。
客户端：客户端接收到用户名和密码后并判断，如果正确了就将本地获取sessionID作为Token返回给客户端，客户端以后只需带上请求数据即可。
分析：这种方式使用的好处是方便，不用存储数据，但是缺点就是当session过期后，客户端必须重新登录才能进行访问数据。

常见安全问题：

• token 爆破，token 客户端回显等

验证码安全

分类: 图片，手机或邮箱，语音，视频，操作等
●原理: 验证生成或验证过程中的逻辑问题
●危害: 账户权限泄漏，短信轰炸，遍历，任意用户操作等
●漏洞: 客户端回显(已讲)，验证码复用，验证码爆破(已讲)，绕过等

二、验证码识别插件及工具操作演示-实例

验证码识别插件工具使用

• captcha-killer
• Pkav_Http_Fuzz
• reCAPTCHA 等

captcha-killer下载地址：

https://github.com/c0ny1/captcha-killer/releases/tag/0.1.2

reCAPTCHA下载地址：

https://github.com/bit4woo/reCAPTCHA/releases/tag/v1.0

Pkav_Http_Fuzz工具演示：

<1>Pkav HTTP Fuzzer验证码识别工具

• 优点：免费，简单，方便
• 缺点：无法集成到burp等第三方工具上使用，只能在本工具上发包

案例网站页面：https://manage.yyxueche.com//panel/login.php

获取到验证码地址：https://manage.yyxueche.com/panel/verify_code_cn.php

优点:简单好用

缺点:不能配合burp使用，软件不更新了

burp验证码识别插件

<2>captcha-killer burp验证码识别插件使用

下载地址： https://github.com/c0ny1/captcha-killer/releases/tag/0.1.2

下载完成后在burpsuite 里面导入

使用参考博客：

https://www.cnblogs.com/cwkiller/p/12659549.html

https://www.cnblogs.com/nul1/p/12071115.html

以上只能识别图片验证码。

三、验证码绕过本地及远程验证-本地及实例

演示案例1&2靶场环境：pickachu

演示案例1：验证码复用

抓取正确的验证码流量包，发现可以无限使用，不需要更新。更换用户名密码也是不会提示出错。

查看源代码：

发现原因是验证码用过后未及时销毁，导致重复使用。

演示案例2：验证码绕过

这里验证码的生成和验证都是在前端进行，绕过方法是直接屏蔽掉前端相关的JS代码即可。

直接burpsuite抓包发送完成绕过无需别的操作。

有时候前端看不到js代码原因一般是进行了封装，可以通过本地浏览器抓包查看js代码：

演示案例3：真实案例

这里有一个注册功能，给手机号发验证短信时需要输入图形的验证码。

第一次输入正确的验证码成功后，抓包，将验证码字段值设置为空，可以一直向手机发送短信。

但是每次一个手机号要间隔60秒，每60秒才能发一次验证。

四、Token客户端回显绕过登录爆破演示-本地

登录请求包有一个隐藏字段token防止重放，这个字段值由前一个请求从后端返回

绕过方法：可以重放两个请求，从第一个请求响应中取token值，放到第二个请求（登录请求）中，对登录进行暴力破解。

方法一 python脚本

[[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hM4hO8Lb-1680590492557)(21-%E9%80%BB%E8%BE%91%E8%B6%8A%E6%9D%83%E6%BC%8F%E6%B4%9E.assets/copycode.gif)]](javascript:void(0)

# Author:Zheng Na
import requests,re

url = 'http://127.0.0.1/dvwa/vulnerabilities/brute/'
headers = {"Cookie":"security=high; PHPSESSID=hcf6rpl3qghlai922bnjhup465"}

flag = False

f1 = open("username.txt", 'r')
for line1 in f1:
    username = line1.strip()

    f2 = open("password.txt", 'r')
    for line2 in f2:
        # 访问首页
        response1 = requests.get(url,headers=headers)
        # 获取user_token
        user_token = re.findall("(?<=)",response1.text)[0]
        # 发送登录数据包
        password = line2.strip()
        params = {'username': username, 'password': password, 'Login': 'login','user_token':user_token}
        response2 = requests.get(url, params=params, headers=headers)
        if "Username and/or password incorrect." in response2.text:
            print("username:%s,password:%s,user_token:%s----wrong account!" % (username, password, user_token))
        else:
            print("\033[31;1musername:%s,password:%s,user_token:%s----right account!\033[0m" % (username, password, user_token))
            flag = True
            break
    if flag == True:
        break
    f2.close()
f1.close()

结果

方法二 burpsuite爆破

步骤

1.抓包，发送到Intruder模块

2.选择Pitchfork(草叉模式)，添加爆破的参数

3.在Options中找到Request Engine模块，把线程数设为1，表示单线程，这里不能使用多线程，不然无法判断token怎么取用。

4.在Options中找到Rediections模块，选择always，允许重定向

5.在Options中找到Grep-Extract模块，点击Add，并设置筛选条件，得到user_token

6.在Payloads中为选择的参数设置字典，payload set 1表示设置第一个的字典。

等会在依次改为2，和3进行设置。

token字典使用的是页面中的：

类型更换：

7.点击start attack，开始爆破

根据返回长度的大小，可以得到正确的用户密码

总结：其实token的爆破还是非常麻烦的因为要爆破的东西非常多，如用户名，密码、token、要是字典比较大的话那么一时半会根本是爆破不完的。

补充知识burpsuite四种的攻击类型：

一、Sniper（狙击手模式）

针对单一密码，假设确定了两个位置A和B，然后密码包payload里有两个密码1、2，那么攻击模式如下：

Attack No.	Position A	Position B
0	1	null
1	2	null
2	null	1
3	null	2

二、Battering ram（攻城锤模式）

于sniper模式不同的地方在于，同样情况下，攻击次数减半，每次两个位置用同样的密码，如表：

Attack No.	Position A	Position B
0	1	1
1	2	2

三、Pitchfork（叉子模式）

跟前两种不同的地方在于，可以多组密码本payload，又于battering ram相同的地方在于，一一对应，现在添加包含3、4的密码本payload，暴力破解过程如表：

Attack No.	Position A	Position B
0	1	3
1	2	4

四、Cluster bomb（炸弹模式）

跟叉子模式相似的是多个密码本对应多个位置，不同的是不再是一一对应，而是交叉组合，每一个密码本里的密码都对应于另一密码本所有密码，如表：

Attack No.	Position A	Position B
0	1	3
1	2	3
2	1	4
3	2	4

六、某URL下载接口ID值调用遍历测试

类似枚举遍历

http://www.grasp.com.cn/DownFiles.aspx?id=591

遇到以上这类请求接口时，可以尝试配合intruder模块，枚举ID值，看能否获取其他编号对应的用户信息

造成这类问题的原因是水平越权

七、allback自定义返回调用安全-漏洞测试

什么是回调？

一般来说，模块之间都存在一定的调用关系，从调用方式上看，可以分为三类：同步调用、异步调用和回调。同步调用是一种阻塞式调用，即在函数A的函数体里通过书写函数B的函数名来调用之，使内存中对应函数B的代码得以执行。异步调用是一种类似消息或事件的机制解决了同步阻塞的问题，例如 A通知 B后，他们各走各的路，互不影响，不用像同步调用那样， A通知 B后，非得等到 B走完后， A才继续走 。回调是一种双向的调用模式，也就是说，被调用的接口被调用时也会调用对方的接口，例如A要调用B，B在执行完又要调用A。

接口安全问题

• 调用，遍历，未授权，篡改等
• 调用案例：短信轰炸
• 遍历案列：UID 等遍历
• callback 回调 JSONP
• 参数篡改：墨者靶场

在支付中判定支付成功用的就是回调的结果。

callback安全

简要说明：

• 1.由于浏览器的同源策略（域名，协议，ip端口相同），非同源域名之间传递会存在限制。
• 2.JSONP（用于解决跨域数据传输的问题，利用了HTML里元素标签的开放策略src引入Js文件，远程调用动态生成JSON文件来实现数据传递,并以任意javascript的形式传递，一般使用 Callback（回调函数返回，由于没有使用白名单的方法进行限制Callback的函数名，导致攻击者可以自定义Callback内容，从而触发XSS等漏洞）由浏览器的javascript引擎负责解释运行。

原理分析：

1.接口开发时，接收回调函数的参数值在进行拼接前未对恶意数据进行合理化处理，导致攻击者插入恶意的HTML标签并在返回的JSON数据格式原样输出；

2.同时服务端未**正确设置响应头content-type,**导致返回的json数据被浏览器当做Html内容进行解析，就可能造成xss等漏洞。

测试切入点：

• 1.一个使用jsonp技术的接口，参数中包含回调函数的名称(jasonp,callback,);
• 2.服务端返回的json数据时，响应头为 content-type: text/html;
• 3.服务端未对回调函数参数进行过滤净化。

测试步骤：

• 1.设置代理到burpsuite;
• 2.网站根目录开始爬取,重点关注Ajax异步（一般页面只会局部刷新）处理的网页，关注重点业务；
• 3.在HTTP history 标签页过滤功能过滤关键词 Callback，jasonp，等请求，找到URL带有Callback参数的链接。勾选Filder by file extension中的Hider，隐藏js、gif等后缀的URL）；
• 4.查看URL对应得HTTP Response的Content-Type类型是否为text/html且内容是否为json形式（带有json数据的函数调用），如果是我们输入的HTML标签才会被浏览器解析；
• 5.将对应的请求发送到Repeater。在callback参数值的前面加一些类似HTML的标签，如，如callback=Testjsonp1，Go之后发现Response的内容有无影响（HTML有无被转义，没有转义则存在漏洞）。也可将callback参数换为有恶意行为的HTML标签，如callback=jsonp1

八、逻辑漏洞发现案例：

整体流程：

爬虫整个网站–>搜索特定关键字（比如cheackcode,id,callback等）–>快速精准找到有逻辑漏洞的点–>针对性测试

案例步骤：

1.抓取数据包，使用send spider，爬虫功能。

2.提示输入账号密码无视：

3.爬取完成后可以看到网站的目录结构：

4.在抓取的大量数据包中，搜索特定关键字（比如cheackcode,id,callback等）。