文章标题

一、简述

  越权漏洞是比较常见的漏洞类型，越权漏洞可以理解为，一个正常的用户A通常只能够对自己的一些信息进行增删改查，但是由于程序员的一时疏忽，对信息进行增删改查的时候没有进行一个判断，判断所需要操作的信息是否属于对应的用户，可以导致用户A可以操作其他人的信息。也可以：越权漏洞是一种很常见的逻辑安全漏洞。可以这样理解：服务器端对客户提出的数据操作请求过分信任，忽略了对该用户操作权限的判定，导致攻击账号拥有了其他账户的增删改查功能。

二、越权分类

 一般情况下，常见的访问控制方式有三种：垂直访问控制、水平访问控制和上下文相关的访问控制。垂直访问控制允许不同类型的用户（常见的有基于角色划分用户类型）访问应用程序的不同功能，例如在某系统中普通用户只能执行有限的操作，管理员则拥有最高权限。水平访问控制允许用户访问一组相同类型的资源，如在一个网银系统中，每个用户只能看到他自己的账户信息，只能操作自己的账户进行转账。而上下文相关的访问控制可确保基于应用程序当前的状态，限制用户仅能访问所允许的内容，如在常见的找回/修改密码功能中，必须通过身份验证才能重新设置密码。许多情况下，垂直访问控制与水平访问控制会相交交叠，配合使用。如果在一个应用中，用户能够访问他本身无权访问的功能或者资源，就说明该应用存在访问控制缺陷，也就是说存在越权漏洞。与访问控制相对应的，将越权分为垂直越权、水平越权和上下文相关的越权。

垂直越权

如果攻击者能够执行某项功能，而他所属的角色并不具备该权限，这就存在垂直越权漏洞，

水平越权

如果攻击者能够执行与自己同级别的其他用户能够执行的操作，这就存在水平越权漏洞

交叉越权（上下文相关）

如果攻击者能够利用应用程序状态机中的漏洞获得关键资源的访问权限，这就存在上下文相关的越权

三、产生原因

通常情况下，我们使用一个web应用程序提供的功能时，流程是：登录—>提交请求—>验证权限—>数据库查询—>返回结果。如果在“验证权限”环节存在缺陷，那么便会导致越权。一种常见的存在越权的情形是：Web应用程序的开发者安全意识不足，认为通过登录即可验证用户的身份，而对用户登录之后的操作不做进一步的权限验证，进而导致越权问题。

通过隐藏URL实现访问控制

有些应用程序仅通过URL实现访问控制。例如：使用管理员身份登录后可以看到后台管理页面的链接，但是以普通用户登录则看不到该链接。在这种情况下，开发者认为普通用户不知道或者很难猜到后台管理页面的URL，因此实现对管理功能的保护。这其实是一种错误观点，因为攻击者完全有可能通过其他方式（如Google Hacking、HTML/js源码分析、暴力猜解URL、利用其他漏洞等）得到后台管理URL。

直接对象引用（Direct Object reference）

用户提交HTTP请求访问某资源时，被请求资源的标识符常常以GET或者POST请求参数的形式出现在URL查询字符串或者POST请求主体中提交给服务器。例如，在一个网银系统中，用户可以使用以下URL查询账户信息：1https://www.onlinebank.com/viewInfo.php?accountId=12345678
其中accountId是用户自己的账户ID。用户登录自己的账户后，该URL的链接会出现在用户账户页面中，用户点击即可跳转到账户信息页面。虽然其他用户无法看到这个链接，但是如果该网银系统的访问控制不完善，攻击者完全可以通过枚举accountId进而构造出URL，然后越权查看他人的账户信息。

静态文件

有些Web应用程序在用户访问动态页面时会执行相应的访问控制检查，以确定用户是否拥有执行相关操作所需的权限。但是，用户仍然会提交对静态资源的访问请求，如下载网站中的word、excel、pdf文档等。这些文档都是完全静态的资源，其内容直接由Web服务器返回，它并不在服务器上运行。因此，静态资源自身并不能执行任何检查以确认用户的访问权限。如果这些静态资源没有得到有效的保护，那么任何知晓URL命名规则的人都可以越权访问这些静态资源。这种情况的越权也很常见，而且即使不知道URL命名规则，完全有可能通过Google hacking搜索到敏感文件。

平台配置错误

一些应用程序通过在Web服务器或应用程序平台层使用控件来控制对特定URL路径的访问。例如，有些应用程序会根据用户角色来限制对管理后台路径（如/admin）的访问，如果用户不属于“管理员”组，则拒绝其访问后台管理页面的请求。但是，如果在配置平台及控件时出现错误，就可能导致越权访问。

四、如何挖掘越权漏洞

首先，找出疑似存在越权漏洞的请求。存在越权漏洞的请求有一定的特点，可以从两个方面下手。从HTTP请求上来说，就是通过BurpSuite抓取在目标站点正常操作所产生的请求数据包，然后找出可能产生越权的请求。一般情况下，类似上文所述URL的GET或者POST请求都要列为重点怀疑对象：
1https://www.onlinebank.co/viewInfo.php?accountId=12345678，从业务功能上来说，找到容易产生越权的功能点。

这时，需要两个不同的账号（下文分别称为账号A和账号B），以便测试登录账号A后进行操作能否影响到账号B。注意在浏览器中测试时，需要使用两个浏览器分别登录不同的账号，或者使用浏览器的隐私浏览功能登录其中一个账号。以上文提到的URL为例进行说明。假设账号A的id为1234，账号B的id为5678，BurpSuite中抓取的数据包都是在账号A的。我的习惯做法是：在BurpSuite中将该请求发送到Repeater，然后将参数id的值修改为5678，最后提交修改后的请求包；服务器返回响应后，可以看一下BurpSuite中收到的响应报文。如果响应报文直接提示错误之类的，基本上可以确定此处不存在越权；如果响应报文提示操作成功，此时应该使用浏览器登录账号B进行二次确认，如果数据确实有相应的改动，那么则说明这里存在越权漏洞。

这里需要注意：BurpSuite中报文提示操作成功有可能是误报，必须在浏览器中进行再次确认。而对于查询订单这类的请求来说，情况更简单了，修改参数id提交请求，如果返回了账号B的数据，那么就可以确定存在越权。当然，越权漏洞的攻击点不仅仅存在于请求参数中，还有可能在Cookie中。因此，需要具体情况具体分析，复杂一点的可能还需要Cookie值配合请求参数值以实现越权攻击。

实例

  白帽子 路人甲：帮朋友挑选一款汽车时，登录了某品牌的官网，无意中看到了旗下的招聘系统网址，http://rec****.***.cn/re****t***t/resume/addresume/person_id/161101/lid/1/job_id/1，这个网址就比较有趣了，person_id代表的是应聘用户的账号，161101意味着用户数量超过16万，如果存在越权漏洞，那么修改一次161101这个数据，就可以看到一个用户的应聘数据。经过测试还真的是这样。

漏洞标题： 同花顺某处鉴权可被遍历导致用户信息泄露
详细说明：http://cats.10jqka.com.cn/catreqtype=cs_query_func_list&userid=11122233&cf_id=203&resp=xml&encoding=gbk&Cfg_id=1&showorder=1
userid 可以任意遍历，cf_id 产品id 也可以任意遍历
userid 任意修改，就能查询任意用户的购买产品信息

非原创

参考文献

[https://xianzhi.aliyun.com/forum/read/313.html]
[https://www.secpulse.com/archives/54137.html]