一、越权访问
越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞，由于其存在范围广、危害大，被OWASP列为Web应用十大安全隐患的第二名。
1.1越权访问的产生
比如，某个订单系统，用户可以查询自己的订单信息。A用户查询订单时，发送的HTTP请求中包含参数“orderid=A”，订单系统取得orderid后最终会查询数据库，查询语句类似于“select * fromtablename where orderid = A”。B用户查询订单时，发送的HTTP请求中包含参数“orderid=B”，系统查询数据库语句类似于“select * fromtablename where orderid = B”。正常情况下，每个用户只会查询到自己的订单。但是，当B用户将自己的HTTP请求参数修改为“orderid=A”，那么最终B用户执行的数据库语句变成了“select * fromtablename whereorderid = A”，导致A的订单信息被B用户获取到了。
一般来说，网站设计者会用户的访问进行权限校验，确保用户仅能访问到属于自己的资源，但是业务复杂到一定程度之后，诸如此类的数据如此之多，从订单信息，到地址数据、支付信息等等，无一不需要小心处理。一旦有所疏漏，就会产生越权访问漏洞。
1.2越权访问的种类
越权访问分为垂直越权访问、水平越权访问和交叉越权。
垂直越权是指不同用户级别之间的越权，如普通用户执行管理员用户的权限。水平越权是指相同级别用户之间的越权操作。
1.2.1水平越权
假设用户A和用户B属于同一角色X，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫做水平越权访问。
1.2.2垂直越权
垂直越权又叫做权限提升攻击。其原理是由于Web应用没有做权限控制，或仅仅在菜单上做了权限控制，导致恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。
1.3越权访问的测试
本文以三员系统为例，首先介绍一下三员系统。
三员系统初始就有三个不同权限的管理员：系统管理员、安全保密管理员、安全审计员，三员之间是平级的但主体功能各不相同。此外根据不同Web系统的需求还会出现三员用户的子用户和普通用户，普通用户中可能还会分出不同权限的用户（如：操作员、监控员等等）。
三员系统为了满足保密产品的安全需求导致用户权限划分细致且众多，相较于普通系统权限判断更加繁多也更需细致，因此权限控制难度更高，导致三员系统出现越权漏洞的概率越高
1.3.1三员之间的交叉越权
登录A管理员，执行A管理员的功能x，抓取保存x功能包。退出A管理员，登录B管理员，抓取B管理员的COOKIE，将x功能包中的COOKIE替换成B的COOKIE，发送x功能包。通过响应包或到x功能的Web页面处查看请求是否成功，成功则存在越权漏洞。
以上是越权通用的测试方式，但实际测试中要注意以下几点：
1.一般Web应用是通过COOKIE里的信息来认证用户身份的，但并不是所用Web应用的是如此的。遇到身份认证不是COOKIE的Web应用，要替换的就是该系统认证身份的地方而不是COOKIE。如下图就是COOKIE认证登录状态，jitabc认证用户身份。
2.遇到有COOKIE共用(多次登录同一或不同用户COOKIE相同)的Web应用时，因为COOKIE不变并不需要替换COOKIE直接替换Web的当前用户就能直接发送请求来测试。但这时候未授权漏洞和COOKIE退出不清除的问题会影响越权漏洞的验证，要在验证越权前先确定未授权漏洞和COOKIE退出不清除这两个问题不存在。
3.三员之间的交叉越权最常出现在同一功能不同权限处。如：系统管理员和安全保密管理员都有用户这个功能模块，但仅有系统管理员有添加用户的功能，仅有安全保密管理员有赋予用户权限的功能，在程序对功能模块进行身份验证但对其中的子功能缺乏验证时就会出现越权漏洞。
1.3.2三员管理员的垂直越权
本漏洞是在用户有某一功能的权限且增删改查的值有限制但限制不完善的情况下，会出现的问题。
例：
三员管理员可以添加自己权限的子用户。抓取系统管理员的用户角色添加功能，其中存在roles=1的字段，可能是角色控制的值，修改为roleid=2继续发送发现请求成功，在Web端查看该用户已被赋予安全管理员角色，很明显存在越权漏洞。
注意：
1. 在实际测试中可能不会出现roleid这样明显的角色字眼，这时候就要认真分析和尝试出请求中每个字段的意义，在进行测试。
2. 该漏洞常出现在用户添加、赋予角色等跟用户角色相关但有限制的地方，一旦程序限制不完善就会出现漏洞。
1.3.3三员子用户/普通用户的垂直越权
登录C管理员，执行C管理员的功能y，抓取保存y功能包。退出C管理员，登录D三员子用户/普通用户，抓取D的COOKIE，将y功能包中的COOKIE替换成D的COOKIE，发送y功能包。通过响应包或到y功能的Web页面处查看请求是否成功，成功则存在越权漏洞。
与1.3.1类似，不同是的利用低权限用户的身份执行高权限用户独有的功能。
1.3.4三员子用户/普通用户的水平越权
登录E用户执行E用户的功能z，抓取z功能包将其中的用户识别id修改为F用户的（如E修改密码时抓取到功能包：username=E&passwd=123,修改成username=F&passwd=123），发送请求测试F用户对应的功能是否被修改，成功修改则存在越权漏洞。
二、未授权访问
未授权访问漏洞可以理解为需要安全配置或权限认证的地址、授权页面存在缺陷导致其他用户可以直接访问从而引发重要权限可被操作、数据库或网站目录等敏感信息泄露。
常见的第三方未授权访问漏洞：
1.MongoDB 未授权访问漏洞
2.Redis 未授权访问漏洞
3.Memcached 未授权访问漏洞CVE-2013-7239
4.JBOSS 未授权访问漏洞
5.VNC 未授权访问漏洞
6.Docker 未授权访问漏洞
7.ZooKeeper 未授权访问漏洞
8.Rsync 未授权访问漏洞
以上都第三方的未授权漏洞，如果Web系统中有用到以上组件，就要及时更新该组件修复漏洞。Web应用本身也存在未授权漏洞，常见有以下两类：
1.没有作任何的用户身份认证手段。
2.一些特定的页面或文件未做认证。
第一类问题的测试只需要随意抓取用户功能，将其中的用户认证信息（COOKIE等）清空或修改然后发送，若请求成功便存在未授权漏洞。
第二类问题测试方式与第一类问题一样，只是特定的页面或文件才存在。一般常见于：可文件、用户手册、Web应用新添加的功能页面。
三、认证信息失效机制问题
用户正常注销退出后，用户的认证信息不会立刻失效。用户认为自己已经退出账号，但在服务端中保留用户登录状态，依然可以用认证信息进行请求。因此在要求单次登录有效的应用系统中，用户正常退出或注销应将服务端认证信息进行注销。
四、结语
在上述安全问题测试方法的前提是获取到其他用户认证信息，而实际应用场景中需要获取其他管理员认证信息虽然很困难，但在现今层出不穷的网络攻击手段下，我们不得不关注这些安全问题的本身。造成“三员”中越权问题的主要原因在于对于身份认证不严格，角色和功能绑定存在遗漏，因此在企业重要的应用系统中建议在服务端进行用户和角色的一对一验证，角色和功能的一对一验证，或者用户和功能的一对一验证。
*本文作者：nercis，转自FreeBuf