0x00 概述
- 本文主要讲解了Web访问控制（越权）漏洞
- 访问控制漏洞多属于高危漏洞，在渗透测试中常发现的问题，而发现之后往往因为系统构架上的问题只能在接口上直接加判断权限的代码，缺乏统一处理及避免之后接口出现问题，漏洞检测难以通过扫描器检测，需要人工发现，不利于系统安全运营
- 本文对访问控制进行拆解，分为认证和授权两个部分，讲解了两个部分多发漏洞的场景，并介绍一些Web系统认证方式和访问控制模型
0x01 漏洞简介
我们按照一般公司成员的组织构架，将权限进行定义，分为垂直和水平两个权限
- 垂直权限
- 按层级划分，组织构架中权力大者拥有更多权限
- 如老板拥有所有权限、部门长拥有本部门所有权限、员工拥有本部门部分权限
- 水平权限
- 同一层级员工对同一功能都拥有编辑权限，但是员工A只能编辑员工A自己文章、员工B只能编辑员工B自己的文章
- 也就是相同功能下可操作的数据不同
访问控制（Access Control），它是限制主体（subject）访问客体（object）的一种方式，在上面的组织构架中，主体是公司成员、客体是权限
所以首先，我们谈到Web越权漏洞，Web访问控制，我们要明确，在Web系统中什么是主体，什么是客体
- 主体是用户，或者说，持有身份验证信息（cookies等）的HTTP/S数据包是主体
- 客体是Web应用的功能接口（垂直权限）和数据（水平权限）
在渗透测试中，有时候很难和开发测试解释清楚这个系统为什么越权了，因为可能部分开发测试不理解前端已经做了限制为什么还有越权漏洞。简单来讲，按上面规则，这种前端限制而后台未作限制的情况是搞错了访问控制的客体，也就是对接口和数据的限制用到另外的客体（前端按钮、界面）上
其次，我们要明确访问控制过程主体访问客体的步骤
- 身份标识
- 提供身份标识信息的主体
- 用户名、ID、账号
- 身份验证
- 验证身份标识信息
- 密码、pin、生物识别、Token
- 访问控制
- 判断主体是否有权限的机制
- 可问责性
- 跟踪主体对客体所执行活动的审计日志和监控，包括入侵检测
在Web系统中，可问责性这个步骤往往需要另一些系统（监控系统、审计系统、WAF等）来完成，因此单个系统我们主要聚焦前三个步骤
而前三个步骤实际上可以分为认证（Authentication）和授权（Authorization）两部分
- 认证的目的是为了认出用户是谁
- 首次登录输入的用户名密码
- 维持登录态的Cookie
- 多因素认证的验证码、二次验密
- 改密邮件、CSRF的token验证
- 授权的目的是决定用户能够做什么
- 接口限制（垂直权限访问控制）
- 数据内容限制（水平权限访问控制）
因此，越权漏洞就是发生于上面步骤中的认证措施失效（主体认证无效，多见于水平权限越权漏洞）和授权措施失效（客体防御无效，多见于垂直权限越权漏洞）
其实越权漏洞就是系统逻辑有问题，没什么好介绍的，大家都懂，就是大家都没从设计时就管它，然后被发现了要补了就很麻烦，有的系统分级很多，有时候权限多样不能从一个中间件统一修改，系统做大了接口多也不能每个接口都写段控制代码做限制
这里要是不懂垂直权限漏洞就需要明确数据和接口是Web应用中最重要的东西，补补Web应用是怎么工作的，从前端到HTTP/S包到后端，不明白水平权限漏洞，可以看下面的威胁场景
0x02 威胁场景
普通垂直权限漏洞
系统有权限分级，但只有前端做了访问控制，也就是隐藏了按钮，没有对后台接口和数据进行访问控制，或者只是对部分接口进行了控制，漏掉了一些
普通水平权限漏洞
举个遇到过的例子
某个系统的暂存工单功能曾经有这样的漏洞，暂存数据的的URL是：xxxx.xxxx.com/xxx/xxx/index.spr#/xxx?param={temporaryId:1467,caseKind:security}存在水平权限越权漏洞，当我们修改url中的temporaryId参数可以看到他人的数据，这个漏洞的问题在于
- 暂存数据没有对用户进行鉴权，只是在后台通过ID进行查询
- ID是顺序加法的4位数，不是随机的，可以容易被人猜到或者暴力破解（当然，URL可能在proxies、日志上留下记录，就算ID随机不可猜解还是可能被别人拿到，所以还是鉴权最重要）
最后吐槽一下这个接口URL，#在URL中一般指锚点，浏览器可能在这里因为自定义解析方式解析为路径，在URL中用#:这些指代不清的符号可能导致解析错误，山寨浏览器效果更加，不一定会产生安全漏洞，这样的指代不明确的URL还是少点好
字典、暴破攻击
存在这样的情况，系统管理台或后门或一些特权路径因为程序员不想暴露在外，用特殊路径访问，比如xxx.com/abcdefg20100101/这样，页面无连接指向这个路径，爬虫爬取不到，这种情况下黑客可能通过自己经验进行暴破，最终访问到这个路径，造成垂直权限越权
还有比如xxx.com/2018-03-15-title这种内容管理系统或者博客的路径命名方式，容易被黑客收集的字典访问到，造成水平权限越权。
上面这两种路径而普通情况下访问也可能在proxies或者日志中留下记录，所以不要用这种方式进行访问控制
登录欺骗
- 诸如CSRF或者点击劫持这样的前端漏洞，在用户不知情的情况下利用用户登录的身份进行了操作
- XSS或者通过Proxies窃取用户身份凭证（Cookie等）仿冒用户凭证
- Session Fixation攻击或者Session保持攻击仿冒用户凭证
- 上面这些虽然也算越权一种，但一般归为其他漏洞
网络钓鱼
钓鱼获取用户密码等信息，这种非系统本身存在问题
竞态条件
两个不同进程分别不用主体的身份在同一客体上执行任务，因为缺乏锁读取或修改了其他主体的信息
其他一些逻辑错误
- 改密逻辑错误
- 改密分为原密码验证和修改密码两个页面，先验证原密码是否正确，再修改密码
- 实际没有在修改密码时验证上一步验证密码的结果，可以直接修改任何用户的密码
- 邮件Token逻辑错误
- 一些操作需要向用户发送邮件带有特殊随机Token串的URL，用户点击后验证生效
- 开发过程中为了测试方便，点击发送邮件时将随机Token传回Response包中，导致Token泄露
- 不安全的身份鉴别、登录态维持算法
- 将用户登录态存放在URL中，用Cookie维持登录态，Cookie不安全的加密方式可被伪造等
- 其他一些和业务属性相关的问题
0x03 修复方式
访问控制漏洞产生主要出于两个方面
- 设计时完全没有考虑访问控制，没有对主体和客体进行正确的鉴别于防护
- 业务逻辑复杂，一些没考虑到的数据操作没有进行准确的身份鉴别
我们的修复方式也出于以上两种产生原因区分开来
一种是没有设计正确的访问控制方式
- 临时修改：在所有访问接口添加权限控制代码，手工加，每个接口分别做判断，之后新增或者修改的接口注意，后门或者特殊特权路径接口关闭
- 框架上添加访问控制
- 认证：在了解框架登录态维持方式（Cookie、Session）的情况下使用框架的登录态维持方式，不了解或者不想去了解就使用主流、生态圈广的框架，见《Web访问控制——认证》
- 授权：推荐使用RBAC（Role-Based Access Control）模型建立访问控制，见《Web访问控制——授权（RBAC模型）》
一种是业务逻辑复杂导致的疏漏
- 多见于水平权限漏洞，不同场景不同
- 及时修改，可考虑在DAO层添加数据访问的控制
0x04 深入攻防
还是从认证和授权两个方面来看
授权方面
上面说了权限漏洞没有什么可说的，大家都懂的，只能说见过的业务场景多了，哪里可能导致越权操作的发生容易被有经验的安全人员看出（恶意黑客或渗透测试人员），在没有垂直权限控制的系统中很容易检测出来，水平权限访问控制的漏洞一般测试感觉上用于查询的Key
认证方面
认证方面导致的问题比较多，很多逻辑问题都可能导致用户的身份凭证信息被伪造、被篡改、被恶意用户获取
比如上面提到的邮件Token被获取、改密绕过原密码验证等逻辑问题
认证方面的安全检查其实很有意思，因为很多时候用户的凭证信息用了一些密码学知识，而不正确使用很可能导致一些问题，详情可见《Web访问控制——认证》，会举一些案例
检测方式
越权漏洞检测是一种见多识广的能力，很多靠经验和遇到过的场景能猜测出某个地方是否有可能存在越权
认证方面主要看用户凭证生成和使用方式，一般需要代码审计，容易在加密方式或者随机数生成上不够安全，产生可以被伪造的地方，需要在了解凭证生成和使用方式的情况下进行评估判断
授权方面的问题可以用多个账号，垂直水平不同权限的账号，分别用他们的登录凭证去访问他们可以访问的接口，测试是否越权访问到了其他人的信息
一般使用Burp Suite被动抓包的方式尽可能多的访问功能接口，使用到的功能越全面，漏过的接口越少，就越不容易漏过漏洞
如果有接口文档，可以固定多个账号凭证自动化去访问所有接口，判断是否有越权情况发生，当然不如人工发现有效，因为水平权限漏洞容易漏过
0x05 总结
- 多了解一些特殊案例，尤其认证方面其实很有意思
- 认证方面了解用户凭证生成和使用方式，最好使用一些主流和社区范围广、经过考验的开发框架
- 授权方面系统设计时使用RBAC权限模型、水平权限也有一定考虑
0x06 参考资料
《CISSP考试认证指南》
