如何绕过 403 Forbidden：请求头、方法、路径

引言

如果绕过 403 错误能够揭示出隐藏的漏洞呢？本文探讨用于绕过这类错误并暴露潜在安全缺陷的高级技术。我们将深入介绍一些方法，例如对请求头进行模糊测试（这能揭示服务器配置错误）、更改 HTTP 方法以测试不同的请求类型、操纵请求参数以绕过限制、利用 Wayback Machine 查找此前可访问的文件，等等。这些技术能够为渗透测试和安全评估提供关键洞见。

用于绕过 403 错误的技术

要达成这一目标，可以使用许多技术。其中包括更改 host 请求头以测试配置错误、构造不同的 user agent 请求以发现其他访问入口、调整请求参数以寻找漏洞、生成经过模糊测试的请求路径以绕过访问控制，以及利用 Wayback Machine 发现此前可访问的内容。这些方法以及更多手段，在智胜 403 错误、揭示隐藏的安全缺陷方面都起着至关重要的作用。

更改 Host 请求头

操纵 HTTP 请求头往往能揭示漏洞或绕过限制。

原始请求/响应：

GET /admin HTTP/1.1  
Host: redacted.com

HTTP/1.1 403 Forbidden  
Access Denied

修改后的请求/响应（绕过）：

GET /admin HTTP/1.1  
Host: google.com

HTTP/1.1 200 Ok  
Admin Panel Login Page(Source Code)

移除 Host 请求头

去掉 host 请求头，以测试在未指定 host 时服务器的响应，这有时会触发默认行为或暴露配置错误。

原始请求/响应：

