小白兔快开门，我是你爸爸。WEB安全基础入门—访问控制漏洞和权限提升

欢迎关注订阅专栏！
WEB安全系列包括如下三个专栏：

• 《WEB安全基础-服务器端漏洞》
• 《WEB安全基础-客户端漏洞》
• 《WEB安全高级-综合利用》

知识点全面细致，逻辑清晰、结合实战，并配有大量练习靶场，让你读一篇、练一篇，掌握一篇，在学习路上事半功倍，少走弯路！
欢迎关注订阅专栏！

• 专栏文章追求对知识点的全面总结，逻辑严密，方便学习掌握。力求做到看完一篇文章，掌握一类漏洞知识。让读者简洁高效的掌握WEB安全知识框架，推开入门深造的大门。
• 绝不为了追求文章数量，彰显内容丰富而故意拆散相关知识点。避免读者沉迷在无尽的技巧中而迷失进阶的道路！本系列的目标是授之以渔，而不仅仅是技巧的堆砌。
• 每篇文章均配有大量靶场，点击文章中靶场名即可跳转练习（靶场在网站注册即可免费使用）。
• 欢迎订阅专栏！建议学完两个基础专栏，再学习高级哦~

1. 什么是访问控制

访问控制是对谁可以执行什么操作或是否允许其访问所请求资源的管控。在具体的WEB环境中，访问控制依赖于身份验证和会话（session）管理.

• 身份验证：识别用户，确认他就是他声称的人。
• **会话管理：**用session标识同一用户发出的后续HTTP请求。
• **访问控制：**确定是否允许用户执行他们尝试执行的操作。

访问控制的设计和管理是一个复杂且动态的问题，它将业务、组织和法律约束应用于技术实施。由于访问控制设计的决策必须由人权衡后做出，而不是单纯由技术做出，因此出错的可能性很高。

2. 访问控制的分类

1. 垂直访问控制（对功能的访问控制策略）

限制不同类型用户访问不同敏感功能的一种访问控制策略
不同类型的用户拥有不同的应用功能权限。例如管理员能够修改或删除任何账户，而普通用户无权访问这些功能。
垂直访问控制可以实施业务策略（如职责分离和最小权限）的更细粒度的安全模型

2. 水平访问控制（对资源的访问控制策略）

限制不同的用户可以访问相同资源类型的特定子集。
不同类型的用户拥有相同类型的资源子集的访问权限。例如银行应用允许用户查看交易并从他们自己的账户付款，但不允许使用其他人的账户。

3. 基于上下文的访问控制

根据应用程序的状态或用户的交互来限制对功能和资源的访问。
可防止用户以错误的顺序执行操作。例如，零售网站会阻止用户在付款后修改订单的内容。

3. 访问控制的安全模型

1. 什么是安全模型

访问控制安全模型是对一组独立于技术或实现平台的访问控制规则的定义。访问控制安全模型在操作系统、网络、数据库管理系统以及后台、应用程序和网络服务器软件中实施。多年来，已经设计了各种访问控制安全模型，已将访问控制策略与业务或组织规则和技术变化相匹配。主要包括以下四种：

• 程序化访问控制模型
• 自主访问控制模型（DAC）
• 强制访问控制模型（MAC）
• 基于角色的访问控制模型（RBAC）

2. 程序化（矩阵）访问控制模型

用户权限矩阵存储在数据库中，并参照该矩阵应用访问控制。这种访问控制可以包括角色、组、个人用户、流程集合或工作流，并且可以是高细粒度的。

3. 自主访问控制模型（DAC）

可以根据用户或指定的用户组来限制对资源或功能的访问。单个资源或功能的所有者能够向用户分配访问权限。该模型是高度细化的，定义了对单个资源或功能的用户访问权限。因此，模型的设计和管理可能会变得非常复杂。

4. 强制访问控制模型（MAC）

是一种集中控制的访问控制系统，主体对某个对象(文件或其他资源)的访问受到限制。与DAC不同，资源的用户和所有者无权委派或修改其资源的访问权限。这种模式通常被军队、保密单位的系统采用。

