PortSwigger Academy | Access control : 访问控制

文章目录

总结

  • 没思路多看前端页面里写了什么,可能有惊喜
  • 对请求响应中的truefalse要非常敏感
  • 对各种id也要敏感
  • X-Original-URL: /admin 改变url路由
  • 多步骤功能的访问控制绕过

在本节中,我们将讨论什么是访问控制安全性,描述权限升级和访问控制可能产生的漏洞类型,并总结如何防止这些漏洞。

访问控制是什么?

访问控制(或授权)是对谁(或什么)可以执行尝试的操作或访问他们所请求的资源的约束条件的应用。 在Web应用程序的上下文中,访问控制取决于身份验证和会话管理:

  • 身份验证可以识别用户并确认他们就是他们所说的身份。

  • 会话管理识别同一用户正在发出哪些后续HTTP请求。

  • 访问控制确定是否允许用户执行他们尝试执行的操作。

损坏的访问控制是一个经常遇到且通常很关键的安全漏洞。 访问控制的设计和管理是一个复杂而动态的问题,将业务,组织和法律约束应用于技术实施。 访问控制设计决策必须由人决定,而不是技术,而且潜在的错误可能性很高。

从用户的角度来看,访问控制可以分为以下几类:

  • 垂直访问控制

  • 水平访问控制

  • 上下文相关的访问控制

在这里插入图片描述

垂直访问控制

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

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

水平访问控制

水平访问控制是一种机制,用于将资源的访问限制为专门允许访问这些资源的用户。

使用水平访问控制,不同的用户可以访问同一类型的资源的子集。 例如,银行业务应用程序将允许用户查看交易并从其自己的帐户进行付款,但不能查看任何其他用户的帐户。

上下文相关的访问控制

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

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

损坏的访问控制示例

当用户实际上可以访问某些资源或执行某些他们不应该访问的资源时,存在损坏的访问控制漏洞。

垂直特权升级

如果用户可以访问他们被禁止访问的功能,那么这就是垂直特权升级。 例如,如果非管理用户实际上可以访问可以删除用户帐户的管理页面,则这是垂直特权升级。

未受保护的功能

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

例如,一个网站可能在以下URL上托管敏感功能:

https://insecure-website.com/admin

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

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

即使未在任何地方公开该URL,攻击者也可以使用单词表来强行执行敏感功能的位置。

Lab: Unprotected admin functionality

robots.txt

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

例如,考虑一个在以下URL上承载管理功能的应用程序:

https://insecure-website.com/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>

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

Lab: Unprotected admin functionality with unpredictable URL

在这里插入图片描述

基于参数的访问控制方法

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

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

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

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

Lab: User role controlled by request parameter

在这里插入图片描述

Lab: User role can be modified in user profile

更改自己的id即可
在这里插入图片描述

平台配置错误导致访问控制中断

某些应用程序通过基于用户角色限制对特定URL和HTTP方法的访问来在平台层实施访问控制。 例如,一个应用程序可能配置如下规则:

DENY: POST, /admin/deleteUser, managers

对于管理器组中的用户,此规则拒绝访问URL /admin/deleteUser上的POST方法。 在这种情况下,各种事情都会出错,从而导致访问控制绕过。

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

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

Lab: URL-based access control can be circumvented

X-Original-URL: /admin
在这里插入图片描述
妙啊
在这里插入图片描述
与请求中使用的HTTP方法有关的替代攻击可能会出现。 上面的前端控件基于URL和HTTP方法限制访问。 某些网站在执行操作时可以使用其他HTTP请求方法。 如果攻击者可以使用GET(或其他)方法对受限制的URL执行操作,则他们可以规避在平台层实现的访问控制。

Lab: Method-based access control can be circumvented

将POST方法改为GET方法即可

在这里插入图片描述

横向特权升级

当用户能够访问属于另一个用户的资源而不是他们自己的那种类型的资源时,就会出现水平特权升级。 例如,如果某个员工仅应能够访问自己的工作和工资记录,但实际上也可以访问其他员工的记录,则这就是横向特权提升。

水平特权升级攻击可能使用与垂直特权升级类似的利用方法。 例如,用户通常可以使用如下URL来访问自己的帐户页面:

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

现在,如果攻击者将id参数值修改为另一个用户的ID参数值,则攻击者可能会访问具有相关数据和功能的另一个用户的帐户页面。

Lab: User ID controlled by request parameter

/my-account?id=carlos

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

