Broken Access Control: Pentester’s Gold Mine

破坏的访问控制: 彭特斯特的金矿

Hey folks, hope you all are doing well!
Recently OWASP Top 10 2021 was released and the Broken Access Control grabbed the first position with the most serious security risk. Broken Access Control issues are present when the restrictions imposed are only on the frontend and the backend APIs are never secured. Using the easily enumerable IDs is the root cause of Insecure Direct Object References (IDORs).

嘿,伙计们,希望你们都做得很好!最近,OWASP Top 102021发布,破坏访问控制以最严重的安全风险占据了第一位。如果限制仅限于前端,而后端 api 从未得到保护,则存在访问控制中断问题。使用易于枚举的 id 是不安全直接对象引用(Insecure Direct Object References,IDORs)的根源。

In this blog, I will be mostly focusing on my approach and scenarios which I encountered.

在这个博客中,我将主要关注我遇到的方法和场景。

Broken Access Control 101

破损的访问控制101

Broken Access Control in simple words means performing the actions outside the set of allowed permissions.

破坏访问控制简单来说就是在允许的权限集合之外执行操作。

Whenever I test any application which has user roles, I ask myself the following questions:

每当我测试任何具有用户角色的应用程序时,我都会问自己以下问题:

  • What are the permissions of this user?

    这个用户的权限是什么?

  • Is the user having permission to perform this action?

    用户是否具有执行此操作的权限?

  • Can this user view this data?

    这个用户可以查看这些数据吗?

  • What will be the business impact if the imposed access control can be broken?

    如果强制的访问控制可能被破坏,将会对业务产生什么影响?

Paisa hi paisa hoga, Broken Access Control, Bug Bounty Hunters, Bug Bounty memes, Phir Hera Pheri

Scenarios Encountered While Testing Applications for Broken Access Control

测试应用程序的访问控制中断时遇到的场景

Let’s see some of the scenarios which I encountered.

让我们来看看我遇到的一些场景。

Scenario 1 – IDOR in Password Vault

场景1-IDOR 在密码保险库中

The application was a password vault. The application allowed the user to store and update the usernames, passwords, ssh keys, and website URLs. When I was testing update account functionality, the application for the password field said: “Leave blank to keep current password”.

这个应用程序是一个密码库。这个应用程序允许用户存储和更新用户名、密码、 ssh 密钥和网站 url。当我测试更新帐户功能时,密码字段的应用程序说: “保留空白以保留当前密码”。

Broken Access Control, Blank Password, Insecure Direct Object Reference, Password vault

Seeing this I questioned myself: How is it binding the password to this account?

看到这个,我问自己: 怎么把密码绑定到这个账户?

After observing the POST request for saving the password I came to know that the application is linking the passwords using a credential_id.

在观察 POST 请求保存密码之后,我知道应用程序正在使用凭据 _ id 链接密码。

Broken Access Control, Credential ID, API, JSON

The post request made me curious. So, I meddled with the request by changing it to some other id. I was surprised to see that the account got updated; however, I wondered where I could see the updated passwords. I checked the application and pondered upon a button that tracks password history and showcases passwords to the users. I was shocked to see a password that was never mine! Hence, Insecure Direct Object Reference (IDOR) led me to enumerate the passwords of all accounts in the organization leading to a simple Broken Access Control issue.

这个职位的要求让我很好奇。因此,我通过将请求更改为其他 id 来干扰请求。我很惊讶地发现这个账户得到了更新; 但是,我想知道在哪里可以看到更新的密码。我检查了这个应用程序,然后思考了一个按钮,这个按钮可以跟踪密码历史记录并向用户展示密码。我很震惊地看到一个从来不是我的密码!因此,不安全的直接对象引用(Insecure Direct Object Reference,IDOR)使我枚举组织中所有帐户的密码,导致了一个简单的访问控制中断问题。

Scenario 2 – Breaking the Business Logic in Energy Tender Management Platform

场景2-打破能源投标管理平台的业务逻辑

In this scenario, the application was some sort of energy tender management platform. In this, the tender was to be approved by higher privileged users. The lower privileged users can only draft the tender and submit it to the Admin for approval. There was one business logic imposed in this application which is when any user is Editing the tender details, the other user cannot edit it. For example if the USER1 is editing the questionnaire the USER2 cannot. The tender is locked for this USER2. When the USER2 tried to open the tender for edit while the USER1 is editing, the application will give the following error message:

在这种情况下,应用程序是某种类型的能源投标管理平台。在这种情况下,投标将获得较高特权用户的批准。较低的特权用户只能草案的投标,并提交给管理员批准。这个应用程序中有一个业务逻辑,当任何用户编辑投标细节时,其他用户不能编辑它。例如,如果 user1正在编辑调查表,那么 user2就不能编辑。这个 user2的投标被锁定。当 user2试图在 user1编辑时打开标书进行编辑时,应用程序将给出以下错误消息:

Broken Access Control, Questionnaire Opened by other user, Business Logic

As per my assumption, the business logic behind the application is that when the Admin is approving the questionnaire, the lower privileged user must not edit it. Because when I tried updating the tender directly by making a PATCH request to the API. The API responded with the following message:

根据我的假设,应用程序背后的业务逻辑是,当 Admin 批准调查表时,低权限用户不能编辑它。因为当我尝试通过向 API 发出一个 PATCH 请求来直接更新投标时。这个 API 回应了以下信息:

Broken Access Control, Questionnaire locked, PUT method enabled, Allow header in response

While looking at the response, I discovered that the PUT method is allowed in this case. I changed the method to the PUT method and forwarded the request. To my surprise, the questionnaire got updated. So, by changing the method, I was able to bypass the imposed access control.

在查看响应时,我发现在这种情况下可以使用 PUT 方法。我将方法更改为 PUT 方法并转发请求。令我惊讶的是,调查问卷被更新了。因此,通过改变方法,我能够绕过强加的访问控制。

Scenario 3 – Pattern-based Shipment IDs

情景3——基于模式的装运 id

This application was for fleet management. This application segregates the companies into groups so that each company can view its shipments. The API request was in the following manner:

此应用程序用于车队管理。这个应用程序将公司分组,以便每个公司都可以查看自己的货件。原料药申请的方式如下:

https://company.com/api/shipments/XXXXXXXX

Here the id was in capital letters and eight characters long.

这里的 id 是大写字母和八个字符长。

Now, if we think of brute-forcing the same, it would have around 268 permutations. I dug a bit deeper to analyze if there is any pattern in the id, and it turned out that the first four characters were the first four letters of the name of the organization and the last four letters were random characters.

现在,如果我们考虑蛮力强迫同样的,它将有大约268种排列。我进一步分析了 id 中是否有任何模式,结果发现前四个字符是组织名称的前四个字母,后四个字母是随机字符。

So, for example, if the company’s name is TESTING Ltd, the id would be TESTxxxx, where x is any alphabet.

因此,举例来说,如果公司的名称是 TESTING Ltd,id 应该是 TESTxxxx,其中 x 是任何字母表。

Now the permutations are lowered down to 264. So by knowing the name of the company, I was able to brute force the rest of the characters and view their shipments. Analyzing the id made the permutations much lower and practically possible. It made the IDOR almost possible.

现在排列被降低到264。因此,通过知道公司的名称,我能够暴力破解其余的字符,并查看他们的出货量。分析 id 使排列变得更低,更实际。这使得 IDOR 几乎成为可能。

Scenario 4 – Using Database of Another User

情况4-使用其他用户的资料库

Here the application was a project management platform. It allows users to upload databases. The user can also create projects in the application. While working on it, I observed that the dataset uploaded by the user could be associated with the project.

这里的应用是一个项目管理平台。它允许用户上传数据库。用户还可以在应用程序中创建项目。在进行这项工作时,我观察到用户上传的数据集可能与项目有关。

Broken Access Control, Attach Database, Project management platform

When I uploaded the dataset, the application responded with an integer as the dataset id. The application stores the dataset and assigns a sequential numerical integer as an id. With such IDs, there can be the possibility of IDOR.

当我上传数据集时,应用程序以一个整数作为数据集 id 响应。应用程序存储数据集并将一个顺序数字整数作为 id 分配。有了这样的 id,就有可能出现 IDOR。

Broken Access Control,Database id, Insecure Direct Object Reference

So, while creating the project, I observed that the application was passing a dataset. I changed it to the dataset of another user and successfully saved the project. Hence, I was able to attach the database of other users to my project.

