访问控制与权限提升初探

合集 - burpsuite靶场学习(12)
1.API初探2.XSS初探及实验3.业务漏洞初探4.命令注入初探5.条件竞争初探6.SSRF初探7.服务器端漏洞基础
8.访问控制与权限提升初探
9.XXE初探10.nosql注入初探11.SQL注入备忘录12.SQL注入初探
收起

一、 前置知识了解

什么是访问控制？

访问控制是对有权执行操作或访问资源的人员或内容施加约束。在 Web 应用程序的上下文中，访问控制依赖于身份验证和会话管理：

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

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

垂直访问控制

垂直访问控制是将敏感功能的访问限制为特定类型的用户的机制。

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

水平访问控制

水平访问控制是将资源访问限制为特定用户的机制。

使用水平访问控制，不同的用户可以访问相同类型的资源子集。例如，银行应用程序将允许用户从自己的账户查看交易和付款，但不允许任何其他用户的账户。

上下文相关访问控制

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

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

二、访问控制损坏的示例

当用户可以访问资源或执行他们不应该能够访问的操作时，存在损坏的访问控制漏洞。

1、垂直权限提升

如果用户可以访问不允许他们访问的功能，则这是垂直权限提升。例如，如果非管理用户可以访问管理页面，他们可以在其中删除用户帐户，则这是垂直权限提升。

① 未受保护的功能

最基本的是，当应用程序不对敏感功能强制实施任何保护时，就会出现垂直权限提升。例如，管理功能可能从管理员的欢迎页面链接，但不能从用户的欢迎页面链接。但是，用户可以通过浏览到相关的管理 URL 来访问管理功能。

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

https://insecure-website.com/admin

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

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

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

在某些情况下，通过为其提供不太可预测的 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 的脚本对所有用户都是可见的，无论其角色如何。

实验1、未受保护的管理功能

此实验室有一个未受保护的管理面板。

利用前面学习到的信息泄露、目录扫描等，尝试寻找不用验证并且未被保护的管理界面。

通过/robots.txt 文件，来查看是否有，发现有，访问进行测试。

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

某些应用程序在登录时确定用户的访问权限或角色，然后将此信息存储在用户可控制的位置。这可能是：

  • 一个隐藏的字段。
  • Cookie。
  • 预设查询字符串参数。

应用程序根据提交的值做出访问控制决策。例如：

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

这种方法是不安全的，因为用户可以修改他们无权访问的值和访问功能，例如管理功能。

实验2、由请求参数控制的用户角色

验在/admin中有一个管理面板，用于识别使用可伪造 Cookie 的管理员。

首先就是进行抓取数据包，看在登录的时候，是否有可以越权的操作。

实验有提示，在cookie中可伪造，抓取后发现，在cookie中有这样一个字段admin:flase

尝试修改为true，发送，发现以管理员的权限登入了。不过之后的每一个操作都需要抓包修改，因为默认情况下，该账户是无管理员权限的，这个修改是一次性的，每次带着cookie的时候，都会有检测是否为管理员，所以每一个操作，都需要修改cookie值

实验3、可以在用户配置文件中修改用户角色

本实验室在/admin中有一个管理面板。只有roleid为2 的登录用户才能访问它。

抓取登录的数据包，发现在登录的时候，并没有像上面的可修改的地方，提示有了一个路径，一般情况下需要进行信息收集来获得网站的其他目录，这里有提示，就省时间。

这里的roleid参数很重要，如果实验不提供的话，自己估计很难找到这个参数来进行修改。

首先每个功能测试一遍，并使用burp抓包，进行分析，发现这个参数基本上没有地方可插入。在登录的时候插入这个参数，并没有实现。

在进行邮箱更改的时候，POST方法中的请求体里有json的数据进行传输，尝试在这里面添加后实现了权限的提升。

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

某些应用程序在平台层强制实施访问控制。他们通过根据用户的角色限制对特定 URL 和 HTTP 方法的访问来实现此目的。例如，应用程序可以按如下方式配置规则：

DENY: POST, /admin/deleteUser, managers

此规则拒绝对 managers 组中的用户访问 URL 上的POST方法。在这种情况下，各种事情都可能出错，导致访问控制绕过。/admin/deleteUser

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

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

