本篇是对去年渗透测试遇到的越权攻击进行一下总结，下面总结的照片实例，均已进行脱敏处理，可放心食用。

前言

从狭义上讲越权访问，是攻击者在获得低权限用户的账户后，可以利用一些方式绕过权限检查，访问或者操作到原本无权访问的高权限功能。

这类漏洞往往很难通过工具进行自动化检测，属于逻辑漏洞中的一种，目前存在着两种越权操作类型，如下图所示：

横向越权：攻击者尝试访问与他拥有相同权限的用户的资源

示例：购物系统中A用户可以可以查询到B用户的订单信息。

纵向越权：攻击者可以使用低权限的账户去使用高权限账户的功能。

示例：原本没有删除功能的用户A可以使用管理员用户的删除功能删除了管理员用户中的数据。

但是从广义上讲还包括一种“未授权攻击”，这种漏洞类似于越权攻击中的纵向攻击，攻击者没有获取到登录权限或未授权的情况下，或者不需要输入密码，即可通过直接输入网站控制台主页面地址，或者不允许查看的链接便可进行访问，同时进行操作。

无论是在我日常渗透测试中还是在自身参加的众测项目中，因鉴权不当产生的越权攻击也越来越多。

对于厂商来说，此类问题危害性极大，攻击者可以突破登录、身份验证等手段控制后台功能或越权到高权限身份。

所以这篇文章我将从几种场景的角度来展开介绍实战中的越权攻击。

登录

1 未授权访问

未授权访问也可大致分为三种，第一种是直接通过修改响应码的状态，第二种通过直接链接访问从而绕过登录限制，第三种人为疏忽的导致的问题。

1.1 修改响应码登录

不同系统采用的响应码各不相同，一般都是通过抓包查看JS文件，来判断如何修改。也可以采用简单粗暴的方式，例如直接登录查看正确的响应码或者是直接猜！

常见响应码：200、000000、true、0、success、ok、1等等（排名不分先后，全凭个人经验）

示例：

JS文件可以查找到准确的响应码

注：

在正确设置后端检验的情况下，即使修改响应码后，仍然会跳回登录界面。而可以通过修改状态码进行登录的，一般分为以下两种类型：

第一种：后端未作验证，修改状态码就可以直接绕过权限检查，可定级为高危漏洞。

第二种：后端做了验证，修改状态码后仍然会显示后台页面，或是泄露后台部分的功能接口，但是没有数据和操作权限，可定级为低中危。

修复方式：

修改验证逻辑，如是否登录成功服务器端返回一个参数，但是到此就是最终验证，不需要再对返回的参数进行使用并作为登录是否成功的最终判断依据。

1.2 URL的直接访问

一般通过目录扫描、FUZZ、猜解等方式获取到后台路径从而达到直接访问后台功能的目的或者是使用JSFinder搜索源代码中调用的地址（成功率很高，强烈推荐）

Tips:

• 目录扫描工具推荐使用Dirmap、Dirsearch，个人比较推荐使用Dirmap加字典的方式。

• JSFinder：推荐使用Tampermonkey下的脚本。

• 若甲方提供测试账户，可以先行登录获取部分链接，然后待退出登录消除凭证后，查看是否能重新访问这部分链接。

示例:

直接访问JSFinder爬取到链接，查看是否存在未授权的情况

注：

扫描目录的时候除了未授权的后台页面，也需要同时关注以下几种漏洞：目录遍历、任意文件上传下载、API接口泄露。

修复方式：

禁止目录扫描，并提前做好自我检查，使用递归的方式检查自己的目录以及检查网页中的站点是否存在未授权的路径。

1.3 密码直接暴露

这里需要注意的是下面示例中账户本下载的情况并不多见，较多情况是直接编写在前端源码中，例如“密码提示框”中或是单纯的隐藏在源码，因此在测试的时候需要注意关注网页源代码。

示例：

这个案例是将账号本链接暴露在前端，从而导致攻击者直接获取了登录的账户密码。

在登录界面可以发现存在一个“账号名单”，尝试下载

点击“账户名单”后下载的密码本

修复方式：

同样是提前做好自我检查，检查是否存在是不是违规或者是敏感的信息泄露。

2. 身份信息/登录信息伪造

开发者为了方便将身份信息/登录信息明文或者只是简单编码、加密之后存放在链接中或是数据包中，网站通过这些信息进行授权或者身份验证。

常见测试就是修改URL和响应包中鉴权参数造成的，鉴权参数大抵就是id、username、login、session、cookie、token等。例如某些系统修改Login=1、修改UserName=admin均可以被系统判定为管理员登录。

注：

此处的加密特指MD5加密，也有极少数能同时泄露密码、公私钥的加密算法。

示例1：

这个案例是通过直接添加token字段的UUID值来构成未授权访问

示例2：

这个案例就可以从响应包准确的看到加密算法为：AES，加密模式：CBC，填充：zeropadding，数据块：128位，密码：XXX，偏移量为：XXX。

只有同时集齐这么多信息才能破解登录数据。