5. 基于角色的访问控制模型（RBAC）

可以定义指定的角色，并为其分配访问权限。然后分配给用户单个或多个角色。如果设计得当，可以提供足够的粒度，以便在复杂的应用程序中提供可管理的访问控制。例如，可以将采购办事员这个职位定义为对采购分类功能及其相关资源有访问权限的角色。当员工离开或担任该职位时，访问控制将简单的撤销或授权其账户为采购办事员的角色即可。

当有足够的角色来正确地调用访问控制，但又不会使模型过于复杂和难以管理时，RBAC是最有效的。

4. 访问控制漏洞利用

1. 垂直权限提升

如果用户可以访问到他们不被允许访问的功能时，即为垂直权限提升。例如，如果非管理用户实际上访问到管理页面。

• 仅受到有限防护的功能点

用户可以通过浏览器直接输入URL到管理功能页。开发者未对所有功能页面做好安全验证防护，导致未授权访问。
https://insecure-website.com/admin

例题1

有时路径并不好寻找，也无法预测，如下
https://insecure-website.com/administrator-panel-yb556
有时响应的JS代码中含有这个路径，其实这属于信息泄露的一种

<script>var isAdmin = false;if (isAdmin) {...var adminPanelTag = document.createElement('a');adminPanelTag.setAttribute('https://insecure-website.com/administrator-panel-yb556');adminPanelTag.innerText = 'Admin panel';...}</script>

例题2

• 基于参数的访问控制方法

一些程序将用户的权限存储在了用户可控制的位置，如URL参数、cookie
https://insecure-website.com/login/home.jsp" />POST / HTTP/1.1X-Original-URL: /admin/deleteUser...

例题 5、6

2. 横向权限提升

如果用户能够访问属于另一个用户的资源，即为横向权限提升。如查看他人个人信息页或查看工资单。
攻击手段与垂直权限提升攻击手段类似，如直接访问URL
https://insecure-website.com/myaccount?id=123

例题7、8、9

3. 从横向到纵向的权限提升

如果横向权限提升到了其他高权限账户，则实现了从横向到纵向的权限提升。

例题 10

4. 不安全的直接对象引用（IDOR）

应用程序直接调用被用户控制输入的信息进行查询，造成对恶意对象的直接调用。

• 对数据对象的直接引用

https://insecure-website.com/customer_account?customer_number=132355
如上URL，某个网站数据库存储的索引值（index）直接作为路径参数customer_number的值。若防护不当，攻击者可以任意修改该值，查看其他索引值对应存储的信息。
若遍历到存储高权限账户的索引值，则攻击会造成很大的威胁。

• 对静态文件的直接引用

https://insecure-website.com/static/12144.txt
如上URL，某个网站将聊天记录以txt文档形式定期存储在服务其上，随着不断累积自动生成新的txt文档。网站可通过URL直接访问这些静态文件。若防护不当，攻击者可任意修改该URL路径，查看其他静态文件。

例题11

5. 多步骤业务流程中的访问控制漏洞

在处理比较重要的业务时，往往采用多步骤处理流程。以管理员更新指定账户信息的操作为例，往往涉及至少如下三个步骤：

• 读取指定用户的信息
• 提交变更
• 查看变化内容并确认

有时网站安全防护只针对部分步骤进行了访问控制，而忽略剩余页面的防护。比如，开发者对上述一、二两步骤设置访问控制，却默认到达第三步的用户为可信用户，无需再做访问控制。攻击者可以利用这点直接调到第三步进行未授权访问。

例题 12

6. 基于Referer的访问控制

有些网页的认证逻辑是，用户在登陆管理员页面/admin时，进行严格的访问控制。但在执行后续操作时，如删除某个用户/admin/deleteUser，则采取验证报头referer的方式，验证其是否从/admin页面过来。

referer标头的作用是记录请求过来时的上一个路径，但此标头可以在Burp等类似工具中任意修改。

例题 13

7. 基于地理位置的访问控制