另一种攻击与请求中使用的 HTTP 方法GET有关。前面部分中介绍的前端控件根据 URL 和 HTTP 方法限制访问。某些网站在执行操作时允许不同的 HTTP 请求方法。如果攻击者可以使用（或其他）方法对受限制的 URL 执行操作，则可以绕过在平台层实现的访问控制。

实验4、 可以规避基于 URL 的访问控制

此网站在/admin 中有一个未经身份验证的管理面板，但前端系统已配置为阻止对该路径的外部访问。但是，后端应用程序是在支持X-Original-URL标头的框架上构建的。

因为是实验，才知道可以应用程序的框架建立在支持X-Original-URL上的，若是不知道的话，就需要慢慢尝试。

过程：抓取访问/时的数据包，尝试在HTTP请求时，加上X-Original-URL尝试覆盖URL，达到访问管理界面，注意是覆盖URL地址，也就是原本的URL地址是/但是经过这个表头，就变成了/admin，需要注意的是，这里并不是我们手动输入URL地址直接访问的，而是间接的访问的，所以才会成功，因为原本的直接访问是被进行了限制。

这里就是第一步。

当绕过这个直接以管理员身份操作时，注意，这个时候的请求是我们主动请求的，所以一定会被拒绝，因为不让直接访问/admin的界面的，所以还是和上面一样，需要修改

这里把主动请求目录换成允许访问的，然后在HTTP请求表头中添加x-original-url的覆盖地址，注意的是，这里我们是进行删除用户的操作，删除的请求是通过username=xxx的形式。

但是不能直接请求，所以通过覆盖地址后，进行拼接，也就是请求后，x-original-ual会把原本的请求地址/替换成/admin/delete，那么知道这个，username就知道放在主动请求地址的后面即可。当表头替换地址成功，就会拼接成这个/admin/delete?username=carlos

这个通常出现在401或者403的时候进行尝试能否绕过，我们这里就是尝试进行401的处理

常用的绕过有 :

X-Original-URL和X-Rewrite-URL
用户可以使用这俩请求标头覆盖请求URL中的路径，尝试绕过对更高级别的缓存和Web服务器的限制

使用Referer标头绕过Web服务器的限制
Referer请求头包含了当前请求页面的来源页面的地址，即表示当前页面是通过此来源页面里的链接进入的。服务端一般使用Referer请求头识别访问来源。

代理IP
一般开发者会通过Nginx代理识别访问端IP限制对接口的访问，尝试使用
X-Forwarded-For、X-Forwared-Host 等标头绕过Web服务器的限制。

实验5、可以规避基于方法的访问控制

本实验部分基于请求的 HTTP 方法实现访问控制

首先实验给了一个管理员的账户，让我们去了解这个过程，通过抓取到升权限的数据包进行分析

就是一个普通的管理员账户来进行升级，看不出什么

后面的降权也是一样的数据包，退出管理员账户，登录普通账户，抓取数据包，发现也没有什么地方，那么从cookie下手试试，毕竟管理员账户退出的情况下，cookie也没了，以普通账户的cookie进行测试，看能否有操作。

这里cookie更改为普通用户的cookie，这个数据包是之前登录管理员账户时留下的数据包，用来观察，这个实验也是进行了解管理员的一些操作，会有哪些。

cookie也不行，已经没什么东西了，测试http的请求方法.

采用postx的请求方法，发现返回不一样，那么其他的请求方法是什么返回呢

POSTX请求，也是http中的一种请求方式，常见的还有put、delete、patch等。

更改为GET方式，发现是个重定向页面，说明有希望，跟踪跳转，发现提权成功，经测试，在post数据包的基础上，把请求方法改成put、patch也是可以的，说明对post请求方法进行了限制

也就是这个数据包通过一个已经登录的普通账户的cookie，也可以进行提权，并且可以给任何已经有的账户进行提权操作。当然前提还是需要知道管理员操作时候产生的数据包。而且这里并没有对cookie进行验证，真实的环境肯定比这牢靠，很难获得这样的数据包，就算获得，也有其他的检测，使得无法完成提权

为什么呢，就像实验名称，服务器应该是对请求方法进行了限制，但是请求方法有很多

为什么POST请求会有不同的结果？

