4.2.6-测试 HTTP 方法

测试 HTTP 方法

ID
WSTG-CONF-06

总结
HTTP 提供了许多可用于在 Web 服务器上执行操作的方法（或动词）。虽然GET和POST是迄今为止用于访问Web服务器提供的信息的最常见方法，但也可以支持各种其他方法，有时可能会被攻击者利用。

RFC 7231 定义了主要的有效 HTTP 请求方法（或动词），尽管在其他 RFC 中添加了其他方法，例如 RFC 5789。其中一些动词已在 RESTful 应用程序中重新用于不同的目的，如下表所示。

[RFC 7231]定义了主要的有效 HTTP 请求方法（或动词），尽管在其他 RFC 中添加了其他方法，例如 RFC 5789. 其中一些动词已在 RESTful 应用程序中重新用于不同的目的，如下表所示。

方法	最初目标	最终目的
GET	请求文件。	请求对象。.
HEAD	请求文件，但仅返回 HTTP 标头。
POST	提交数据。
PUT	上传文件。	创建一个对象。
DELETE	删除文件	删除对象
CONNECT	建立与另一个系统的连接。
OPTIONS	列出支持的 HTTP 方法。	执行 CORS Preflight 前检查请求。
TRACE	出于调试目的回显 HTTP 请求。
PATCH		修改对象。

测试目标

• 枚举支持的 HTTP 方法。
• 测试访问控制绕过。
• 测试 HTTP 方法覆盖技术。

如何测试

了解支持的方法

要执行此测试，测试人员需要一种方法来识别正在检查的 Web 服务器支持哪些 HTTP 方法。最简单的方法是向服务器发出OPTIONS 请求：

OPTIONS / HTTP/1.1
Host: example.org

然后，服务器应使用支持的方法列表进行响应：

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST

但是，并非所有服务器都可以响应 OPTIONS 请求，有些服务器甚至可能返回不准确的信息。还值得注意的是，服务器可能支持不同路径的不同方法。这意味着即使根/目录不支持某个方法，也不一定表示其他地方不支持相同的方法。

测试受支持方法的更可靠方法是简单地使用该方法类型发出请求，并检查服务器响应。如果不允许使用该方法，则服务器应返回 405 Method Not Allowed 状态。

请注意，某些服务器将未知方法视为等效于 GET ，因此它们可能会响应任意方法，例如如下所示的请求。这有时可用于逃避 Web 应用程序防火墙或阻止特定方法的任何其他筛选。

FOO / HTTP/1.1
Host: example.org

使用任意方法的请求也可以使用 curl 和 -X 选项发出：

curl -X FOO https://example.org

还有各种自动化工具可以尝试确定支持的方法，例如 http-methodsNmap脚本。但是，这些工具可能不会测试危险方法（即可能导致更改的方法，例如 PUT 或 DELETE ），或者如果支持这些方法，则可能会无意中导致对 Web 服务器的更改。因此，应小心使用它们。

放置和删除

PUT and DELETE 方法可以有不同的效果，具体取决于它们是由 Web 服务器解释的还是由在其上运行的应用程序解释的。

旧版 Web 服务器

一些旧版 Web 服务器允许使用PUT 该方法在服务器上创建文件。例如，如果服务器配置为允许这样做，则下面的请求将在服务器上创建一个test.html 文件，该文件调用的内容为 <script>alert(1)</script>. 。

PUT /test.html HTTP/1.1
Host: example.org
Content-Length: 25

<script>alert(1)</script>

也可以使用 cURL 发出类似的请求：

curl https://example.org --upload-file test.html

这允许攻击者将任意文件上传到 Web 服务器，如果允许他们上传可执行代码（如 PHP 文件），则可能导致整个系统受损。但是，这种配置极为罕见，在现代系统上不太可能看到。

同样，该 DELETE 方法可用于从 Web 服务器中删除文件。请注意，这是一种破坏性行为;因此，在测试此方法时应格外小心。

DELETE /test.html HTTP/1.1
Host: example.org

或者使用 cURL：

curl http://example.org/test.html -X DELETE

RESTful APIs

相比之下，现代 RESTful 应用程序通常使用 PUT 和DELETE 方法来创建和删除对象。例如，下面的 API 请求可用于创建名为“foo”的用户，其角色为“user”：

PUT /api/users/foo HTTP/1.1
Host: example.org
Content-Length: 34

{
    "role": "user"
}

使用 DELETE 方法的类似请求可用于删除对象。

DELETE /api/users/foo HTTP/1.1
Host: example.org

尽管自动扫描工具可能会报告这些方法，但 RESTful API 上存在这些方法并不是**安全问题 **。但是，此功能可能存在其他漏洞（如弱访问控制），应进行全面测试。

跟踪