有些商业或社交媒体应用对访问者的位置进行访问控制，此种情况可以使用代理、VPN或者修改地理位置的插件进行篡改，从而实现绕过。

5. 漏洞实例

1. 不受保护的管理功能（Unprotected admin functionality）

• 目标

删除账户carlos

• 解题思路

随手一试有/robots.txt得到路径/administrator-panel可直接访问

2. 不受保护的管理功能但使用了不可预测的URL（Unprotected admin functionality with unpredictable URL）

• 目标

删除账户carlos

• 解题思路

在首页代码中发现js代码，获取后台管理路径/admin-mzk80q

var isAdmin = false;if (isAdmin) { var topLinksTag = document.getElementsByClassName("top-links")[0]; var adminPanelTag = document.createElement('a'); adminPanelTag.setAttribute('href', '/admin-mzk80q');（关键信息在此行） adminPanelTag.innerText = 'Admin panel'; topLinksTag.append(adminPanelTag); var pTag = document.createElement('p'); pTag.innerText = '|'; topLinksTag.appendChild(pTag);}

3. 由请求参数控制的用户角色（User role controlled by request parameter）

• 目标

删除账户carlos
测试账户:wiener:peter

• 解题思路

浏览数据包发现cookie中存在Admin=false，改为true即可

GET /my-account HTTP/1.1Host: 0ab100e204f55672c0eb16ac002b0029.web-security-academy.netCookie: session=DsCKlJOncLPK0Qw4ANnbaeMd0SjWW9m9; Admin=false

4. 可以在用户配置文件中修改用户角色（User role can be modified in user profile）

• 目标

管理页面路径为/admin 用户roleid=2可访问。删除账户carlos
测试账户:wiener:peter

• 解题思路
  1. 经测试在更换邮箱功能点时发现如下数据包和响应，包含roleid

POST /my-account/change-email HTTP/1.1Host: 0aa400d30361cda2c0613cc0007b00f7.web-security-academy.net{"email":"123@123.com"}

HTTP/1.1 302 FoundLocation: /my-accountContent-Type: application/json; charset=utf-8Connection: closeContent-Length: 115{"username": "wiener","email": "123@123.com","apikey": "EG450geTGShSaScJP4Wx0jQfObL3dITa","roleid": 1}

2. 因是json交互，尝试在请求json中，增加roleid=2

POST /my-account/change-email HTTP/1.1Host: 0aa400d30361cda2c0613cc0007b00f7.web-security-academy.net{"email":"123@123.com","roleid":2}

5. 可以绕过基于URL的访问控制（URL-based access control can be circumvented）

• 目标

管理页面在/admin HTTP支持标头X-Original-URL删除账户carlos

• 解题思路

本题访问/admin页面被拒绝，考虑使用X-Original-URL重写URL，实现绕过

GET / HTTP/1.1Host: 0a1400540499c19fc0588c9500a700cc.web-security-academy.netX-Original-URL: /admin

GET /?username=carlos HTTP/1.1Host: 0a1400540499c19fc0588c9500a700cc.web-security-academy.netX-Original-URL: /admin/delete?username=carlos

6. 可以绕过基于方法的访问控制（Method-based access control can be circumvented）

• 目标

登陆账户wiener:peter 提升权限至administrator
可参考登陆administrator:admin熟悉整个流程

• 解题思路

暂略

7. 可控制请求参数中的用户的ID （User ID controlled by request parameter）

• 目标

获取账户carlos 的API key
测试账号：wiener:peter

• 解题思路

熟悉流程后，发现数据包/my-account?id=wiener
尝试更为为id=carlos

8. 具有不可预测的用户ID （User ID controlled by request parameter, with unpredictable user IDs）

• 目标

获取账户carlos 的 GUID 获取其API key
测试账号：wiener:peter

