访问控制

介绍

访问控制是对用户可以执行什么操作或者对他们所请求资源的约束的要求，在 WEB 应用程序的上下文中，访问控制依赖于身份验证和会话管理：

身份验证：识别用户并确认
会话管理：标识是不是一个用户发出的请求
访问控制：确定是否允许用户执行请求的操作

访问控制漏洞是一种常见且通常很严重的漏洞，主要分为三类：

垂直访问控制
横向访问控制
上下文相关的访问控制

访问控制模型

访问控制安全模型是一组独立于技术和实现平台的访问控制规则的定义。访问控制安全模型在操作系统、网络、数据库管理系统、后台、应用程序、网络服务器软件中实现

1. 程序化访问控制

通过编程访问控制，用户权限存储在数据库中，并且参考数据库中数据应用访问控制

2. 自主访问控制 DAC

通过自主访问控制，对资源或功能的访问受到基于某个用户或指定用户组的限制，资源或功能的所有者可以向用户分配权限，该模型是高度精细的，具有针对单个资源或功能的访问权限设置，因此设计和管理比较复杂

3. 强制访问控制 MAC

强制访问控制是一个集中控制的访问控制系统，其中主体对某些对象的访问受到限制，但是在这种访问控制模型中资源的用户和所有者没有权限去修改对其资源的访问权限

4. 基于角色的访问控制 RBAC

使用基于角色的访问控制，命名角色被定义为分配访问权限，然后将用户分配给单个或多个角色， RBAC 提供了对其他访问控制模型的增强管理，如果设计得当，它还具有足够的粒度以在复杂的应用程序中提供可管理的访问控制例如，采购文员可能被定义为对采购分类帐功能和资源的子集具有访问权限的角色。当员工离开或加入组织时，访问控制管理被简化为定义或撤销采购员角色的成员资格。

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

访问控制

1. 垂直访问控制

是用来限制其他类型用户不可用的敏感功能的访问机制。通过垂直访问控制不同类型的用户可以访问不同的应用程序功能

2. 横向访问控制

横向访问控制，可以对资源的访问限制为专门允许访问这些资源的用户

通过横向访问控制，不同的用户可以访问同一类型资源的子集

3. 上下文相关的访问控制

上下文相关的访问控制根据应用程序的状态或用户与应用程序的交互来限制对功能和资源的访问。

上下文相关的访问控制可防止用户以错误的顺序执行操作。例如，零售网站可能会阻止用户在付款后修改购物车的内容

垂直提权

用户可以访问不允许他们访问的功能，就是垂直权限升级

1. 不受保护的功能

应用程序没有对敏感功能实施任何保护的情况下，eg: 管理功能界面可以直接使用 URL 进行访问，不需要限制

https://insecure-website.com/admin

有的时候，可能会对一些敏感 URL 使用一些不好预测的 URL 来隐藏，但是可能会在页面源代码中泄露出来。

<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. 通过参数进行访问控制

一些应用程序在登录时确定用户的访问权限或角色，然后将此信息存储在用户可控的位置，例如隐藏字段、cookie 或预设查询字符串参数。应用程序根据提交的值做出后续的访问控制决策。例如：

https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1

3. 平台配置错误导致访问控制失效

某些应用程序通过根据用户角色限制对特定 URL 和 HTTP 方法的访问，在平台层实施访问控制。例如，应用程序可能会配置如下规则：

DENY: POST, /admin/deleteUser, managers

对于 managers 组中的用户，此规则拒绝POST方法访问 /admin/deleteUser 。

一些应用程序框架支持各种非标准的 HTTP 标头，可用于覆盖原始请求中的 URL，例如X-Original-URL和X-Rewrite-URL。如果网站使用严格的前端控制来限制基于 URL 的访问，但应用程序允许通过请求标头覆盖 URL，则可以使用如下请求绕过访问控制

POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...

另一种攻击可能与请求中使用的 HTTP 方法有关。上面的前端控件基于 URL 和 HTTP 方法限制访问。某些网站在执行操作时容忍备用 HTTP 请求方法。如果攻击者可以使用GET（或其他）方法对受限 URL 执行操作，则他们可以绕过在平台层实现的访问控制

横向提权

当一个用户能够访问属于另一个用户的资源，而不是他们自己的那种类型的资源时，就会出现水平权限提升

1. 使用请求参数控制用户

使用请求参数来判断返回的信息

https://insecure-website.com/myaccount?id=123

2. 使用不可预测的 ID