TRACE 方法（或Microsoft的等效TRACK 方法）使服务器回显请求的内容。这导致了一个名为跨站点跟踪（XST）的漏洞在2003 (PDF)年发布（PDF），该漏洞可用于访问设置了 HttpOnly标志的cookie。 TRACE方法已在所有浏览器和插件中被阻止多年;因此，此问题不再可利用。但是，它仍可能被自动扫描工具标记，并且在 Web 服务器上启用的 TRACE 方法表明尚未正确强化。

连接

CONNECT 方法使 Web 服务器打开与另一个系统的 TCP 连接，然后将流量从客户端传递到该系统。这可能允许攻击者通过服务器代理流量，以隐藏其源地址，访问内部系统或访问绑定到localhost的服务。CONNECT请求示例如下所示：

CONNECT 192.168.0.1:443 HTTP/1.1
Host: example.org

补丁

PATCH 方法在 RFC 5789 中定义，用于提供有关如何修改对象的指令。RFC 本身没有定义这些指令应该采用什么格式，但在其他标准中定义了各种方法，例如 RFC 6902 - 对象表示法 （JSON） 补丁.

例如，如果我们有一个名为“foo”的用户，具有以下属性：

{
    "role": "user",
    "email": "foo@example.org"
}

以下 JSON PATCH 请求可用于将此用户的角色更改为“admin”，而无需修改电子邮件地址：

PATCH /api/users/foo HTTP/1.1
Host: example.org

{ "op": "replace", "path": "/role", "value": "admin" }

尽管 RFC 声明它应该包括有关如何修改对象的说明，但 PATCH 方法通常（错误地）用于包含更改的内容，如下所示。与上一个请求非常相似，这会在不修改对象的其余部分的情况下将“role”值更改为“admin”。这与 PUT方法相反，该方法将覆盖整个对象，从而导致对象没有“电子邮件”属性。

PATCH /api/users/foo HTTP/1.1
Host: example.org

{
    "role": "admin"
}

与 PUT方法一样，此功能可能存在访问控制弱点或其他漏洞。此外，应用程序在修改对象时可能不会执行与创建对象时相同级别的输入验证。这可能允许注入恶意值（例如在存储的跨站点脚本攻击中），或者可能允许可能导致业务逻辑相关问题的损坏或无效对象。

访问控制绕过测试

如果应用程序上的某个页面在用户尝试直接访问时将用户重定向到带有 302 代码的登录页面，则可以通过使用不同的 HTTP 方法，例如 HEAD, POST 甚至编造的方法FOO发出请求来绕过它。如果Web应用程序响应的是 HTTP/1.1 200 OK 而不是预期的 HTTP/1.1 302 Found，则可以绕过身份验证或授权。以下示例显示了HEAD请求如何导致页面设置管理 Cookie，而不是将用户重定向到登录页面：

HEAD /admin/ HTTP/1.1
Host: example.org

HTTP/1.1 200 OK
[...]
Set-Cookie: adminSessionCookie=[...];

或者，也可以直接向导致操作的页面发出请求，例如：

HEAD /admin/createUser.php?username=foo&password=bar&role=admin HTTP/1.1
Host: example.org

或:

FOO /admin/createUser.php
Host: example.org
Content-Length: 36

username=foo&password=bar&role=admin

测试 HTTP 方法覆盖

某些 Web 框架提供了一种覆盖请求中实际 HTTP 方法的方法。它们通过模拟缺少的 HTTP 谓词并在请求中传递一些自定义标头来实现此目的。这样做的主要目的是绕过阻止特定方法的中间件应用程序（例如代理或 Web 应用程序防火墙）。可能会使用以下替代 HTTP 标头：

• X-HTTP-Method
• X-HTTP-Method-Override
• X-Method-Override

若要对此进行测试，请考虑受限制谓词喜欢 PUT 或 DELETE返回 405 Method not allowed.在这种情况下，请重播相同的请求，但添加用于 HTTP 方法覆盖的备用标头。然后，观察系统的响应。在支持方法覆盖的情况下，应用程序应使用不同的状态代码（例如200 OK）进行响应。

以下示例中的 Web 服务器不允许 DELETE方法并阻止它：

DELETE /resource.html HTTP/1.1
Host: example.org

HTTP/1.1 405 Method Not Allowed
[...]

添加 X-HTTP-Method 标头后，服务器使用 200 响应请求：

GET /resource.html HTTP/1.1
Host: example.org
X-HTTP-Method: DELETE

HTTP/1.1 200 OK
[...]

修复

• 确保仅允许所需的方法，并且正确配置了这些方法。
• 确保未实施任何变通方法来绕过用户代理、框架或 Web 服务器实施的安全措施。

工具

• Ncat
• cURL
• Nmap http-methods NSE script

引用

• RFC 7231 - 超文本传输协议 （HTTP/1.1）
• RFC 5789 - HTTP 的补丁方法
• HTACCESS: BILBAO 方法暴露
• 强化 - 误用的 HTTP 方法覆盖
• Mozilla 开发者网络 - 安全的 HTTP 方法s