逻辑漏洞终章：PortSwigger 访问控制 (Access Control) 攻防实战与越权全解
前言: 逻辑漏洞一共包含业务逻辑漏洞、身份验证漏洞和访问控制漏洞三种，本篇博客是对访问控制漏洞的总结，其他两种我前两篇博客已经总结过了。如果说身份验证是‘防盗门’，那访问控制就是室内的‘保险柜’。在 PortSwigger 靶场中，我深入研究了垂直越权、水平越权以及基于上下文的逻辑绕过，本文记录了这些漏洞的复现过程以及我自己的思考。
访问控制漏洞
- 逻辑漏洞终章：PortSwigger 访问控制 (Access Control) 攻防实战与越权全解
- 一、垂直权限提升
-
- 1、未受保护的管理功能
-
- 1）通过 robots.txt 发现隐藏路径
- 2）通过源码审计发现隐藏 URL
- 2、参数与请求头篡改
-
- 1）篡改请求参数实现提权
- 2）欺骗服务器的 URL 验证
- 3）利用 HTTP 方法逻辑漏洞
- 二、水平权限提升
-
- 1、经典 ID 遍历
-
- 1）直接修改 ID 参数
- 2）利用重定向泄露数据
- 2、复杂场景下的IDOR
-
- 1）攻克不可预测的GUID
- 2）静态文件的越权访问
- 三、混合攻击链
-
- 1、横向越权转纵向提权
-
- 1）窃取管理员密码
- 2、业务流程绕过
-
- 1）跳过验证步骤
- 防御与总结
一、垂直权限提升
⬆️ 权限低的干了权限高的事，如普通用户获得管理员权限（垂直越权、提权）
1、未受保护的管理功能
1）通过 robots.txt 发现隐藏路径
实例：Lab: Unprotected admin functionality未受保护的管理员功能 要求：垂直提权访问管理员面板删除carlos
前提 robots.txt：位于网站根目录下，用来告诉搜索引擎的爬虫哪些网页可以访问，哪些网页不可以访问（只是一个协定，并未强制阻止） 但是它对黑客工具是没有效果的，反而带有指示效果帮助扫描目录，如Burp自带的爬虫扫描功能。
该题描述管理员功能未受保护，因此我们试着访问一下/robot.txt，直接就能看到管理员面板路径： 
或者如果一时忘记了robots.txt这个东西，也可以简单粗暴的用burp自带爬虫扫描器直接把目录扫描一遍： 
访问管理员面板即垂直提权成功。
2）通过源码审计发现隐藏 URL
实例：Lab: Unprotected admin functionality with unpredictable URL管理员功能不受保护，URL 不可预测 要求：垂直提权访问管理员面板删除carlos
这一题直接访问robots.txt访问不了了，直接扫描目录也是确定不了具体位置的，说明URL不可预测： 
那我们就要试着看一下源代码，右击查看页面源代码，发现端倪： 
说明管理员面板是/admin-gegv7o，访问即可提取成功。
2、参数与请求头篡改
1）篡改请求参数实现提权
实例一：Lab: User role controlled by request parameter用户角色由请求参数控制 要求：访问/admin，删除carlos
前两个实验直接访问管理员面板就可以提权，这一题是将身份放在请求参数里面控制 访问/admin，显示无权访问： 
我们登录已知账户wiener：peter，点击我的账户然后抓包，发现管理员身份是直接由cookie里面的参数决定的，我们将Admin=false改为true，即可获得管理员权限： 
后面的每一步都要验证是否是管理员，每一步都抓包做修改即可。
实例二：Lab: User role can be modified in user profile用户角色可以在用户个人资料中修改 要求：访问/admin，删除carlos，只有roleid为2的已登录用户能访问
先登录已知账户wiener：peter，抓包分析时未看到roleid，因此修改邮件点击更新然后抓包： 
发现响应的内容roleid=1，所以只需要将roleid改为2就可以拥有管理员权限： 
访问管理员面板，删除carlos。
2）欺骗服务器的 URL 验证
实例：Lab: URL-based access control can be circumvented基于 URL 的访问控制可以被绕过 要求：提权至管理员权限，删除carlos
前提 X-Original-URL： 传递客户端最初请求的完整路径 ，可用来覆盖原始请求中的URL，伪造路径 例如： 若代理只允许/api/*路径转发到后端，那么其他路径如/admin就会被拦截 那怎么办？ 发送符合规则的请求路径 伪造X-Original-URL：/admin 如果后端信任并直接使用X-Original-URL作为真实路径，就饶过了拦截
该实验的问题在于使用严格的前端控制来限制基于 URL 的访问 首先点击管理员面板发现是无权访问，那我们就要判断一下是否能使用X-Original-URL，将路径改为/，然后用X-Original-URL伪造一个不存在的路径，发现响应not found，说明并没有按照原来的路径跳转到首页，而是去访问了X-Original-URL伪造的路径，说明可以使用X-Original-URL： 
那保持路径/不变，X-Original-URL=/admin，即可访问管理员面板，然后删除carlos，发现依然无权访问，抓包看看： 
把路径改为/，将那一长串/admin/delete？username=carlos放到X-Original-URL中： 
发现不能携带参数，因此把?username=carlos放到路径/后面，执行时会自动添加到X-Original-URL后： 
结果重定向到/admin，说明删除成功，重新返回首页刷新一下即可通关。
3）利用 HTTP 方法逻辑漏洞
实例：Lab: Method-based access control can be circumvented基于方法的访问控制可以被绕过 要求：使得wiener获得管理员权限
这个实验的漏洞原理在于： 后端逻辑只在 POST 请求时检查权限，而忽略了 GET 请求 首先登陆管理员账户，提升carlos权限然后抓包，在退出登录自己的账户wiener：peter，查看我的账户抓包： 
复制普通用户的session，并且将HTTP方法改为GET方法，username改为wiener（这样后端根本不会检查权限，用wiener的session自己给自己提权）： 
提权成功，wiener获得管理员权限。
替换session的原理： 若替换session后请求成功，说明普通用户执行了管理员操作，存在垂直越权漏洞，后端仅校验了session是否有效，没校验是否为管理员权限。 注意 部分现代服务器（HTTP/2）对请求头校验严格，直接修改 Method 可能会报错。此时可以将协议降级为 HTTP/1.1，利用旧协议的宽松特性成功绕过。
二、水平权限提升
↔️ 权限地位平等的用户之间，如普通用户A看了普通用户B的隐私（水平越权、IDOR不安全的直接对象引用）
1、经典 ID 遍历
1）直接修改 ID 参数
实例：Lab: User ID controlled by request parameter用户 ID 由请求参数控制 要求：提交目标用户carlos的API key
这一题特别简单，登录自己的账号后，只要修改URL中的id就可以获得目标用户的API key了： 
2）利用重定向泄露数据
实例：Lab: User ID controlled by request parameter with data leakage in redirect用户 ID 由请求参数控制，重定向过程中存在数据泄露。 要求：提交目标用户carlos的API key
这一题很简单，登录已知账号wiener：peter抓包，然后修改参数id改为carlos，这时候会显示重定向到登录界面，但是这个重定向信息中包含了carlos的API key： 
2、复杂场景下的IDOR
1）攻克不可预测的GUID
实例：Lab: User ID controlled by request parameter, with unpredictable user IDs用户 ID 由请求参数控制，用户 ID 不可预测 要求：提交目标用户carlos的API key
前提 GUID：全球唯一标识符
用户也是通过请求参数控制的，这一题与前面题目的区别就在于，用户是用GUID标识的 但是 GUID 可能会在应用程序的其他位置泄露，例如用户消息或评论中引用用户的地方
这一题不止是直接修改URL后的id为carlos那么简单，用户是用GUID来标识的，所以要找到carlos的GUID，通过翻博客，可以找到carlos发表的一篇博客，点击carlos名字然后抓包： 
carlos的GUID就得到了，然后修改URL后的id即可获得carlos的API key。
2）静态文件的越权访问
实例:Lab: Insecure direct object references(IDOR)不安全的直接对象引用 要求：找到carlos的密码
前提 IDOR不安全的直接对象引用： 指应用将内部对象标识符（如用户 ID、订单号等）暴露在URL中、或请求头中，直接依据该标识访问资源且未做权限校验，攻击者篡改标识就能越权操作。
这一题的话是有一个实时聊天框，可以与机器人聊天，并无任何异常，我们点击查看记录然后抓包，发现端倪： 
我们的聊天记录会显现出来，且是位于2.txt，因此可以猜测序号2是不是用来记录我们的聊天记录的，而其他的序号是记录别人的聊天记录的，将2改为0，发现找不到记录，再改为1.txt发现有用聊天记录，密码就位于此处： 
三、混合攻击链
🔄 破坏业务流程（ 逻辑绕过）
1、横向越权转纵向提权
1）窃取管理员密码
实例：Lab: User ID controlled by request parameter with password disclosure用户 ID 由请求参数控制，密码泄露 要求：获得管理员密码，删除carlos
首先点击我的账户界面抓包，在响应内容中是直接泄露密码的： 
我们试着将id改为admin、administrator看看能不能直接访问管理员账户界面然后获取密码，发现当id为administrator时，是成功的： 
成功获取管理员密码。
2、业务流程绕过
1）跳过验证步骤
实例：Lab: Multi-step process with no access control on one step多步骤流程，其中一步没有访问控制 要求：使得wiener获得管理员权限 这一题其实与之前有一题很像，首先就是登录管理员账号，查看管理员面板，然后升级wiener权限，发现有两步，第一步是点击upgrade，第二步是点击sure，这两个请求全部抓包放到重放器，登录自己的账号获取session，然后将该session分别替代第一步的session和第二步的session： 
第一步显示无权，那再我们替代掉第二步的session： 
发现可以提权成功，这就是由于在多步的流程中，漏了一步没有做访问控制，就会导致这种情况。
防御与总结
1、拒绝“隐式信任”： 不要相信用户提交的任何参数（ID、Role、Header），所有权限必须在服务器端从Session中重新验证。 2、默认拒绝原则 ： 配置权限时，应默认拦截所有请求，只放行明确允许的接口。 3、使用难以猜测的 ID： 尽量使用UUID/GUID替代自增ID，防止被遍历。 4、全流程校验： 对于多步操作（如支付、改密），每一步都要校验用户是否完成了上一步。