Lab: User ID controlled by request parameter, with unpredictable user IDs

carlos发的文章里可以找到id

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

Lab: User ID controlled by request parameter with data leakage in redirect

访问id=carlos然后burp中查看即可

水平到垂直特权升级

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

例如,攻击者也许可以使用针对水平特权升级已经描述的参数篡改技术来访问另一个用户的帐户页面:

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

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

Lab: User ID controlled by request parameter with password disclosure

?id=administrator

在这里插入图片描述

不安全的直接对象引用

不安全的直接对象引用(IDOR : Insecure direct object references)是访问控制漏洞的子类别。 当应用程序使用用户提供的输入直接访问对象并且攻击者可以修改输入以获得未经授权的访问时,就会发生IDOR。 它以其在OWASP 2007十强中的出现而得到普及,尽管它只是许多实现错误的一个例子,该错误可能导致访问控制被规避。

Lab: Insecure direct object references

这里的对象引用时/download-transcript/1.txt
在这里插入图片描述

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

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

  • 加载表单,其中包含特定用户的详细信息。

  • 提交更改。

  • 查看更改并确认。

有时,网站将对其中一些步骤实施严格的访问控制,而忽略其他步骤。 例如,假设访问控制已正确应用于第一步和第二步,但不适用于第三步。 实际上,该网站假定用户只有完成了正确控制的第一步后,才可以进入第3步。 在这里,攻击者可以跳过前两个步骤并直接使用所需参数提交对第三步的请求,从而获得对功能的未授权访问。

Lab: Multi-step process with no access control on one step

carlos的身份重放提升权限的第二步即可
在这里插入图片描述

基于referer的访问控制

某些网站的访问控制基于HTTP请求中提交的Referer标头。 通常,浏览器会将Referer标头添加到请求中,以指示发起请求的页面。

例如,假设应用程序对/admin上的主管理页面强加了强制性的访问控制,但是对于/admin/deleteUser等子页面,它仅检查Referer标头。 如果Referer标头包含主要的/admin URL,则允许该请求。

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

Lab: Referer-based access control

referer
在这里插入图片描述

基于位置的访问控制

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

如何防止访问控制漏洞

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

  • 切勿仅依靠混淆来进行访问控制。

  • 除非打算公开访问资源,否则默认情况下将拒绝访问。

  • 尽可能使用单个应用程序范围的机制来强制执行访问控制。

  • 在代码级别,使开发人员必须声明每个资源允许的访问,并默认拒绝访问。

彻底审核和测试访问控制,以确保它们按设计工作。


访问控制安全模型

在本节中,我们解释什么是访问控制安全模型,并讨论最常遇到的模型。

什么是访问控制安全模型?

访问控制安全模型是一组独立于技术或实现平台的访问控制规则的正式定义。 访问控制安全模型在操作系统,网络,数据库管理系统以及后台,应用程序和Web服务器软件中实现。 这些年来,已经设计了各种访问控制安全模型,以使访问控制策略与业务或组织规则以及技术变化相匹配。

程序访问控制 Programmatic access control

通过编程访问控制,用户特权矩阵存储在数据库或类似数据库中,并且参考该矩阵以编程方式应用访问控制。 这种访问控制方法可以包括角色或组或单个用户,流程的集合或工作流,并且可以非常精细。

自由访问控制(DAC) Discretionary access control

使用任意访问控制,将根据用户或指定的用户组来限制对资源或功能的访问。 资源或功能的所有者可以向用户分配或委派访问权限。 该模型非常精细,具有对单个资源或功能和用户的访问权限。 因此,模型的设计和管理可能变得非常复杂。

强制访问控制(MAC)Mandatory access control

强制性访问控制是一种访问控制的集中控制系统,其中,对象对某些对象(文件或其他资源)的访问受到限制。 值得注意的是,与DAC不同,资源的用户和所有者没有能力委派或修改其资源的访问权限。 该模型通常与基于军事许可的系统相关联。

基于角色的访问控制(RBAC) Role-based access control

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

当有足够的角色来适当地调用访问控制,但又没有太多的角色使模型过于复杂且难以管理时,RBAC最为有效。


不安全的直接对象引用(IDOR)

Insecure direct object references (IDOR)

在本节中,我们将解释什么是不安全的直接对象引用(IDOR),并描述一些常见的漏洞。

什么是不安全的直接对象引用(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

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

Lab: Insecure direct object references

这里的对象引用时/download-transcript/1.txt
在这里插入图片描述

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值