访问控制和权限提升

所有内容，来自burpsuite官方靶场（portswigger）

访问控制漏洞和权限提升

什么是访问控制？

​ 访问控制（或授权）是对谁（或什么）可以执行已尝试的操作或访问他们请求的资源的限制的应用。在 Web 应用程序的上下文中，访问控制依赖于身份验证和会话管理：

• 身份验证识别用户并确认他们就是他们所说的人。
• 会话管理识别同一用户正在发出哪些后续 HTTP 请求。
• 访问控制确定是否允许用户执行他们试图执行的操作。

损坏的访问控制是一个常见且通常是严重的安全漏洞。访问控制的设计和管理是一个复杂且动态的问题，它将业务、组织和法律约束应用于技术实现。访问控制设计决策必须由人类而非技术做出，并且出错的可能性很高。

从用户的角度来看，访问控制可以分以下几类：

• 垂直访问控制
• 水平访问控制
• 上下文相关的访问控制

垂直访问控制

​ 垂直访问控制是限制对其他类型用户不可用的敏感功能的访问的机制。

​ 通过垂直访问控制，不同类型的用户可以访问不同的应用程序功能。例如，管理员可能能够修改或删除任何用户的帐户，而普通用户无权访问这些操作。垂直访问控制可以是安全模型的更细粒度的实现，旨在强制执行业务策略，例如职责分离和最小权限。

水平范围跟控制

​ 水平访问控制是将资源访问权限限制为明确允许访问这些资源的用户的机制。

​ 通过水平访问控制，不同的用户可以访问同一类型资源的子集。例如，银行应用程序将允许用户查看交易并从他们自己的账户进行支付，但不允许任何其他用户的账户。

上下文相关的访问控制

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

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

损坏的访问控制实例

​ 当用户实际上可以访问某些资源或执行他们不应该访问的某些操作时，就会存在破坏的访问控制漏洞。

纵向提权

​ 如果用户可以访问他们不被允许访问的功能，那么这就是垂直权限提升。例如，如果非管理用户实际上可以访问他们可以删除用户帐户的管理页面，那么这就是垂直权限提升

未受保护的功能

​ 在最基本的情况下，垂直特权升级出现在应用程序不对敏感功能实施任何保护的情况下。例如，管理功能可能是从管理员的欢迎页面链接的，而不是从用户的欢迎页面链接的。但是，用户可以通过直接浏览到相关的管理 URL 来访问管理功能。

例如，网站可能在以下 URL 上托管敏感功能：

https://insecure-website.com/admin

这实际上可由任何用户访问，而不仅仅是在其用户界面中具有指向该功能的链接的管理用户。在某些情况下，管理 URL 可能会在其他位置公开，例如robots.txt文件：

https://insecure-website.com/robots.txt

即使 URL 未在任何地方公开，攻击者也可以使用词表来暴力破解敏感功能的位置。

LAB：不受保护的管理功能

在某些情况下，敏感功能没有得到强有力的保护，而是通过给它一个不太可预测的 URL 来隐藏：所谓的默默无闻的安全。仅仅隐藏敏感功能并不能提供有效的访问控制，因为用户仍然可能以各种方式发现混淆的 URL。

例如，考虑在以下 URL 托管管理功能的应用程序：

https://insecure-website.com/administrator-panel-yb556

这可能无法被攻击者直接猜测。但是，应用程序可能仍会将 URL 泄露给用户。例如，URL 可能会在 JavaScript 中公开，它根据用户的角色构建用户界面：

如果用户是管理员用户，此脚本会添加指向用户 UI 的链接。但是，包含 URL 的脚本对所有用户都是可见的，无论其角色如何。

LAB：具有不可预测url的未受保护的管理功能

基于参数的访问控制方法

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

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

​ 这种方法从根本上来说是不安全的，因为用户可以简单地修改值并获得对他们未授权的功能（例如管理功能）的访问权限。

LAB：由请求参数控制的用户角色

登录普通账户

每个请求中cookie中false改为true

LAB：可以在用户配置文件中修改用户角色

修改email

发现roleid可修改，修改后

平台配置错误导致访问控制终端

某些应用程序通过基于用户角色限制对特定 URL 和 HTTP 方法的访问来强制执行平台层的访问控制。例如，应用程序可能会配置如下规则：

DENY: POST, /admin/deleteUser, managers

