本文中提供的例子均来自网络已公开测试的例子，仅供参考。

　　本期斗哥带来越权漏洞和大家探讨探讨。什么是越权呢？

　　越权，顾名思义，就是超出了权限或权力范围。多数WEB应用都具备权限划分和控制，但是如果权限控制功能设计存在缺陷，那么攻击者就可以通过这些缺陷来访问未经授权的功能或数据，这就是我们通常说的越权漏洞。攻击者越权后就可以进行一些操作，例如查看敏感信息、进行一些增删改查的操作等等。

　　我们一般将越权漏洞分为三种：水平越权、垂直越权和权限框架缺陷。以下是越权漏洞的几种攻击场景。

　　水平越权

　　水平越权指的是攻击者尝试访问与他拥有相同权限的用户的资源，怎么理解呢？比如某系统中有个人资料这个功能，A账号和B账号都可以访问这个功能，但是A账号的个人信息和B账号的个人信息不同，可以理解为A账号和B账号个人资料这个功能上具备水平权限的划分。此时，A账号通过攻击手段访问了B账号的个人资料，这就是水平越权漏洞。

　　系统中所有具备水平权限划分的功能，都存在水平越权的风险，以下是常出现的水平越权的功能的几种场景：

　　1. 基于用户身份ID

　　在使用某个功能时通过用户提交的身份ID（用户ID、账号、手机号、证件号等用户唯一标识）来访问或操作对应的数据。

　　举个栗子：

　　①某航空公司存在水平越权漏洞，提交订单后抓取数据包。

　　②可以发现请求中有蛮多ID信息，通常情况下，我们一般会挨个测试，是否存在越权漏洞，其中passenger1d1是乘机人，contactId联系人。

　　③经测试可发现这两个参数修改后，可查看到其他乘机人的身份证及联系人信息。

　　2. 基于对象ID

　　在使用某个功能时通过用户提交的对象ID（如订单号、记录号）来访问或操作对应的数据。

　　举个栗子：

　　①某系统存在水平越权漏洞。

　　②抓取订单提交的数据包，发现有一个oid很可疑。

　　③尝试进行测试发现，可遍历订单号，查看他人待付款订单信息。

　　3.基于文件名

　　在使用某个功能时通过文件名直接访问文件，最常见于用户上传文件的场景。

　　举个栗子：

　　②遍历fileid可以下载到数十万的资质文件：

　　http://**.**.**.**/sFile-image.action?fileid=9316

　　http://**.**.**.**/sFile-image.action?fileid=39316

　　垂直越权

　　垂直越权指的是一个低级别攻击者尝试访问高级别用户的资源。比如说某个系统分为普通用户和管理员，管理员有系统管理功能，而普通用户没有，那我们就可以理解管理功能具备垂直权限划分，如果普通用户能利用某种攻击手段访问到管理功能，那我们就称之为垂直越权。

　　垂直越权主要以下两种攻击场景：

　　1.未认证账户访问无需认证后能访问该功能。

　　举个栗子：

　　①某站点后台仅使用js跳转来限制未授权的用户访问。

　　②去掉js可以成功访问后台，且可以进行操作。

　　2. 不具备某个功能权限的账户认证后成功访问该功能。

　　举个栗子：

　　①使用default用户名和密码：useradmin / admin!@#$%^登录系统。

　　②成功登录后台。

　　③依次点击“对象管理——>用户管理——>编辑‘useradmin’——>得到URL：*.*.*.*/cgi-bin/webif/Objset-users.sh?edituser=edituser&id=5”

　　④修改参数id为：id=4，成功垂直越权telecomadmin。

　　⑤查看源码，可读取telecomadmin密码：telecomadmin34224223，至此已获得最高管理员权限，可以完全对该设备进行操作。

　　⑥由下图可判断出telecomadmini为高权限用户。

　　权限框架缺陷

　　权限控制框架是实现权限控制功能的基础，如果权限控制框架本身存在缺陷容易被攻陷会导致权限控制功能完全失效。在cookie中使用简单的权限标识来标记用户的权限等级或使用用户请求参数中所带的简单用户ID来控制用户权限，是典型的权限框架缺陷。

　　举个栗子：

　　①某系统存在弱口令：guest、guest，访问http://**.**.**.**/nbr.htm，然后登进去 只能看到系统首页和流量监控。

　　②然后用cookie修改工具，先登录guest账号。

　　③然后修改cookie信息，user=guest 改成user=admin 重要的是需要后面删掉分号。

　　④然后刷新。

　　⑤admin账号拥有更多的功能，可以修改管理员密码等。

　　修复意见

　　好啦，上面就是斗哥近期整理的一点越权漏洞栗子，越权漏洞可大可小，那我们要怎么控制呢？

　　1.采用成熟的权限管理框架，如spring security。

　　2.用户进行访问操作的凭证（如用户ID、产品号码、订单流水号等）优先采用在服务端关联session或加密后放在session中的方式获取。

　　3.必须采用表单或其他参数提交用户进行访问操作的凭证（如用户ID、产品号码、订单流水号等）时，应尽可能采用难以猜测的构造方式（增加字母及随机数字等）或采用复杂的加密算法加密后提交，应对客户端提交的凭证与会话的权限进行严格的验证，如提交的产品号码是否为隶属于登录用户的产品号码。

　　4.对管理功能模块进行严格的权限验证，如非必要建议不对互联网开放或进行网络层的访问控制。

　　专栏