在某些应用程序中，可利用参数没有可预测的值。例如，应用程序可以使用全局唯一标识符 (GUID) 来标识用户，而不是递增的数字。在这里，攻击者可能无法猜测或预测另一个用户的标识符。但是，属于其他用户的 GUID 可能会在引用用户的应用程序的其他地方公开，例如用户消息或评论。

3. 重定向导致信息泄露

在某些情况下，应用程序会检测到何时不允许用户访问资源，并返回到登录页面的重定向。但是，包含重定向的响应可能仍包含一些属于目标用户的敏感数据，因此攻击仍然成功。

横向到垂直的特权升级

通常，通过危及更高特权的用户，水平特权升级攻击可以变成垂直特权升级。例如，水平升级可能允许攻击者重置或捕获属于另一个用户的密码。如果攻击者以管理用户为目标并破坏了他们的帐户，那么他们可以获得管理访问权限，从而执行垂直权限提升。

例如，攻击者可能能够使用已经针对水平权限升级描述的参数篡改技术来访问另一个用户的帐户页面：

https://insecure-website.com/myaccount?id=456

不安全的直接对象引用 IDOR

不安全的直接对象引用 (IDOR) 是访问控制漏洞的一个子类别。当应用程序使用用户提供的输入直接访问对象并且攻击者可以修改输入以获得未经授权的访问时，就会出现 IDOR。

1. 直接引用数据库对象的 IDOR 漏洞

考虑一个网站，它使用以下 URL 通过从后端数据库检索信息来访问客户帐户页面：

https://insecure-website.com/customer_account?customer_number=132355

在这里，客户编号直接用作对后端数据库执行的查询中的记录索引。如果没有其他控制，攻击者可以简单地修改customer_number值，绕过访问控制来查看其他客户的记录。这是导致水平权限提升的 IDOR 漏洞示例。

攻击者可能能够通过将用户更改为具有额外权限的用户同时绕过访问控制来执行水平和垂直权限提升。其他可能性包括利用密码泄漏或修改参数，例如，一旦攻击者登陆用户的帐户页面。

2. 直接引用静态文件的 IDOR 漏洞

当敏感资源位于服务器端文件系统的静态文件中时，通常会出现 IDOR 漏洞。例如，网站可能会使用递增的文件名将聊天消息记录保存到磁盘，并允许用户通过访问如下 URL 来检索这些记录：

https://insecure-website.com/static/12144.txt

在这种情况下，攻击者可以简单地修改文件名来检索另一个用户创建的副本，并可能获取用户凭据和其他敏感数据。

多步骤流程中的访问控制漏洞

许多网站通过一系列步骤实现重要功能。当需要捕获各种输入或选项时，或者当用户需要在执行操作之前查看和确认详细信息时，通常会执行此操作。例如，更新用户详细信息的管理功能可能涉及以下步骤：

加载包含特定用户详细信息的表单。
提交更改。
查看更改并确认。

有时，网站会对其中一些步骤实施严格的访问控制，而忽略其他步骤。例如，假设访问控制正确应用于第一步和第二步，但没有应用于第三步。实际上，该网站假定用户只有在已经完成第一步的情况下才会到达第 3 步，这些步骤受到适当控制。在这里，攻击者可以通过跳过前两步，直接提交带有所需参数的第三步请求，获得对该功能的未授权访问。

基于 Referer 的访问控制

Referer一些网站基于HTTP 请求中提交的标头进行访问控制。标Referer头一般由浏览器添加到请求中，以指示发起请求的页面。

例如，假设一个应用程序对位于的主要管理页面强健地实施访问控制/admin，但对于子页面，例如/admin/deleteUser仅检查Referer页眉。如果Referer标头包含主/adminURL，则允许该请求。

在这种情况下，由于Referer标头可以完全由攻击者控制，他们可以伪造对敏感子页面的直接请求，提供所需的Referer标头，从而获得未经授权的访问。

基于位置的访问控制

一些网站根据用户的地理位置强制实施对资源的访问控制。例如，这可以适用于适用州立法或业务限制的银行应用程序或媒体服务。这些访问控制通常可以通过使用网络代理、VPN 或操纵客户端地理定位机制来规避

防御

永远不要单独依赖混淆来进行访问控制。
除非资源旨在公开访问，否则默认情况下拒绝访问。
尽可能使用单一的应用程序范围的机制来实施访问控制。
在代码层面，强制要求开发人员声明每个资源允许的访问权限，默认情况下拒绝访问。
彻底审核和测试访问控制，以确保它们按设计工作。

最后更新于2年前

这有帮助吗？