POST请求是HTTP协议中的一种请求方法，用于向服务器提交数据。与GET请求不同，POST请求将数据放在请求体中，而不是放在URL中。因此，POST请求的结果可能会受到以下因素的影响：

  1. 请求参数：POST请求可以携带更多的数据，包括表单数据、JSON数据等。不同的请求参数可能会导致服务器端处理逻辑的不同，从而产生不同的结果。
  2. 服务器端处理逻辑：服务器端根据接收到的POST请求参数进行处理。不同的服务器端处理逻辑可能会导致不同的结果。例如，对于同一个POST请求，服务器端可能会根据参数的不同返回不同的数据或执行不同的操作。
  3. 接口设计：POST请求通常用于提交数据，因此接口的设计对于结果的不同也起着重要的作用。接口设计应该合理，明确指定POST请求的预期结果，并根据实际需求进行处理。
  4. 网络传输：网络传输可能会导致POST请求的结果不同。例如，网络延迟、丢包等问题可能会导致请求超时或数据丢失，从而影响结果。

综上所述，POST请求的结果可能会受到请求参数、服务器端处理逻辑、接口设计和网络传输等因素的影响。为了获得一致的结果，需要确保请求参数正确、服务器端处理逻辑一致、接口设计合理，并保证网络传输的稳定性。

④ 由于 URL 匹配差异导致的访问控制中断

网站在将传入请求的路径与定义的终结点的匹配程度上可能会有所不同。例如， 和 它们可能容忍不一致的大小写，因此对的请求可能仍映射到终结点。如果访问控制机制的容忍度较低，它可能会将它们视为两个不同的终结点，并因此无法强制实施正确的限制。/ADMIN/DELETEUSER /admin/deleteUser

如果使用 Spring 框架的开发人员启用了该选项，也会出现类似的差异。这允许将具有任意文件扩展名的路径映射到没有文件扩展名的等效终结点。换言之，请求仍将与模式匹配。在 Spring 5.3 之前，默认情况下启用此选项。

useSuffixPatternMatch /admin/deleteUser.anything /admin/deleteUser

在其他系统上，您可能会遇到是否被视为不同终结点的差异。在这种情况下，您可以通过在路径上追加尾部斜杠来绕过访问控制。/admin/deleteUser /admin/deleteUser/

2、水平权限提升

如果用户能够访问属于其他用户的资源，而不是他们自己的该类型的资源，则会发生水平权限提升。例如，如果员工可以访问其他员工以及他们自己的记录，则这是横向权限提升。

水平权限提升攻击可能使用与垂直权限提升类似的攻击方法。例如，用户可以使用以下 URL 访问自己的帐户页面：

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

如果攻击者将参数值修改为其他用户的参数值，则可能会访问其他用户的帐户页面以及相关的数据和功能。id

注意

这是不安全的直接对象引用 （IDOR） 漏洞的一个示例。当用户控制器参数值用于直接访问资源或功能时，就会出现此类漏洞。

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

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

实验6 由请求参数控制的用户 ID

此实验室在用户帐户页面上存在一个水平权限提升漏洞。

若要求解实验室，请获取用户carlos的 API 密钥并将其作为解决方案提交。

以一个已知账户登录后，可以看到URL中有关于账户的信息

my-account?id=wiener 类似于这种，是否通过修改URL中的账户信息来访问其他账户呢。

测试后，发现修改后可直接访问到其他账户，完成水平越权

实验7 用户 ID 由请求参数控制，用户 ID 不可预测

实验室在用户帐户页面上存在一个水平权限提升漏洞，但使用 GUID 标识用户。

若要求解实验室，请找到carlos的 GUID，然后提交其 API 密钥作为解决方案。

使用唯一标识符进行账户的确认，但是如果网站中的关于账户的所有功能都是以这个为基准的话，就能被找到别人的id。

如，在一个博客网站中，用这个进行账户的确认识别，如果某个账户发表了一个文章，并且是以他当前用户发表的，那么网站在识别谁发表的时候，以这个id作为识别的话，别人通过抓包是否能通过查看文章中的作者名称的形式，看到他的id呢

首先抓取登录一个已知账户的数据包，发现，登录成功后跳转到账户界面，并且是以这个id为谁的界面。猜测修改这个id可以查看不同账户的界面。并经过测试，不过重新登录多少次，始终是这个id，说明这个就相当于用户名，只是这个很难被猜到。