因此,在创建项目时,我观察到应用程序正在传递一个数据集。我将其更改为另一个用户的数据集,并成功地保存了该项目。因此,我能够将其他用户的数据库附加到我的项目中。

Scenario 5 – Analyzing the Flow of Requests

场景5——分析请求流

In this case, the application was for entity and database management. It had a view-only user and an admin role. There were many vulnerable modules in this application. I was trying to perform all the CRUD operations from the view-only user’s session. The operation which grabbed my attention was DELETE. The application implemented a 2 step delete process:

在本例中,应用程序用于实体和数据库管理。它有一个只能查看的用户和一个管理员角色。这个应用程序中有许多易受攻击的模块。我试图从只有视图的用户会话中执行所有 CRUD 操作。引起我注意的操作是 DELETE。该应用程序实现了一个2步删除过程:

First, it sent a request to delete the endpoint, which redirected to confirm the delete endpoint, and the response also had some cookies.

首先,它发送了一个删除端点的请求,该端点被重定向以确认删除端点,响应也有一些 cookie。

Next, using these cookies, the application sent a request to confirm the delete endpoint and the entity deleted. There was no entity id present in the request. So, it was using the cookies assigned in step 1 identify the entity to be deleted.

接下来,使用这些 cookie,应用程序发送请求确认删除端点并删除实体。请求中没有实体 id。因此,它使用了步骤1中分配的 cookie 来标识要删除的实体。

Using the cookies of the View-only user, I first sent a request to the delete endpoint with the entity id to delete, copied the cookies obtained in the response, and sent a request to confirm the delete endpoint. By understanding the flow of requests in the application, I was able to break the access control imposed.

使用仅视图用户的 cookie,我首先向要删除的实体 id 的删除端点发送请求,复制在响应中获得的 cookie,然后发送请求确认删除端点。通过理解应用程序中的请求流,我能够打破强加的访问控制。

Key Takeaways

关键的外卖

For Security Researchers:

安全研究人员:

  • Dig deeper into the application and understand the flow of requests.

    深入挖掘应用程序并理解请求流。

  • Observe the requests closely and try to understand the significance of each parameter in the request.

    仔细观察请求,并尝试理解请求中每个参数的重要性。

  • If you are given more than 2 roles, don’t always focus on the least and the highest privileged roles. There can also be flaws in the access control roles with the mid-privileged roles.

    如果你被分配了两个以上的角色,不要总是关注最小和最高特权的角色。使用中间特权角色的访问控制角色也可能存在缺陷。

  • Try to understand the application, use all the functionalities, and then focus on finding flaws in one functionality at a time. Dig as much as deep you can.

    尝试理解应用程序,使用所有的功能,然后一次专注于发现一个功能中的缺陷。挖得越深越好。

  • Reading the documentation of the application helps a lot in understanding the core logic and permission to various roles assisting you in discovering broken access control issues.

    阅读应用程序的文档有助于理解各种角色的核心逻辑和权限,从而帮助您发现无效的访问控制问题。

For Developers:

对于开发者:

  • Whenever you are developing the application don’t impose access controls from the frontend only.

    无论何时开发应用程序,都不要只从前端强加访问控制。

  • Impose Access control checks on the API endpoints too.

    对 API 端点也进行访问控制检查。

  • Always keep in mind to have server-side checks for the access control before committing the operation.

    请始终记住,在提交操作之前要对访问控制进行服务器端检查。

  • Use GUIDs for referencing the objects.

    使用 guid 来引用对象。

Once Sir Albert Einstein truly said :

阿尔伯特 · 爱因斯坦爵士曾经真诚地说过:

“If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask for once I know the proper question, I could solve the problem in less than five minutes.”

“如果我有一个小时的时间来解决一个问题,而我的生活取决于这个解决方案,我会用前55分钟确定一个合适的问题,一旦我知道了合适的问题,我就能在不到5分钟的时间里解决这个问题。”

Questioning properly helps you analyze how the application behaves and come out with various unique test cases. There are misconfigurations at many places. Many times the access control is imposed only on frontend, so checking the APIs or POST request can reveal the issues.

正确的提问可以帮助您分析应用程序的行为,并得出各种独特的测试用例。在许多地方都存在错误的配置。很多时候,访问控制只施加在前端,因此检查 api 或 POST 请求可以揭示问题。