Question

Our credit card processing example could also be classified as a broken access control issue. Broken access control occurs when access control in an application is improperly implemented and can be bypassed by an attacker. For example, the IDOR vulnerabilities discussed in Chapter 10 are a common broken access control issue that applications face.

“我们的信用卡处理示例也可以被归类为破损的访问控制问题。破损的访问控制指的是当应用程序的访问控制不正确地实施时，攻击者可以绕过。例如，第 10 章讨论的 IDOR 漏洞是应用程序面临的常见破损的访问控制问题。”

But there are many other broken access control issues common in web applications that you should learn about if you hope to become an effective hacker. Let’s look at a few of them.

然而，许多其他的 Web 应用程序也存在许多常见的访问控制问题，如果你希望成为一个有效的黑客，你必须学习它们。让我们看一些例子。

Exposed Admin Panels

Applications sometimes neglect or forget to lock up sensitive functionalities such as the admin panels used to monitor the application. Developers may mistakenly assume that users can’t access these functionalities because they aren’t linked from the main application, or because they’re hidden behind an obscure URL or port. But attackers can often access these admin panels without authentication, if they can locate them. For example, even if the application example.com hides its admin panel behind an obscure URL such as https://example.com/YWRtaW4/admin.php , an attacker might still be able to find it via Google dorks or URL brute-forcing.

应用程序有时会忽略或忘记锁定敏感功能，比如用于监控应用程序的管理面板。开发人员可能错误地认为用户无法访问这些功能，因为它们没有链接到主应用程序，或者因为它们隐藏在一个晦涩的 URL 或端口后面。但是，攻击者通常可以在不进行身份验证的情况下访问这些管理面板，如果他们能够找到它们的话。例如，即使应用程序 example.com 将其管理面板隐藏在一个晦涩的 URL https://example.com/YWRtaW4/admin.php 后面，攻击者仍然可能通过 Google dorks 或 URL 等方式找到它。

Sometimes applications don’t implement the same access control mechanisms for each of the various ways of accessing their sensitive functionalities. Say the admin panel is properly secured so that only those with valid admin credentials can access it. But if the request is coming from an internal IP address that the machine trusts, the admin panel won’t ask the user to authenticate. In this case, if an attacker can find an SSRF vulnerability that allows them to send internal requests, they can access the admin panel without authentication.

有时，应用程序在访问其敏感功能的各种方式上可能没有实现相同的访问控制机制。比如说，管理员面板被适当地保护，只有持有有效管理员凭证的人才能访问。但是，如果请求来自机器信任的内部 IP 地址，管理员面板就不会要求用户进行身份验证。在这种情况下，如果攻击者能够找到 SSRF 漏洞并发送内部请求，他们就能够在不进行身份验证的情况下访问管理员面板。

Attackers might also be able to bypass access control by tampering with cookies or request headers if they’re predictable. Let’s say the admin panel doesn’t ask for credentials as long as the user requesting access presents the cookie admin=1 in their HTTP request. All the attacker has to do to bypass this control is to add the cookie admin=1 to their requests.

攻击者如果能够预测，也可以通过篡改 cookie 或者请求头来绕过访问控制。比如，假设管理员面板只要求用户在 HTTP 请求中携带名为 admin=1 的 cookie，就可以直接访问，而无需验证凭据。攻击者只需将 cookie admin=1 添加到其请求中，就能够绕过此控制。

Finally, another common access control issue occurs when users can force their browsing past the access control points. To understand what this means, let’s say the usual way of accessing example.com ’s admin panel is via the URL https://example.com/YWRtaW4/admin.php . If you browse to that URL, you’ll be prompted to log in with your credentials. After that, you’ll be redirected to https://example.com/YWRtaW4/dashboard.php , which is where the admin panel resides. Users might be able to browse to https://example.com/YWRtaW4/dashboard.php and directly access the admin panel, without providing credentials, if the application doesn’t implement access control at the dashboard page.

最后，另一个常见的访问控制问题是用户可以强制浏览器绕过访问控制点。为了理解这意味着什么，假设访问 example.com 的管理员面板的通常方法是通过 URL https://example.com/YWRtaW4/admin.php。如果您浏览到该 URL，您将被提示使用凭据登录。之后，您将被重定向到 https://example.com/YWRtaW4/dashboard.php，其中管理员面板位于该处。如果应用程序不在仪表板页面实施访问控制，则用户可能能够浏览到 https://example.com/YWRtaW4/dashboard.php 并直接访问管理员面板，而无需提供凭据。

Directory Traversal Vulnerabilities

Directory traversal vulnerabilities are another type of broken access control. They happen when attackers can view, modify, or execute files they shouldn’t have access to by manipulating filepaths in user-input fields.

目录遍历漏洞是另一种破损的访问控制类型。攻击者可以通过操纵用户输入字段中的文件路径来查看、修改或执行他们本不应该访问的文件。

Let’s say example.com has a functionality that lets users access their uploaded files. Browsing to the URL http://example.com/uploads?file=example.jpeg will cause the application to display the file named example.jpeg in the user’s uploads folder located at /var/www/html/uploads/USERNAME/ .

假设 Example.com 有一项功能，让用户可以访问他们上传的文件。浏览 URL http://example.com/uploads?file=example.jpeg 将导致应用程序在用户的上传文件夹中显示名为 example.jpeg 的文件，该文件夹位于 /var/www/html/uploads/ USERNAME/路径下。

If the application doesn’t implement input sanitization on the file parameter, a malicious user could use the sequence ../ to escape out of the uploads folder and read arbitrary files on the system. The ../ sequence refers to the parent directory of the current directory on Unix systems. For instance, an attacker could use this request to access the /etc/shadow file on the system:

如果应用程序没有对文件参数执行输入清理，则恶意用户可以使用序列../来逃脱上传文件夹并在系统上读取任意文件。../序列指 Unix 系统上当前目录的父目录。例如，攻击者可以使用此请求访问系统上的/etc/shadow 文件。

http://example.com/upload?file=../../../../../etc/shadow

The page would navigate to /var/www/html/uploads/USERNAME/../../../../../etc/shadow , which points to the /etc/shadow file at the system root! In Linux systems, the /etc/shadow file contains the hashed passwords of system users. If the user running the web server has the permissions to view this file, the attacker could now view it too. They could then crack the passwords found in this file to gain access to privileged users’ accounts on the system. Attackers might also gain access to sensitive files like configuration files, log files, and source code.

该页面将导航到/var/www/html/uploads/USERNAME/../../../../../etc/shadow，该文件指向系统根路径下的/etc/shadow 文件！在 Linux 系统中，/etc/shadow 文件包含系统用户的哈希密码。如果运行 Web 服务器的用户具有查看此文件的权限，则攻击者也可以查看该文件。然后，他们可以破解在该文件中找到的密码以访问系统上的特权用户帐户。攻击者还可能获得访问敏感文件（如配置文件、日志文件和源代码）的权限。