对于 manager 组中的用户， 此规则拒绝访问POSTURL 上的方法/admin/deleteUser。在这种情况下，各种事情可能会出错，从而导致访问控制绕过。

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

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

LAB：可以绕过基于URL的访问控制

响应非常简单，表明它可能来自前端系统~~？？？~~

这表明后端系统正在处理来自X-Original-URL标头的 URL~~？？？~~

如果使用了”X-Original-URL”或者“X-Rewrite-URL“请求的响应包中提示”不存在的路径信息“或者是404状态，或者是”资源未发现“等相关内容，表明应用程序支持这两种特殊的请求头。此时我们可以指定”X-Original-URL”或者“X-Rewrite-URL“为”/console“或者”/admin“,尝试绕过禁止互联网访问的限制。

删除carlos

​ 与请求中使用的 HTTP 方法相关的替代攻击可能会出现。上述前端控件根据 URL 和 HTTP 方法限制访问。某些网站在执行操作时可以容忍其他 HTTP 请求方法。如果攻击者可以使用GET（或其他）方法对受限 URL 执行操作，则他们可以绕过在平台层实现的访问控制

LAB：可以绕过基于方法的访问控制

将权限提升数据包截获，修改wiener的cookie和username

Post改为Get方式

横向提权

​ 当用户能够访问另一个用户的资源而不是属于他们自己的资源时，就会出现水平权限提升。例如，如果一个员工应该只能访问自己的就业和工资记录，但实际上也可以访问其他员工的记录，那么这就是横向提权。

​ 横向提权攻击可能使用与纵向提权类似的漏洞利用方法。例如，用户通常可能使用如下所示的 URL 访问他们自己的帐户页面：

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

现在，如果攻击者将id参数值修改为另一个用户的参数值，那么攻击者可能会访问另一个用户的帐户页面，以及相关的数据和功能。

LAB：由请求参数控制的用户ID

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

LAB：用户ID请求参数控制，用户ID不可预测

在博客区找到carlos发布的博客，记录下userid

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

LAB：用户ID请求参数控制，重定向数据泄露

横向到纵向提权

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

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

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

如果目标用户是应用程序管理员，则攻击者将获得对管理帐户页面的访问权限。此页面可能会泄露管理员密码或提供更改密码的方法，或者可能提供对特权功能的直接访问。

LAB：用户ID由请求参数控制，密码公开

密码为掩码时，可能数据包中会有明文

不安全的直接对象引用

​ 不安全的直接对象引用 (IDOR) 是访问控制漏洞的一个子类别。当应用程序使用用户提供的输入直接访问对象并且攻击者可以修改输入以获得未经授权的访问时，就会出现 IDOR。它因出现在 OWASP 2007 前十名而广受欢迎，尽管它只是许多可能导致访问控制被规避的实施错误的一个例子。

LAB：不安全的直接对象引用

什么是不安全的直接对象引用 (IDOR)？
不安全的直接对象引用 (IDOR) 是一种访问控制漏洞，当应用程序使用用户提供的输入直接访问对象时会出现这种漏洞。IDOR 一词因出现在 OWASP 2007 前十名中而广为人知。然而，这只是可能导致访问控制被规避的许多访问控制实施错误的一个例子。IDOR 漏洞最常与水平权限提升相关，但它们也可能与垂直权限提升相关。

IDOR 示例
有许多访问控制漏洞的例子，其中用户控制的参数值用于直接访问资源或功能。

直接引用数据库对象的 IDOR 漏洞
考虑一个网站，它通过从后端数据库检索信息，使用以下 URL 访问客户帐户页面：

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

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

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

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

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

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

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

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

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

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

LAB：多步流程，一步无法访问控制

最后一步确认未作保护、替换另一普通用户的cookie，username

重放

基于Referer的访问控制

​ 一些网站基于RefererHTTP 请求中提交的标头进行访问控制。的Referer报头由浏览器一般加入请求，以指示从其中请求被发起的网页。

例如，假设一个应用程序在 处对主管理页面严格执行访问控制/admin，但对于子页面（例如/admin/deleteUser仅检查Referer标题）。如果Referer标头包含主/adminURL，则允许请求。

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

LAB：基于Referer的访问可控制

基于位置的访问控制

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

如何防止访问控制漏洞

通常可以通过采用深度防御方法并应用以下原则来防止访问控制漏洞：

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