在网站上寻找数据，发现这有个作者的选项，可直接点击，进入作者的主页

点击后，通过抓取的数据包可以看到，有一个id，并且构造与之前账户的id形式基本相同。

然后把这个作者的id复制，并访问之前登录的账户界面，把id修改为作者的id，发现直接以作者的身份访问他的账户界面了，水平越权完成

这个和上面的以id=账号名的形式基本一样，只是这个所谓的唯一标识符很难被猜测，太长了。

但是如果网站中的所有关于识别账户的时候都会以这种形式进行的话，也是可以获取到这个id的，比如这里访问作者的主页的时候，给出作者的id了。因为当网站知道访问的是某个作者的时候，他也是根据这个id去识别作者是谁的，所以就使得这个id处于可获取的。

实验8 用户 ID 由请求参数控制，重定向中出现数据泄漏

此实验包含一个访问控制漏洞，其中敏感信息在重定向响应的正文中泄露。

若要求解实验室，请获取用户carlos的 API 密钥并将其作为解决方案提交。

在已经登录的账户的界面处，进行url修改，url中还是包含用户名信息，用于识别用户。此次是即使url中的参数id可修改，但是会对用户进行登录状态的检测，如果没有登录直接修改id 的话，会进行页面跳转，返回登录界面。

抓包进行分析，从登录的时候进行抓取，没有什么信息可看，当进行到账户界面的时候，尝试把id修改成其他用户，然后再分析。通过抓取到的数据包发现，当把id修改后，因为没有登录，然后跳转到登录界面，但是在跳转的数据包中，下面竟然有html的代码，也就是302跳转的时候有页面，查看后发现，这个跳转页面中包含了其他id修改后的账户的界面信息。

3、水平到垂直权限提升

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

攻击者或许能够使用已针对水平权限提升描述的参数篡改技术访问其他用户的帐户页面：

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

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

实验9 用户 ID 由请求参数控制，并带有密码泄露功能

实验室具有用户帐户页面，其中包含当前用户的现有密码，并预填充了屏蔽输入。

本实验和上面差不多，由URL中的id参数可直接查看其他账户的界面，但是因为没有登录，所以只能看到其他账户的界面，不过像这里，默认的账户界面中有一个更改密码的选项，并且把原密码默认的存在表单中，所以，当直接修改id为其他账户时，可以通过数据包看到账户的原密码，并且后面可以通过这个密码直接登录。

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

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

什么是不安全的直接对象引用 （IDOR）？

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

IDOR 示例

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

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

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

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

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

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

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

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

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

在这种情况下，攻击者只需修改文件名即可检索其他用户创建的脚本，并可能获取用户凭据和其他敏感数据。

实验10 不安全的直接对象引用

实验将用户聊天日志直接存储在服务器的文件系统上，并使用静态 URL 检索它们。

聊天日志可下载，并且在聊天日志中可能存在信息的泄露，如密码等。

通过访问页面，然后抓取数据包，当看到有一个聊天对话框的时候，测试与其对话，发现会进行回复，并且在发送消息旁，有一个transcript（谈话全文）的选项，点击后，发现会把最近的对话下载。

那么抓取数据包发现，这个下载的对话，是一个txt文件，并且文件名是可检索的，是以数字1，2，3等进行命名，当我对话的时候，并进行下载，发现文件为2.txt，再进行对话，下载，为3.txt，说明由规律，并且在我新的对话之前，可能有一个1.txt，是别人的对话，抓包修改为1.txt，发现文件中，是对话记录，并且其中有一个密码泄露

5、多步骤进程中的访问控制漏洞

许多网站通过一系列步骤实现重要功能。这在以下情况下很常见：

  • 需要捕获各种输入或选项。
  • 在执行操作之前，用户需要查看并确认详细信息。

例如，更新用户详细信息的管理功能可能涉及以下步骤：

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

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

实验11 多步骤流程，一步无访问控制

此实验室有一个管理面板，其中包含用于更改用户角色的有缺陷的多步骤过程。您可以通过使用凭据登录来熟悉管理面板。administrator:admin

管理员账户登录后的流程分析：

登录------>登录界面----->管理面板---->选择提升权限--->确定是否提升--->提升成功

抓包分析：