qqaAAAAAAAAAAAAA`

Tips:

常见的解码网址：

URL解码：http://www.jsons.cn/urlencode/

Base64解码：https://base64.us/

MD5解码：https://cmd5.com/

AES解密：http://tool.chacuo.net/cryptaes

以及个人使用频率很高的utools解编码插件，由于utools的快速呼出机制，因此在这里解码尤为方便。

PS：这东西简直是安服居家旅行必备好物，墙裂推荐！这里面还有很多小插件，有兴趣的话大家可以继续探索。

数据

在这一场景下，基本都是登录的情况下，因此参数也不在局限于身份信息了，更多的为手机号、ID number、卡号、员工编号、日期、账单编号，还有部分是自定义的参数，极少数是通过插入随机数然后取特定的几位数（防御较好的站点这些部分仍然会被进行加密），如下图所示：

当然也有部分个例采用的是JWT方式隐藏特定参数，然后通过解密进行校验。

从当前测试的站点来看，数据层面出现的越权占据越权的一半以上，而这一半中至少80%为横向越权。

而数据层面也大致分为以下三种：身份信息伪造、数据篡改、流程越过

1. 身份信息伪造

与上同，这部分仍然是对身份信息的校验，这部分的信息使用明文或者只是简单编码、加密进行存放都有可能构成越权。

示例1：

首先我们通过一个账户A在此接口进行查询，通过分析数据包就可以发现参数accountNo为身份控制参数。

在此接口查看账户B，此处由于账户原因，导致没有账户明细，但是已经显示可以成功查询

示例2：

与示例1的情况基本相同，此时的身份控制参数直接出现的URL中，可以更加便捷的发现越权情况。

使用账户A查询，发现出现自定参数partnerId

在此接口遍历参数partnerId，成功返回其他账户信息。

注：

关于鉴权参数的检查是贯穿整个测试流程的，望各位师傅谨记。每个功能点都有可能因为鉴权失效而构成越权攻击。

修复方式：

身份信息必须进行加密传输，要采取标准的加密方式进行加密，并保存好密码，尽量不要使用base64编码，即使使用base64传输，也需要加入脏数值来进行混淆，尽可能的增加攻击者破解的难度。

2. 数据篡改

常见的数据修改一般为正负值反冲、修改订单数据、修改商品ID等，以前憧憬一分钱买一大堆零食，现在干了就喜提白银手铐一副。值得注意的是，例如sendXX、XXmessage这部分可以进行接口的爆破，以此来构成短信/邮件轰炸。

参数大多为：value 、price 、amount 、number 、XXID、pid 等。

示例：

通过修改参数值以达到越权增删改查的横向越权漏洞

抓包截取当前的数据包，通过修改Price的相关参数，均修改为负数，从而来构造恶意的请求

可以看到此处的价格已经被成功修改

修复方式：

针对数据的越权修改也有较为成熟的修复方法，可以根据商品ID、订单金额等数据生成这个订单专属哈希值，验证的时候服务器需要根据当前数据包内金额再次生成哈希值与第一次做匹配；

除此之外，一些特定的机构还可以额外添加大额交易人为审核的措施，保证资金安全。

3. 流程越过

攻击者越过中间校验步骤直接进行后续操作，导致中间校验等步骤失效。

通常的测试思路基本就是，首先完成正常的业务逻辑步骤，获取每一个步骤的请求，再绕过中间步骤直接访问最后一个或几个的验证请求，查看是否能成功请求。

流程越过在密码修改/重置处、购买商品上出现的比较频繁，各位师傅可以重点留意这些测试点。

示例：

这个案例就是通过直接访问最后一个接口信息，来达成的流程越过。

正常逻辑下完成付款步骤

代码部分

从源码可以看出通过访问接口/shoufei，就可以直接完成缴费请求

下面尝试跳转逻辑

重复上述操作，再次添加一次100元的CT项目

然后直接访问/shoufei接口,此处的33，就是上述步骤中的订单据号

返回数据几即表示缴费多少条订单，这里只有一个订单，因此返回1

修复方式：

在每个步骤的session都应该添加标识位，并将session与用户的身份进行强绑定并且在新步骤显示之前必须要检测之前每一步的 session标志位。

而关于密码修改的地方还可以使用一次性填写所有的校验信息，例如原始密码、新密码等信息后再提交修改/重置密码请求。

总结

在日常的测试中需要关注任何场景每一个可能决定用户权限的参数值，注意GET、POST的传参，把握传参，就能把握住越权的命脉。

当然，还有一些常见的测试方式：

当对一个有注册功能或是存在身份认证的站点，可以申请两个不同账户来进行横向越权测试，如果甲方爸爸同意的话，最好是提供一个管理员权限的账户和两个普通的账户，以此来完成完整的纵横越权测试。例如使用账号C的token或者是cookie去替换账户A的信息来测试功能。

分析每个参数的功能，尽可能的多去尝试修改，例如任意加减参数值或将false修改为true/success会发生什么、执行某一操作的时候删除 Cookie或 Token后是否仍能触发功能。

同时，我们也可以思考一下：

A拿A的钥匙，开B的锁，这叫锁有问题。A拿B的钥匙，开B的锁，锁还有问题么?

大门里的东西，包含小门里的东西，如果大门进去能够看到小门的东西，算不算问题？如果小门进去能看到小门里面东西之外的其他大门所有东西，算什么问题？

A、B两个不同的门，进去的东西不相同，A门进去之后有办法看到B门的东西，算什么问题？

Tips：

火狐插件Multi-Account Containers可以提高平时我们测试时候的效率，它通过使用不同的容器，让不同的颜色来区分不同的账户。

追根结底，越权漏洞的本质就是看到当前用户本不该看到的数据，执行本不该执行的操作。

作者：一线卑微安服仔

原文地址：https://www.freebuf.com/vuls/313396.html

如侵权请私聊我们删文

多一个点在看多一条小鱼干