GET /reach%2fsip.svc HTTP/1.1
Host: lyncdiscover.microsoft.com
User-Agent: curl/7.79.1
Accept: */*
Connection: close


HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Content-Type: text/html
X-MS-Correlation-Id: fd2fe958-0683-4bb6-8ac6-36637ce86b81
X-Content-Type-Options: nosniff
Date: Thu, 08 Sep 2022 07:25:58 GMT
Connection: close
Content-Length: 1233

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
            <title> 
                403 - Forbidden: Access is denied. 
            </title>
            <style type="text/css">
...

修改后的请求/响应（绕过）：

GET /reach%2fsip.svc HTTP/1.0
<deleted_host_header>


HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=UTF-8
X-MS-Correlation-Id: c989aa79-e7d7-4855-9937-67a51a548435
x-ms-client-request-id: c30a03fa-dce8-4a8c-b34f-c5f6a11d47d0
X-Content-Type-Options: nosniff
Date: Thu, 08 Sep 2022 07:45:40 GMT
Connection: close
Content-Length: 3058

构造不同的 User Agent 请求

使用各种针对特定 user agent 的方式来改变请求特征，从而绕过针对特定 user agent 的拦截。

• 例如，使用来自不同浏览器或设备的 user agent 可能会得到不同的响应。
• 可以在此链接中找到一份详尽的 User-Agent 列表。

构造不同的代理请求头请求

添加代理请求头，查看服务器行为是否会根据其感知到的客户端 IP 而发生变化。

• 例如，使用如下请求头：

X-Originating-IP,
X-Forwarded-For,
X-Forwarded,
Forwarded-For,
X-Remote-IP,
X-Remote-Addr,
X-ProxyUser-Ip,
X-Original-URL,
Client-IP,
True-Client-IP,
Cluster-Client-IP

• 配以如下取值：

10.0.0.0 
10.0.0.1
127.0.0.1
127.0.0.1:443
127.0.0.1:80
172.16.0.0
localhost

添加端口请求头

将端口号附加到 X-Forwarded-Port 请求头，以测试服务器是否有针对特定端口的规则。 - 示例： - X-Forwarded-Port: 443 - X-Forwarded-Port: 80

添加协议（Schema）请求头

加入针对特定协议的请求头来修改请求，例如表明该请求是 HTTP 还是 HTTPS。 - 示例： - X-Forwarded-Proto: http - X-Forwarded-Proto: https

更改 HTTP 方法

在 GET、POST、PUT、DELETE 等方法之间切换，查看不同方法是否被不一致地处理。

更改 HTTP 方法的大小写

测试诸如 GET 与 get 之类的变体，查看服务器是否区分大小写。 - 例如，使用 get /admin HTTP/1.1。

使用请求头更改 HTTP 方法

使用诸如 X-HTTP-Method-Override 之类的请求头来绕过方法限制。 - 例如，在一个 POST 请求中设置 X-HTTP-Method-Override: PUT。 - 其他方法： - X-Original-Method - X-Method-Override

构造修改参数后的请求

修改请求中已有的参数，以测试不同的输入场景。

原始请求/响应：

POST /api/admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

id=9999&access=restricted

HTTP/1.1 403 Forbidden 
Content-Type: application/json 

{ 
    "error": "Access denied" 
}

修改后的请求/响应（绕过）：

POST /api/admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

id=1&access=granted

HTTP/1.1 200 OK
Content-Type: application/json

{
    "message": "Access granted",
    "data": {
        "id": 1,
        "role": "admin"
    }
}

注意事项：

如果服务器的响应取决于上下文，或修改后的参数未被按预期处理，这项技术可能会产生误报。请确保您所做的更改与正在测试的具体访问控制或条件相关。由于非标准的服务器行为而错误解读响应，可能导致对漏洞是否存在得出错误结论。

递增参数值

逐步增大参数值，以测试差一（off-by-one）错误或边界条件。 - 例如，id=1、id=2、id=3，依此类推。

注意事项：

通过递增参数来测试边界条件可能导致误报，尤其是当应用以非标准方式处理参数或具有大量校验逻辑时。请确保结合预期行为来分析结果，并考虑使用一系列取值进行测试，以准确识别潜在问题。由于应用的设计或数据约束而错误解读响应，可能导致误导性的结论。

添加参数

向请求中引入额外的参数，查看服务器是否会错误地处理它们。

• 例如，添加 isAdmin=true。
• 其他示例：

- ("isAdmin", "true")
- ("order", "desc")
- ("sort_by", "date")
- ("limit", "100")
- ("debug", "true")
- ("admin", "true")
- ("verbose", "true")
- ("user_id", "10")
- ("mode", "admin")
- ("user", "admin")
- ("role", "admin")

删除参数

移除参数，以测试默认行为，或测试是否强制要求必填参数。例如，从请求中删除令牌。

反转参数顺序

如果服务器以特定顺序处理参数或具有依赖顺序的逻辑，更改请求中参数的顺序有时有助于绕过 403 Forbidden 错误。例如，如果服务器为进行访问控制或校验而按某种固定顺序检查参数，那么反转参数顺序可能会诱使它授予访问权限。当服务器后端逻辑假定参数采用固定顺序时，这项技术尤为有用，而改变这一顺序可能揭示出隐藏的漏洞。

例如，将 id=1&name=John 改为 name=John&id=1。

添加边界情形参数

添加边界情形参数有助于通过挑战服务器输入处理的极限来识别漏洞。极大的取值、特殊字符或意料之外的输入格式，可能会触发非预期行为或暴露弱点。这项技术可用于测试服务器是否正确校验或清理输入，以及它是否容易受到可能导致绕过安全限制（包括 403 错误）的边界情形影响。

例如，id=0 或 name=-99999999999999999999999999999。

对参数进行 SQL 注入

尝试 SQL 注入攻击以测试漏洞。

原始请求/响应：

修改后的请求/响应（绕过）：

空参数

使用空的参数值，查看服务器如何处理缺失的数据。

• 例如，id=。

反转取值

反转参数取值是指互换参数的值，以测试服务器是否会根据其内容而对它们进行不同的处理。这项技术可用于揭示数据处理方式中的漏洞或不一致之处。

工作原理

有些应用可能以特定方式处理参数值，或要求它们符合特定格式。通过反转或改变这些值，您可以测试应用的输入校验或处理机制是否足够健壮。

示例

• 数值：将 "1" 改为 "0"，或将 "0" 改为 "1"。
• 布尔值：将 "true" 改为 "false"，将 "false" 改为 "true"。
• 字符串值：将 "yes" 改为 "no"，将 "no" 改为 "yes"；或将 "Yes" 改为 "No"，将 "No" 改为 "Yes"。

参数污染

参数污染指的是向 HTTP 请求中引入重复或冲突的参数，以扰乱或操纵服务器处理输入的方式这一技术。它会使服务器产生混淆，从而可能导致非预期行为或暴露漏洞。

其工作原理如下：

1. 重复参数：通过多次包含同一参数并赋予不同的值（例如 id=1&id=2），您可以测试服务器如何处理此类输入。服务器可能以多种方式处理这些重复项：
   • 首次出现：有些服务器可能只考虑该参数的第一个实例，忽略后续实例。
   • 末次出现：另一些服务器可能使用最后提供的值，丢弃先前的值。
   • 合并：在某些情况下，服务器可能会尝试合并重复参数，这可能导致意料之外的结果。
2. 冲突处理：服务器处理冲突参数的方式可能各不相同。例如，如果一个请求包含 sort=asc&sort=desc，服务器解决这一冲突的方式可能会揭示出不一致之处或弱点。
3. 绕过限制：参数污染有时能绕过安全限制或校验检查。例如，服务器可能对某个参数设有严格的校验规则，而一旦引入该参数的多个实例，这些规则就会被绕过。

更改路径大小写

修改路径中字符的大小写，以测试大小写敏感性。 - 例如，将 /admin 改为 /Admin。

在路径后追加扩展名

在路径后添加扩展名，查看不同的文件类型是否被区别对待。 - 例如，将 /admin 改为 /admin.php。

路径变体

尝试不同的路径编码和变体： - /path（被拦截）→ /%2e/path、/%252e/path。 - Unicode 绕过：/%ef%bc%8fpath。 - 大小写变体和结尾斜杠：/secret、/SECRET、/secret/、/secret/.、//secret//、/./secret/.。 - 额外字符：;/secret、/.;/secret、//;//secret。

原始请求/响应：

修改后的请求/响应（绕过）：

更改 API 版本

在不同的 API 版本之间切换，以测试针对特定版本的漏洞。 - 例如，将 /v1/users 改为 /v2/users。

对首字母进行 URL 编码

对路径的首个字符进行 URL 编码，以测试对编码字符的不当处理。 - 例如，将 /admin 改为 /%61dmin。

查询 Wayback Machine

在安全评估中，使用 Wayback Machine 可以是一种有策略的做法，用以揭示那些此前可访问、如今已受限的资源。通过查询某个目标 URL 的历史快照，您可以了解某个页面或端点在不同时间点上的样貌。这在以下方面尤其有用：

1. 识别以往的 URL：历史记录可能揭示那些以前可公开访问、现在却已受限或被移除的 URL 或资源路径。这有助于发现可能仍然存在漏洞的已弃用端点。
2. 揭示隐藏的资源：目录、文件或 API 等资源在站点的早期版本中曾被暴露，如今可能已被隐藏。Wayback Machine 有助于识别这些资源，从而可以进一步测试它们在特定条件下是否仍然可访问。
3. 分析内容变化：审查页面的过往版本可以凸显访问控制或应用逻辑方面的变化。这能帮助您了解应用的安全态势是如何演变的，以及是否引入了新的漏洞。

例如，如果某个现在返回 403 Forbidden 错误的页面在早期快照中曾可访问，Wayback Machine 就能展示它以往的结构和内容。这种历史背景可以揭示出在当前版本中已不再明显的潜在访问路径或漏洞。

更改协议版本

在测试不同的 HTTP 协议版本（例如 HTTP/1.1、HTTP/1.0、HTTP/2.0 和 HTTP/3.0）时，需要注意的是，并非所有服务器和技术栈都支持每一个版本。有些服务器对较新协议的支持可能有限或不一致，这会影响请求的处理方式。例如，服务器处理 HTTP/2.0 请求的方式可能与 HTTP/1.1 不同，或者根本不支持 HTTP/3.0。这种不一致有时会导致非预期行为，从而可能让某些请求绕过限制，或揭示出在使用默认协议版本时不会显现的漏洞。因此，跨不同版本进行测试可能很有用，但要留意技术栈支持方面的限制，这些限制可能影响结果。

示例：将 HTTP/1.1 改为 HTTP/1.0

原始请求/响应：

修改后的请求/响应（绕过）：

结论

通过采用诸如对请求头进行模糊测试、尝试不同的 HTTP 方法、修改请求参数以及改变请求路径等技术，我们能够揭示隐藏在 403 错误背后的潜在漏洞。此外，到 Wayback Machine 查询已归档的内容并测试不同的 HTTP 协议版本，也能揭示出被忽视的安全缺陷。这些方法共同有助于绕过 403 错误，并识别 Web 应用中的关键弱点。