访问控制漏洞和权限提升
翻译
原文：https://portswigger.net/web-security/access-control
- name: 翻译
desc: 原文：https://portswigger.net/web-security/access-control
bgColor: '#F0DFB1'
textColor: 'green'
2
3
4
# 0访问控制漏洞和权限提升
在本节中，我们将讨论什么是访问控制安全性，描述 访问控制和权限提升 可能产生的漏洞类型，并总结如何防范这些漏洞。
实验室
如果您已经熟悉 信息泄露漏洞 背后的基本概念，并且只想在一些实际的、易受攻击的目标上练习和利用它们，那么您可以从下面的链接访问本主题中的所有实验室。
# 1什么是访问控制？
访问控制（也叫授权）是一种约束，约束对象是某个人或物，可以允许或拒绝他们 执行的操作/访问所请求的资源。
在 Web 应用程序的上下文中，访问控制依赖于身份验证和会话管理：
- 身份验证识别用户并确认他们是他们所说的那个人。
- 会话管理标识同一用户发出的后续 HTTP 请求。
- 访问控制确定是否允许用户执行他们尝试的操作。
破坏的访问控制是一种常见的安全漏洞，它通常是严重的。访问控制的设计和管理 是一个复杂而动态的问题，它将业务、组织和法律约束 应用到技术实现中。访问控制的设计决策必须由人来做出，而不是基于某种技术，并且决策出错的可能性很高。
从用户的角度来看，访问控制可分为以下几类：
# 1.1垂直访问控制（纵向访问控制）
垂直访问控制是 “对用户的访问限制” 机制，你不能访问其他类型用户的敏感功能。
通过垂直访问控制，不同类型的用户可以访问不同的应用程序功能。例如，管理员能够修改或删除任何用户的帐户，而普通用户无权访问这些功能。垂直访问控制可以是安全模型的更精细实现，旨在强制实施业务策略，例如 职责分离和最小权限。
（译者加：管理员有管理员的功能，普通用户有普通用户的功能，但是普通用户不允许访问管理员功能）
# 1.2水平访问控制（横向访问控制）
水平访问控制是 “对资源的访问限制” 机制，它明确了哪些用户允许访问这些资源。
通过水平访问控制，不同的用户可以访问相同类型的资源子集。例如，银行应用程序将允许用户查看交易并从自己的帐户付款，但不允许 查看或影响 任何其他用户的帐户。
（译者加：A用户有自己的钱包，B用户也有自己的钱包，但是他们不能访问对方的钱包）
# 1.3依赖于上下文的访问控制
依赖于上下文的访问控制，根据用户与应用程序的交互状态，来限制对相关功能和资源的访问。
这种访问控制，还可以防止用户以错误的顺序执行操作。例如，零售网站在用户付款之后，可能会阻止其修改购物车的内容。
# 2访问控制中断的示例
在实际中，当用户可以访问某些资源，或 执行某些他们不应该执行的操作时，就会存在访问控制中断漏洞。
（译者加：扩展阅读资料 “OWASP TOP10-访问控制中断 (opens new window)”）
# 2.1垂直权限提升
如果用户可以访问他们无法访问的功能，则这就是垂直权限提升。例如，一个非管理员用户，如果他可以访问管理页面，则他可以在其中删除任意用户的帐户，这就是垂直权限提升。
# 2.1.1不受保护的功能
在最基本的情况下，当应用程序不对 敏感功能 实施任何保护措施时，就会出现垂直权限提升。例如，管理功能 可以链接在管理员的欢迎页面，但不能链接在普通用户的欢迎页面。然而，在某些情况下，当用户直接浏览到相关的管理 URL 时，就可以访问管理功能。
例如，网站可能在以下 URL 中托管敏感功能：
https:/admin
实际上，任何用户都可以访问这个路径，管理员的用户界面 具有指向该功能的链接，但对于其他用户来说，则需要寻找该链接。在某些情况下，管理 URL 可能会在其他位置暴露，例如robots.txt文件：
https:/robots.txt
即使 URL 没有在任何地方暴露，攻击者也可以使用单词列表，来暴力破解敏感功能的位置。
- name: 实验室-学徒
desc: 不受保护的管理功能 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-unprotected-admin-functionality
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
在某些情况下，敏感功能没有受到强有力的保护，而是通过一个不可预测的 URL 来隐藏：这就是所谓的隐蔽性安全。仅隐藏敏感功能，并不能提供有效的访问控制，因为用户仍可能以各种方式 发现经过混淆的 URL。
例如，考虑在以下 URL 部署管理功能的应用程序：
https:/administrator-panel-yb556
攻击者可能无法直接猜到这个路径。但是，应用程序可能会将 URL 泄露给用户。例如，该 URL 可能会在 JavaScript 中暴露，该 JavaScript 根据用户的角色构造用户界面：
<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
3
4
5
6
7
8
9
10
如果当前用户是管理员用户，此脚本将添加一个指向用户 UI 的链接。但是，包含 URL 的前端脚本对所有用户都是可见的，无论其角色如何。
- name: 实验室-学徒
desc: 不受保护的管理功能，其URL不可预测 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-unprotected-admin-functionality-with-unpredictable-url
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
# 2.1.2基于参数的访问控制策略
一些应用程序在登录时，确定用户的访问权限或角色，然后将此信息存储在用户可控制的位置，例如隐藏字段、Cookie 或预设字符串查询参数。应用程序根据提交的值，来做出后续的访问控制决策。例如：
https:/login/home.jsp?admin=true
https:/login/home.jsp?role=1
2
这种方法从根本上来说是不安全的，因为用户可以简单地修改值，然后访问他们未被授权的功能，例如管理功能。
- name: 实验室-学徒
desc: 由请求参数控制的用户角色 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-user-role-controlled-by-request-parameter
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
- name: 实验室-学徒
desc: 通过用户个人资料修改用户角色 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-user-role-can-be-modified-in-user-profile
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
# 2.1.3平台配置错误导致访问控制中断
一些应用程序根据用户的角色，限制对特定 URL 和 HTTP 方法的访问，在平台层强制实施访问控制。例如，应用程序可以配置如下所示的规则：
DENY: POST, /admin/deleteUser, managers
此规则拒绝 managers 组中的用户访问 URL/admin/deleteUser上的POST方法。在这种情况下，各种事件都可能产生错误，导致访问控制被绕过。
一些应用程序框架支持各种非标准 HTTP 标头，这些标头可用于覆盖原始请求中的 URL ，例如X-Original-URL和X-Rewrite-URL。假设，网站使用了严格的前端控件来限制基于 URL 的访问，但是，如果应用程序允许通过以上请求标头来覆盖 URL，则可以使用如下所示的请求，来绕过访问控制：
POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...
2
3
- name: 实验室-从业者
desc: 绕过基于URL的访问控制 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-url-based-access-control-can-be-circumvented
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
另一种攻击方式，与请求中使用的 HTTP 方法有关。上面的前端控件根据 URL 和 HTTP 方法来限制访问。但，某些网站在执行操作时，允许其他 HTTP 请求方法。如果攻击者可以使用 GET（或其他）方法对受限 URL 执行操作，则他们可以绕过平台层的访问控制。
- name: 实验室-从业者
desc: 绕过基于方法的访问控制 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-method-based-access-control-can-be-circumvented
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 2.1.4URL匹配不一致导致访问控制中断
在路由传入请求时，网站的路径必须与预定义的端点相匹配，但在匹配的严格程度方面有所不同。例如，它们可能在大小写方面不敏感，因此对/ADMIN/DELETEUSER端点的请求，仍然会映射到相同的/admin/deleteUser端点。这本身不是问题，但如果访问控制机制的容忍度较低，则它可能会将其视为两个不同的端点，从而导致无法强制实施适当的限制。
如果使用 Spring 框架的开发人员启用了useSuffixPatternMatch选项，则可能会出现类似的差异。该选项允许 将具有任意文件扩展名的路径，映射到没有文件扩展名的等效端点。换句话说，对/admin/deleteUser.anything的请求仍然匹配/admin/deleteUser模式。在 Spring 5.3 之前，此选项默认处于启用状态。
在其他系统上，你可能会遇到是否将/admin/deleteUser和/admin/deleteUser/（后面多了个斜杠/）视为不同端点的差异功能选项。在这种情况下，只需在路径后面追加一个斜杠，就可以绕过访问控制。
# 2.2水平权限提升
当用户能够访问 属于另一个用户的同类资源 时，就会出现水平权限提升。例如，一个员工本应该只能访问 他自己的就业和工资单记录，但实际上还可以访问其他员工的记录，那么这就是水平权限提升。
水平权限提升攻击，可能使用与 垂直权限提升 类似的攻击手段。例如，用户通常可以使用如下所示的 URL 来访问自己的帐户页面：
https:/myaccount?id=123
现在，如果攻击者将id参数值修改为另一个用户的值，则攻击者可以访问另一个用户的帐户页面，包括该账户关联的数据和功能。
- name: 实验室-学徒
desc: 由请求参数控制的用户ID >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
在某些应用程序中，可利用的参数没有可预测的值。例如，应用程序可以使用全局唯一标识符（GUID）来标识用户，而不是纯粹的递增数字。在这里，攻击者可能无法猜测或预测另一个用户的标识符。但是，属于其他用户的 GUID 可能会在引用用户信息的某个位置暴露，例如用户消息或评论。
- name: 实验室-学徒
desc: 由请求参数控制的用户ID，用户ID不可预测 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-unpredictable-user-ids
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
在某些情况下，应用程序会检测用户何时不被允许访问资源，并返回指向登录页的重定向。但是，重定向的响应可能包含属于目标用户的一些敏感数据，因此攻击仍然成功。
- name: 实验室-学徒
desc: 由请求参数控制的用户ID，重定向中的数据泄露 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-data-leakage-in-redirect
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
# 2.3从水平到垂直的权限提升
通常，通过攻击高权限的用户，可以将水平权限提升攻击 转变为 垂直权限提升。例如，水平提升可能允许攻击者 重置或捕获 属于其他用户的密码。如果攻击者以管理员用户为目标，并破坏其帐户，则他们可以获得管理访问权限，从而执行垂直权限提升。
例如，攻击者可以使用水平权限提升中的参数篡改技术，来访问其他用户的帐户页面：
https:/myaccount?id=456
如果目标用户是应用程序管理员，则攻击者将获得账户管理界面的访问权限。此页面可能会泄露管理员的密码，或 提供更改密码的功能，或者 可能提供对特权功能的直接访问。
- name: 实验室-学徒
desc: 由请求参数控制的用户ID，密码泄露 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-password-disclosure
bgColor: '#001350'
textColor: '#39d50c'
2
3
4
5
6
# 2.4不安全的直接对象引用（IDOR）
不安全的直接对象引用（IDOR） (opens new window)是访问控制漏洞的一个子类别。当应用程序使用用户提供的输入直接访问对象，并且攻击者可以修改输入，以获取未经授权的访问时，就会出现 IDOR。它因出现在 OWASP 2007 Top 10 榜单中而流行起来，尽管它只是 可能导致绕过访问控制的、许多实施错误的 其中一个例子。
# 2.5多步骤流程中的访问控制漏洞
许多网站通过一系列步骤 来实现重要功能。通常，当需要捕获各种输入或选项时，或者 当用户需要在执行操作之前 查看和确认详细信息时，才会执行此类操作。例如，更新用户详细信息的管理功能，可能涉及以下步骤：
- 加载包含特定用户详细信息的表单。
- 提交更改。
- 查看更改并确认。
有时，网站会对其中一些步骤 实施严格的访问控制，但会忽略其他步骤。例如，假设访问控制被正确地应用于第一步和第二步，但没有应用于第三步。实际上，该网站假设用户已经正确完成第一步骤，才会到达步骤 3 。在这里，攻击者可以跳过前两个步骤，然后构造所需参数，直接提交第三步的请求，来获得对函数的未授权访问。
- name: 实验室-从业者
desc: 多步骤过程，其中一步未实施访问控制 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-multi-step-process-with-no-access-control-on-one-step
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 2.6基于Referer的访问控制
一些网站基于 HTTP 请求中提交的Referer标头来进行访问控制。Referer标头通常由浏览器添加到请求中，以标识从中发起请求的页面。
例如，假设应用程序在/admin处 对主要管理页面严格实施访问控制，但对于/admin/deleteUser等子页面，仅检查Referer标头。如果Referer包含主要页面的/adminURL ，则允许该请求。
- name: 实验室-从业者
desc: 基于Referer的访问控制 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/access-control/lab-referer-based-access-control
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 2.7基于地理位置的访问控制
一些网站根据用户的地理位置，来对资源实施访问控制。例如，这可以应用于银行应用或媒体服务，使其符合当地法律法规或某些业务限制要求。
这些访问控制通常可以通过使用 Web 代理、VPN 或操纵客户端地理定位机制来绕过。
# 3如何防范访问控制漏洞
通常，可以采用纵深防御方法，并应用以下原则来防范访问控制漏洞：
- 永远不要仅仅依靠 模糊处理 来进行访问控制。
- 除非资源打算公开，否则默认情况下拒绝访问。
- 尽可能使用单一的应用程序范围机制，来强制实施访问控制。
- 在代码层面，开发人员必须声明每个资源允许访问的范围，并默认拒绝访问。
- 彻底审核和测试访问控制，以确保它们按预期设计工作。
（译者加：以下为个人总结）
- 访问控制需要 “精确匹配和处理” ，不能 “模糊” 。
- （照搬）除非资源打算公开，否则默认情况下拒绝访问。
- 为单个应用程序，设置单独的强制访问控制措施。
- 声明资源所属范围，只有在该范围内才允许访问。
- 深度测试访问控制，确保没有逻辑上的问题。