Appearance
16逻辑漏洞：你的订单信息是如何泄露的？
本节课开始介绍越权漏洞，这是一种偏业务逻辑处理缺陷的漏洞，不仅是 Web 应用，许多应用场景中会可能会遇到。
比如去年 12 月底，因北京健康宝网站存在越权漏洞，导致了"明星健康宝照片泄露"事件，大量用户的个人信息被窃取，其中不乏明星的姓名、身份证、素颜照等个人隐私信息。
图 1 记者获得的 1000 多位明星身份证号等信息
越权漏洞是很多应用中比较常见的漏洞类型，它是在授权逻辑上存在安全缺陷导致的问题。在基于用户提供的输入对象直接访问，而未进行有效鉴权，导致一些超出预期的操作行为，可能导致信息泄露或者提权，具体危害的大小取决于业务场景，所以对越权漏洞的理解依赖于你对业务逻辑的理解深度。
当前国际上习惯将越权漏洞称为 IDOR（Insecure Direct Object Reference，不安全的对象引用），在 HackerOne 上公开的漏洞案例中，你以关键词 IDOR 去搜索，就可以找到不少真实的企业漏洞案例。
越权漏洞的分类
根据越权对象的差异，可以分析水平越权和垂直越权。
1.水平越权
假设用户 A 与用户 B 属于相同权限等级的用户，当用户 A 能够访问用户 B 的私有数据时，就称为水平越权。
以 Pikachu 靶场的水平越权题目为例，下图是个登录界面，先点击下"点一下提示"获得 3 个账号及其密码：
java
lucy/123456
lili/123456
kobe/123456图 2 水平越权题目
先用 lucy 的账号密码登录，点击"点击查看个人信息"，页面返回 lucy 的个人信息：
图 3 查看个人信息
同时用 Chrome Network 抓包，得到查看个人信息的 GET 请求地址和参数：
java
http://127.0.0.1:8080/vul/overpermission/op1/op1_mem.php?username=lucy&submit=%E7%82%B9%E5%87%BB%E6%9F%A5%E7%9C%8B%E4%B8%AA%E4%BA%BA%E4%BF%A1%E6%81%AF前面已经密码验证过了，如果此时修改 username 为其他账号，是否会获得其他用户的个人信息呢？
下面修改 username 为 lili，发起请求：
java
http://127.0.0.1:8080/vul/overpermission/op1/op1_mem.php?username=lili&submit=点击查看个人信息图 4 水平越权获取他人隐私信息
如上图所示，成功获取 lili 的个人信息，说明这里存在越权漏洞，且属于水平越权，因为从原定权限看，两者的权限等级是相同的。
你可以自己动手尝试下，看能否获取用户 kobe 的个人信息。
2.垂直越权
假设用户 A 是普通用户，用户 B 是管理员，当用户 A 能够访问用户 B 的私有数据时，就称为垂直越权，又称为权限提升。
以 Pikachu 靶场的垂直越权题目为例，如下图所示，它也是个登录界面，先点击下"点一下提示"获得 2 个账号及其密码，其中 admin 是管理员账号：
java
admin/123456
pikachu/000000图 5 Pikachu 靶场垂直越权题目
分别登录这 2 个账号看下有啥区别，下图是 admin 登录后返回的信息，可以看它拥有添加和删除用户的权限：
图 6 admin 管理界面
为方便后面测试，先记录添加与删除用户的请求数据。
先点击用户 vince 一行所在的"删除"按钮，删除用户 vince 并抓包，得到请求数据：
java
http://127.0.0.1:8080/vul/overpermission/op2/op2_admin.php?id=1再点击"添加用户"，然后填写信息并点击"创建"：
图 7 添加用户
同时抓包获得请求数据：
java
POST http://127.0.0.1:8080/vul/overpermission/op2/op2_admin_edit.php
username=test&password=test&sex=%E7%94%B7&phonenum=13666666666&email=test%40gmail.com&address=test&submit=%E5%88%9B%E5%BB%BA我们再回头登录看下普通用户 pikachu 登录后的情况。
图 8 pikachu 的查看页面
试想下，普通用户 pikachu 如何才能拥有 admin 一样的增加与删除用户的权限呢？
在当前用户为 pikachu 的情况下，尝试删除用户，构造如下请求去删除 id=2 的用户：
java
http://127.0.0.1:8080/vul/overpermission/op2/op2_admin.php?id=2访问后 302 跳转到登录界面，且并没有删除成功，说明这里没有越权漏洞。
图 9 构造删除用户的请求后，被重定向到登录界面
接下来看看添加用户的接口是否存在越权，在当前用户为 pikachu 的情况下，构建如下请求，添加一个用户名密码均为 hacker 的账号：
java
POST http://127.0.0.1:8080/vul/overpermission/op2/op2_admin_edit.php
username=hacker&password=hacker&sex=%E7%94%B7&phonenum=13666666666&email=test%40gmail.com&address=test&submit=%E5%88%9B%E5%BB%B这里我使用 HackBar 去构造 POST 请求，请求后会跳转到登录界面，重新用 pikachu 登录可以看到 hacker 账号已经创建成功，说明我们已经越权成功，这里属于提升权限，所以它属于垂直越权漏洞。
图 10 越权添加用户
越权漏洞的检测与利用
对于越权漏洞的检测与利用基本是一回事，因为它偏于业务逻辑缺陷，当你检测到的时候，基本等同于利用了，所以此处我把它们放在一块儿谈。
越权漏洞的检测与利用，长期以来大多是以手工测试或半自动测试为主，因为背后涉及一些业务逻辑功能的理解。对于自己公司内部业务做一些定制化的全自动检测也是可行的，比如掌握各类用户权限情况、涉及权限验证的敏感操作请求等等情况，就可以尝试自动切换用户或删除登录态去执行敏感操作，以此判断是否存在越权漏洞，再进行人工最终确认。
关于自动化扫描越权漏洞，推荐《越权扫描器碎碎念》一文。
下面我会介绍一些用来检测越权漏洞的常用工具，主要是一些 BurpSuite 插件，都可以通过 BurpSuite 插件库 BApp Store 找到并安装，不过安装速度可能很慢，甚至是多尝试几次才能安装成功。
这种情况可以尝试手工安装，先从 BApp Store 官网下载插件的 bapp 文件到本地，然后点击"Manual install ..."选择下载的文件进行安装。
图 11 Manual install
下面介绍的这些工具都是刷漏洞奖励平台的利器，而且越权漏洞跟别人撞洞的概率也会相对低些，有些奖金也不低。
1.Authz
Authz 的使用比较简单，在 BurpSuite 中将需要测试的请求发送到 Authz：
图 12 发送请求到 Authz
之后修改 Cookie 值为其他用户，也可以是其他请求头信息，待准备测试的请求收集完后，点击"Run"按钮即可。如果原响应内容长度、状态码和被修改请求后的响应内容长度、状态码一致，则会被标为绿色，表示可能存在越权漏洞。
图 13 Authz
以普通用户 pikachu 直接访问绿色的 URL，可以直接打开"添加用户"的界面进行操作，这原来是管理员 admin 才拥有的权限，非常明显的越权行为。
图 14 普通用户越权访问"添加用户"管理页面
2.Autorize
Autorize 会对客户端发送的所有请求数据进行修改后重放，主要是将其他用户的 Cookie 替换当前用户的 Cookie，或者其他授权验证相关的请求头。
Autorize 不用像 Authz 那样挑选请求并发送到插件，它可以直接配置要替换的头信息，包括 Cookie 或者其他验证头信息，同时支持作用域过滤器，用来筛选我们感兴趣的请求，避免收到大量的无用结果。
图 15 将其他用户的 Cookie 配置到 Autorize 进行替换
之后也是通过对比修改前后的响应结果来判断越权漏洞是否存在，若响应长度和状态码一样，那就有可能存在越权漏洞。不过，有时候也需要人工难证下，有可能一些页面本身就是允许任意用户访问的，需要分析下原设定的正常业务逻辑。
3.Auto Repeater
像 Authz 这种挑选请求并发送到插件的方式，测试效率会低一些，没有 Auto Repeater 高效。
Auto Repeater 功能相对 Autorize 更多更复杂一些，可以理解为是它的扩展版，是基于自动请求重放与响应比对的方式进行检测的，它可以对更加具体的请求参数进行测试，比如 PHPSESSID、SID、UID 等涉及用户身份的参数，支持正则匹配与替换。
点击"Active AutoRepeater"开启，再添加替换规则。比如，我想替换 Cookie 中的 PHPSESSID 参数值，可以在 Replacements 中添加替换规则，然后在 Base Replacements 下为 cookie 配置一个规则，Type 选择"Match Cookie Name, Replace Value"Match 设置为 Cookie 名称 PHPSESSID，替换为权限较低的用户的 Cookie 值。
图 16 设置替换规则
在之后的捕获的请求中，若满足匹配条件就会自动修改数据并重新发送请求，用户再根据响应结果是否有差异来判断是否存在越权漏洞，可以通过 Logs 设置颜色标记来区分，避免请求过多时，浪费过多时间排查验证。
图 17 Auto Repeater Logs
防御越权漏洞
由于越权漏洞涉及业务逻辑，靠 WAF、RASP 那些安全系统是没有用的，更重要的是在开发设计时提前考虑好权限控制与校验问题，可以尝试从以下几方面入手：
整体的权限调节：每次访问一个对象时，都要检查访问是否授权，特别是对于安全很关键的对象。不要像前面的靶场题目那样，密码验证过后，后续的敏感对象操作都不再验证，这样很容易导致漏洞。
最低权限原则：只授予执行操作所必需的最小访问权限，并且对于该访问权只准许使用所需的最少时间。
前后端双重验证：在涉及敏感操作行为时，前端与后端同时对用户输入数据进行权限校验，尤其是前端校验特别容易被改包绕过。
对于特别敏感的操作增设密码或安全问题等验证方式：比如修改密码要求输入原密码。
小结
越权漏洞属于业务逻辑型漏洞，常见一些业务功能场景，比如查看和修改个人信息、账号登录等功能。但它又不是一种固定漏洞场景的漏洞，依赖于业务处理逻辑，所以手工测试和半自动化测试是主要的检测手段。当前的一些全自动化检测越权，主要是替换用户凭证相关信息来重放请求，根据响应结果的比对判断，思路与在越权漏洞的检测与利用一小节中介绍的工具检测原理类似。
越权漏洞常被分为水平越权和垂直越权两种，根据越权对象的权限等级来划分的，同级的就是水平越权，由低向高权限越权就是垂直越权。你还记得开篇提到的"明星健康宝照片被泄露"事件吗？你认为它属于水平越权还是垂直越权呢？欢迎在评论区留言讨论。