• 解题思路
  1. 熟悉流程后，发现数据包/my-account?id=85ecc1fe-90e2-4de8-b2ac-f35b58117019
  2. 发现参数id使用了GUID无法预测，不能像上题直接更换参数了。继续浏览网页查看是否有其他途径获取carlos的GUID
  3. 发现carlos发布的文章，查看页面代码，发现亮点（其实这道题放在信息泄露那里更适合）

<h1>What Can 5G Do For You?</h1><p><span id=blog-author><a href='/blogs?userId=cad2ac39-9e5b-45ed-bb36-7db56335aa3d'>carlos</a></span> | 07 May 2022</p>

4. 改造数据包为

GET /my-account?id=cad2ac39-9e5b-45ed-bb36-7db56335aa3d HTTP/1.1Host: 0a21001804b9771bc0c2445d00ad005d.web-security-academy.net

9. 重定向数据泄漏获取ID参数 （User ID controlled by request parameter with data leakage in redirect）

• 目标

获取账户carlos 的API key
测试账号：wiener:peter

• 解题思路

此题与第7题完全一样，只是页面重定向到了登陆界面，但是数据包信息全部泄露。
给我们的启发是做安全渗透要一边看web页面，一边看数据包内容，甚至是习惯只看数据包，来发现所有功能点和内部文件的调用关系。这是个基本功。

10. 请求参数控制，获取密码（User ID controlled by request parameter with password disclosure）

• 目标

获取账户administrator的密码，删除账户carlos
测试账号：wiener:peter

• 解题思路

与第7题思路一致，在响应包中获取administrator的密码

11. 不安全的直接对象引用（Insecure direct object references）

• 目标

通过查看聊天记录文件，获取目标账户carlos的密码，登陆其账户。

• 解题思路
  1. 找到聊天功能点，查看数据包，发现下载数据包路径为GET /download-transcript/2.txt
  2. 尝试修改为GET /download-transcript/1.txt，可得到他人聊天记录获取密码

12 多步骤处理流程的访问缺陷（Multi-step process with no access control on one step）

• 目标

使账户wiener:peter成为管理员权限账户
可以使用administrator:admin熟悉整个流程

• 解题思路

介绍此题关键点

1. 熟悉整个流程发现有三个步骤分别为

• GET /admin 显示管理功能页面
• POST /admin-roles 提交提升管理权限操作请求，响应为再次确认页面
• POST /admin-roles 提交确认请求，完成权限升级

2. 在未登录情况下单独测试三个步骤，均不可访问。
3. 登陆wiener账户，获取cookie。将此cookie替换测试攻击包中的cookie，第三个环节可实现未授权访问。成功攻击包如下

POST /admin-roles HTTP/1.1Host: 0a3b00d0030c6d65c0ad5d4b00ff0015.web-security-academy.netCookie: session=UVvMFVvJTQz0F3lcK7pBy8Hv0hBEJz1y （此处替换为wiener账户的cookie）action=upgrade&confirmed=true&username=wiener (目标用户修改为wiener)

13. 基于Referer的访问控制（Referer-based access control）

• 目标

使账户wiener:peter成为管理员权限账户
可以使用administrator:admin熟悉整个流程

• 解题思路
  1. 熟悉流程发现两个步骤
  • GET /admin
  • GET /admin-roles?username=carlos&action=upgrade
  2. 使用上题方法未成功，观察第二个步骤数据包发现referer值末尾有/admin

Referer: https://0af9009c0386b8ddc099233100930076.web-security-academy.net/admin

3. 尝试去掉/admin发现响应显示未授权不能访问。判断出权限不是基于cookie，而是基于你是从哪个路径过来的。也许开发的思路是，只有经过验证的用户才能访问到/admin页面，所以从此页面过来的用户没有问题。
4. 登陆账户wiener:peter，将referer值增加/admin直接访问第二个步骤。

GET /admin-roles?username=wiener&action=upgrade HTTP/1.1Host: 0af9009c0386b8ddc099233100930076.web-security-academy.netCookie: session=aeJWiWDAH4JbksfE1GUufSjPfDCK19GU （账户wiener的cookie）Referer: https://0af9009c0386b8ddc099233100930076.web-security-academy.net/admin