登录界面，验证用户名和密码是否正确，正确跳转到账户界面

管理面板，有给用户提升/降低权限的功能模块 /admin 和 /admin/roles

当选择其中一项模块进行操作时，都会进行确认，有个单独的确认是否操作的数据包

/admin/roles 请求体为 action=upgrade&confirmed=true&username=carlos

确认后才会进行下一步操作。

以普通用户登录进行尝试：

登录后并没有管理面版，所以直接访问这个网站目录/admin进行测试。提示只有以管理员账户登录才能访问，分析之前以管理员抓取的数据包，想想有没有什么办法绕过这个账户的检测，就可以直接使用管理面板中的功能

通过上面的以管理员账户的数据包再次分析：

首先登录，这个需要用户名和密码，无法绕过

第二，请求提权，然后需要确认，这个即使修改成功，但也需要下一步才能成功

第三，确认提权，然后成功。可以直接从这个下手，因为只要这个可以成功，也就不需要验证，只要能够绕过第一步就行。

使用抓取到的第三步的数据包，首先直接访问，发现不能，出现401，因为这时已经退出管理员账户，猜测，检测或者cookie失效。用普通账户的cookie放在这里进行测试，发现可以直接绕过，并修改成功，说明这里不检测cookie是否为某某账户，只是简单的用来访问网站所需要的，或者说检测是否以管理员登录的时候，并不检测cookie值。

6、基于 Referer 的访问控制

某些网站基于在 HTTP 请求中提交的标头Referer 进行访问控制。浏览器可以将标头Referer添加到请求中，以指示哪个页面发起了请求。

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

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

实验12 基于引用程序的访问控制

此实验室根据 Referer 标头控制对某些管理功能的访问。您可以通过使用凭据登录来熟悉管理面板。administrator:admin

与上面实验一样，先通过以管理员账户登录，抓取数据包并分析

登录---->账户界面---->访问管理面板---->提权------>成功后返回管理面板

然后以普通账户登录，先进行上面的所有学过的进行测试

访问/admin，提升要管理员账户登录才可以访问

上面的方法测试后发现不行，无论是http请求中加入x-original-url，或者更改http的请求方法，都不行。

但是直接在提权的数据包修改，更改cookie为登录的普通账户的cookie就可以了，但是当把referer的值修改就不能成功了。

对管理员账户登录的流程数据包再次分析：

在上面流程的每一步，发现有一个http请求头referer，总是在变化

  1. 当请求路径是/login时，referer是 网址/login
  2. 当请求路径是/my-account?id=administrator时，referer是 网址/login
  3. 当请求路径是/admin时，referer是 网址/my-account?id=administrator
  4. 当请求路径是/admin-roles?username=carlos&action=upgrade时，referer是 网址/admin

由此猜测，每一次的请求路径，都可能是访问下一个路径的一个referer的值，并且可能在进行需要管理员权限的操作时，通过referer检测是否有权限修改

这样其实也可以自己构造一个提权数据包，只需要有一个普通账户的cookie值，然后知道请求的路径和参数，referer值加上即可成功

7、基于位置的访问控制

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

三、如何防止访问控制漏洞

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

  • 切勿仅依靠混淆进行访问控制。
  • 除非资源旨在公开访问，否则默认情况下拒绝访问。
  • 尽可能使用单个应用程序范围的机制来强制实施访问控制。
  • 在代码级别，强制开发人员声明允许对每个资源的访问，并默认拒绝访问。
  • 彻底审核和测试访问控制，以确保它们按设计工作。
posted @   whitehe  阅读(31)  评论(0)  编辑  收藏  举报  
相关博文：
·  SSRF初探
·  API初探
·  访问控制漏洞和权限提升 | PortSwigger（burpsuite官方靶场）| Part 3
·  access control
·  访问控制漏洞和权限提升 | PortSwigger（burpsuite官方靶场）| Part 1
阅读排行：
· 10年+ .NET Coder 心语 ── 封装的思维：从隐藏、稳定开始理解其本质意义
· 提示词工程——AI应用必不可少的技术
· 地球OL攻略 —— 某应届生求职总结
· 字符编码：从基础到乱码解决
· SpringCloud带你走进微服务的世界
点击右上角即可分享
微信分享提示
AI IDE Trae