WEB 网络请求初探

网络请求

超文本传输协议 (HTTP)

        HTTP 是一种应用层协议，用于通过万维网访问资源。超文本一词代表包含指向其他资源的链接的文本以及读者可以轻松解释的文本。

        HTTP 通信由客户端和服务器组成，客户端向服务器请求资源。服务器处理请求并返回请求的资源。 HTTP 通信的默认端口是 80；但是，这可以更改。这些是我们在使用 Internet 访问不同网站时所知道的对 Web 服务器的请求。我们输入完全限定域名 (FQDN) 作为统一资源定位符 (URL) 以访问所需的网站，例如 www.hackthebox.eu。

        URL 为我们提供了更多的可能性，而不仅仅是指定我们要访问的网站。 HTTP 上的资源是通过 URL 访问的。让我们看一下 URL 的结构。

 以下是每个组件的含义：

         并非总是需要所有组件来访问资源。然而，一个 URL 至少应该包含一个方案和主机来发出正确的请求。

        上图以非常高的层次展示了 HTTP 请求的剖析。用户第一次在浏览器中输入 URL (inlanefreight.com) 时，它会请求 DNS（域名解析）服务器来解析域。 DNS 服务器查找 inlanefreight.com 的 IP 地址并将其返回。所有域名都需要以这种方式解析，因为如果没有 IP 地址，服务器就无法通信。

        接下来，浏览器向默认的 HTTP 端口（即 80）发送 GET 请求，请求根 / 文件夹。这里 GET 是请求方法。请求的类型可能会有所不同，我们稍后会看到。 Web 服务器接收请求并处理它。默认情况下，服务器配置为在收到 / 请求时返回索引文件。在这种情况下，webserver 读取 index.html 的内容并将其作为 HTTP 响应返回。响应还包含状态码 200 OK 等信息，表示请求已成功处理。

        index.html 内容随后由 Web 浏览器呈现并呈现给用户。 HTML（超文本标记语言）是一种客户端语言，可以被浏览器理解和处理。它是通过网络浏览器显示文档的标准标记语言。 HTML 页面由级联样式表 (CSS) 辅助，它允许灵活地将布局、颜色和字体等表示元素应用到一个或多个网页，以及支持交互式网页的 JavaScript 等脚本语言。

安全超文本传输​​协议 (HTTPS)

HTTPS 概述：

        HTTP 的主要缺点之一是所有数据都以明文形式传输，这意味着源和目标之间的任何人都可以执行中间人 (MiTM) 攻击来查看传输的数据。这是包含敏感用户数据的银行和政府网站的主要问题。

        这可以通过使用网络分析器（例如 Wireshark）来检查。以下示例演示了在 Web 浏览器和 Web 应用程序之间不强制执行安全通信的效果。如果我们在使用图形数据包网络协议分析器（如 Wireshark）监控网络流量的同时尝试登录不安全的网站，我们可以看到登录凭据可以明文形式被截获。这将使同一网络（例如公共无线网络）上的某人很容易捕获它们并将它们用于恶意目的。

         如下所示，捕获网络流量的攻击者将能够查看整个登录序列，显示登录请求（以及提供的用户名和密码）以及在成功登录尝试后重定向到管理仪表板页面。

 

        这些缺点催生了 HTTPS（HTTP 安全）协议。启用此协议后，客户端（通过 Web 浏览器访问 Web 应用程序的用户）与托管 Web 应用程序的 Web 服务器之间的所有通信都将被加密。在 Web 应用程序上实施 HTTPS 后，任何人都无法拦截和分析流量并捕获凭据和其他敏感数据等信息。

        可以通过 URL 中的 https://（即 https://www.google.com）以及 Web 浏览器地址栏中位于 URL 左侧的锁定图标来识别强制执行 HTTPS 的网站。

        HTTPS 的默认端口是 443，浏览器优先于 HTTP 端口 80，前提是不存在允许用户浏览网站的不安全 HTTP 版本而不是 HTTPS 版本的错误配置。在浏览 https://google.com 时运行 Wireshark 会显示通过网络的流量已加密。 

        在上面的示例中，我们可以看到浏览到 https://google.com 时的所有流量都是加密的。 

HTTPS Flow（流）:

 

        让我们看看 HTTPS 在高层次上是如何运作的。浏览到 http://inlanefreight.com 后，浏览器会尝试解析域并将用户重定向到托管目标网站的网络服务器。首先向端口 80 发送请求，该端口是未加密的 HTTP 协议。服务器检测到这一点并将客户端重定向到安全的 HTTPS 端口 443。这是通过 301 Moved Permanently 响应代码完成的。

        接下来，客户端（Web 浏览器）发送一个“client hello”数据包，提供有关自身的信息。此后，服务器回复“server hello”，然后进行密钥交换。客户端验证这个密钥并发送它自己的一个。此后，将启动加密握手以验证加密和传输是否正常工作。

        握手成功完成后，继续进行正常的 HTTP 通信，然后对其进行加密。

        根据具体情况，攻击者可能能够执行 HTTP 降级攻击，将 HTTPS 通信降级为 HTTP。这是通过设置中间人 (MITM) 攻击并在用户不知情的情况下通过攻击者的主机代理（传递）所有流量来完成的。成功的降级攻击将导致 HTTP 数据的明文传输，攻击者可以记录这些数据，然后出于恶意目的进行检查或操作。

 

标头：

        HTTP 标头提供了另一种在客户端和服务器之间传递信息的方法。有特定于请求和响应的标头以及两者共有的通用标头。标头可以在标头名称后附加一个或多个值，并用冒号分隔。有许多用于不同目的的标头，它们分为不同的类别：

1.通用标题

2.实体标头

3.请求标头

4.响应标头

5.安全标头

1. 通用标题：

        这些标头不专门属于请求或响应。它们是上下文相关的，用于描述消息而不是其内容。此链接提供有关一般标题的附加信息。

2.实体标头：

        与一般标头类似，实体标头可以为请求和响应所共有。这些标头用于描述消息正在传输的内容（实体）。它们通常出现在响应和 POST 或 PUT 请求中（例如，文件上传）。可以在此处找到有关实体标头的其他信息。

 

3.请求标头：

      客户端在 HTTP 事务中发送请求标头。它们在 RFC 2616 中定义。这些标头用于 HTTP 请求，与消息内容无关。 Accept、Accept-* 和 IF-* 等标头允许有条件的请求。发送诸如 Cookie 或 User-Agent 之类的标头，以便服务器可以定制响应。以下标头在 HTTP 请求中很常见。可以在此处找到请求标头及其用法的完整列表。

 

4.响应头：

        HTTP 响应标头可以在 HTTP 响应中使用，并且与消息的内容无关。某些响应标头（例如 Age、Location 和 Server）用于提供有关响应的更多上下文。以下标头常见于 HTTP 响应中。https://datatracker.ietf.org/doc/html/rfc7231#section-6包含有关响应标头的更多详细信息。

5. 安全标头：

随着浏览器和基于 Web 的攻击种类的增加，有必要定义某些增强安全性的标头。 HTTP 安全标头是一类响应标头，用于指定浏览器在访问网站时要遵循的某些规则和策略。

OWASP Secure Headers Project | OWASP Foundation可以进一步阅读各种 HTTP 安全标头可能性的绝佳资源。

        上面的部分涵盖了一小部分常见的 HTTP 标头。但是，在通信过程中可以使用更多的上下文标头。应用程序还可以根据其要求定义自定义标头。可以在此处https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers找到标准 HTTP 标头的完整列表。 

 HTTP 方法和代码：

注意：“PUT”和“DELETE”通常都与 WebDAV 服务器相关联

上面的列表仅突出显示了几种方法。特定方法的可用性取决于服务器以及应用程序配置

1.响应代码：

服务器使用 HTTP 状态码告诉客户端请求是否被成功处理。 HTTP 服务器可以返回五种类型的响应代码：

让我们看看一些常见的 HTTP 响应代码及其含义:

 

看到重定向的一个常见示例是在线购物期间，网站将您重定向到支付网关。 

 

 

上图描述了 Apache 返回的 403 Forbidden 错误。

 

 

 

该图显示了 IIS 在遇到服务器错误时返回的默认页面。除了标准的 HTTP 代码外，Cloudflare 或 AWS 等各种服务器和提供商也有自己的代码。

GET请求：

HTTP 方法 GET 是最常用的。其主要目的是请求给定资源并检索它。在查询参数的帮助下，可以通过 GET 请求发送数据。但是，这些数据应该是有限的，如果需要更多输入，应该使用 POST。

让我们看一些演示 GET 请求的基本示例。

        浏览到上述页面会提示我们进行身份验证。这种身份验证称为基本身份验证，其中服务器提示我们在访问资源之前提供凭据。在字段中输入随机值并单击“确定”应显示以下消息。

 

由于凭据不正确，服务器拒绝我们访问该页面。刷新页面并输入凭据以继续：

admin:password

这让我们进入仪表板，它允许搜索端口。让我们退后一步，分析一下请求过程。重新启动浏览器，以便丢弃经过身份验证的凭据。打开 Burp 拦截并在浏览器中输入 URL。

点击 [Ctrl + R] 将其发送到Repeater，以便我们查看响应。

在 Repeater 中转发请求以检查响应。我们看到服务器使用 WWW-Authenticate 标头响应 401 Unauthorized。此标头通知浏览器身份验证方案是基本的。返回代理选项卡，转发请求并在浏览器中输入正确的凭据。

这次我们在请求中看到了一个额外的 Authorization 标头。此标头包含身份验证类型，即 Basic 和 Base64 编码值。该值只不过是通过浏览器输入的凭据。突出显示字符串并按 [Ctrl + Shift +B] 对它进行 Base64 解码。

如我们所见，凭据在编码之前以用户名：密码的形式放入。这有助于服务器解析它并授权我们。单击转发以发送请求，之后我们应该被重定向到仪表板。

从前面的部分中，我们知道也可以通过 URL 指定凭据。让我们测试一下。重新启动浏览器并输入以下 URL。

他的浏览器通知我们它正在以管理员用户身份登录我们。单击“确定”应该会成功登录，而不会出现任何凭据提示。

还有几种授权类型是 Digest 和 Bearer。 Digest 类型用于使用 MD5 散列算法对凭证进行散列。与 Basic 相比，这可以防止凭据的明文传输。可以在https://datatracker.ietf.org/doc/html/rfc7616此处找到有关该过程的更多详细信息。

另一方面，Bearer 类型用于发送标识客户端的“令牌”。这些令牌可以由应用程序根据需要定义和创建。它们通常与 OAuth 授权框架相关联。

查询参数：

在管理仪表板上的搜索框中输入一些内容。

输入“a”后，查询参数“port_code”将附加到值为“a”的 URL。这意味着我们也可以直接将数据传递到页面，而无需将其输入到搜索框中。例如：

 

POST请求：

与 GET 方法不同，POST 将用户参数放在 HTTP 请求正文中。这有三个主要好处：

缺乏日志记录：这听起来可能违反直觉，因为日志记录通常被视为一件好事。但是，POST 请求可以处理文件上传和用户登录等任务。记录这些字段可能会导致本地磁盘被填满或密码以明文形式存储。当遇到通过 GET 请求接受登录的登录表单时，这应该始终是一个高风险，因为它可能会导致凭据存储在日志文件中。

更少的编码要求：URL 旨在共享，这意味着它们需要确认可以转换为字母的字符。 POST 请求将数据放在可以接受二进制数据的正文中。唯一需要编码的字符是那些用于分隔参数的字符。

更少的编码要求：URL 旨在共享，这意味着它们需要确认可以转换为字母的字可以发送更多数据：最大 URL 长度因浏览器 (Chrome/Firefox/IE)、Web 服务器 (IIS、Apache、nginx)、内容交付网络 (Fastly、Cloudfront、Cloudflare) 甚至 URL 缩短器 (bit.ly , amzn.to)。一般来说，URL 应保持在 2,000 个字符以下。符。 POST 请求将数据放在可以接受二进制数据的正文中。唯一需要编码的字符是那些用于分隔参数的字符。

检查请求：

让我们检查一个使用 POST 请求来处理登录的简单网页。我们将使用管理凭据 (admin:password) 登录，然后检查 Web 服务器如何跟踪我们的身份。下面是登录页面。

目标的凭据是访客/访客，因为需要检查 cookie 以升级到管理员用户。

我们可以使用 admin:password 或 guest:guest 登录应用程序。如果我们想退出网站，我们可以找到退出按钮或删除我们的 cookie，方法是单击锁定图标，然后单击清除 Cookie 和站点数据。建议使用网站的注销按钮，因为这会通知网络服务器您要注销。通过清除 cookie，您永远不会通知网络服务器您要退出，它也没有机会终止您的 cookie。如果您的 cookie 被拦截，拦截它们的人将可以访问您的帐户，直到它们过期（通常为 30 天）。

现在cookies被清除了，我们可以再次登录。这次我们将在登录前打开 Burp 以拦截登录凭据并查看请求。

我们看到一个对 /login.php 的 POST 请求。 Content-Type 标头设置为 application/x-www-form-urlencoded，它是 URL 编码表单数据的媒体类型。发现请求的正文包含两个参数，即用户名和密码，其值为 admin 和 password。

点击 [Ctrl + R] 将此请求发送到中继器，然后单击发送。

通过Repeater发送请求后，我们看到页面返回了302 Found响应码。我们还通过 Set-Cookie 标头看到了一个名为 PHPSESSID 的 cookie。 Location 标头表示我们被重定向到的页面。但是，使用不正确的密码发送请求会导致 200 OK 和 Login Failed 消息。

在这种情况下，由于名称 PHPSESSID，很明显 cookie 是一个“会话”，它只是一个唯一的字符串。一般来说，会话​​ ID 几乎总是散列，可以通过以下方式识别：

仅包含十六进制字符。 (a-f, 0-9)。

能被8整除。

应用程序的每个用户都有一个唯一的会话 ID，它映射到服务器上的文件或数据库条目，该条目存储有关您的登录信息。并非所有应用程序都使用会话。许多框架将允许用户保存有关其登录会话的信息。这最大限度地降低了网络服务器的处理能力，因为它不再需要跟踪数千个会话。

为了安全地做到这一点，网络服务器必须对请求进行加密签名，并向用户提供他们持有的数据的哈希值。由于用户不知道用于创建哈希的签名密钥，他们无法修改数据。但是，如果没有使用签名密钥，则用户可以修改 cookie 并可能诱骗服务器给予他们比预期更多的特权。当遇到您不认识的 cookie 时，尝试解码它们（base64/URL/等）并尝试修改它们的值总是很重要的。

让我们退后一步，看看失败的请求会发生什么。下面是显示 Burp Repeater 使用凭据 admin:test 登录的屏幕截图。

现在我们了解了登录成功和不成功时会发生什么。让我们验证服务器在篡改 Cookie 时是否将我们视为未经身份验证的用户。

导航回该页面并登录到 Web 应用程序。您可以在登录期间禁用 Burpsuite，也可以简单地在 burp 中转发请求。登录后，启用 Burp 并刷新页面以查看发送到服务器的请求。

我们看到请求连同 cookie 一起发送到 /admin/dashboard.php。我们知道cookies是用来识别客户的；如果我们删除 cookie 标头会怎样？点击 [Ctrl + R] 将其发送到中继器，然后删除 cookie 标头。

发现服务器将我们重定向回登录页面。这是因为它无法确认我们已经对服务进行了身份验证。点击 [Ctrl + Z] 撤消更改并保留 cookie 标头。

这次没有重定向，我们可以访问管理仪表板.

Content-Type:

Content-Type Header 是 POST 请求的关键部分。这告诉网络服务器期望什么类型的内容。在我们上面的示例中，它被设置为 application/x-www-form-urlencoded。它告诉服务器期望类似于：ParamName1=Value1&ParamName2=Value。

还有许多其他内容类型。另一个流行的是 application/json，它用于 JSON 资源。 JSON 或 JavaScript 对象表示法是一种存储和传输数据的简化方式，并且易于解释和解析。 JSON 对象由用大括号括起来的数据-值对组成。

多个库和应用程序支持 JSON 输入，包括 Web 应用程序。通常可以更改 Content-Type 并使应用程序解析不同格式的输入。

让我们拦截对登录页面的请求并尝试发送以下 JSON 输入。

Content-Type 标头应更改为 application/json 以便服务器将其解析为 JSON。

我们看到服务器成功接受了凭据并将我们重定向到仪表板。

还可以看出，将 Content-Type 设置为 application/x-www-form-urlencoded 并不会导致认证成功。这是因为服务器假定输入是表单数据，而实际上它是 JSON。

在 URLEncoded 和 JSON 之间进行更改可能看起来毫无意义，但更改格式可能会导致开发人员没有预料到的情况。由于具有 REST API，许多框架本机支持 JSON，当计算机与网络服务器而不是用户进行通信时使用该 API。在编程中，JSON 是一种广泛使用的安全存储对象的格式。

这方面的一个示例是在 MongoDB 数据库上执行 SQL 注入。要执行注入，攻击者必须发送一个数组。使用 application/x-www-form-urlencoded 执行此操作的示例是：username=admin&password[$ge]=0，它会尝试告诉服务器我的用户名是 admin 并且密码大于 0。许多 Web 服务器不会处理请求，因为在变量名上使用方括号并不常见。但是，在 REST API 中，数组很常见，不会被框架阻止。将请求更改为：

如果开发人员没有保护它，将允许注入。 Content-Type 修改可以在发现漏洞和导致 Web 应用程序中的意外错误方面发挥关键作用。但是，各种媒体类型的处理仅取决于应用程序逻辑及其预期。

PUT 和 DELETE 方法:

默认情况下，Web 服务器配置中不允许使用 PUT 和 DELETE 方法，因为它们可能存在风险，并且如果滥用，会造成损坏或导致意外访问，但可以在需要时启用。在 Web 分布式创作和版本控制 (WebDAV) 服务器上通常允许使用这些方法。 WebDAV 是 HTTP 的扩展，用于远程管理文件和文件夹。它在内容管理系统 (CMS) 和博客应用程序中很流行，使作者能够编辑和上传数据。有多种类型的 webdav 方法；但是，我们只关注 PUT 和 DELETE。可以通过发送 OPTIONS 请求找到服务器支持的方法。 OPTIONS 方法对于枚举服务器允许的方法列表很有用。这可以帮助我们计划可以用来攻击网络服务器的进一步行动。

响应中的 Allow 标头返回所有允许的方法，其中可以看到 PUT 和 DELETE。

PUT 方法

可用于覆盖任何现有文件或创建新文件。让我们尝试创建一个新文件。

响应中的 Allow 标头返回所有允许的方法，其中可以看到 PUT 和 DELETE。 PUT 方法可用于覆盖任该请求会将名为 hello.txt 的文件写入 webroot。响应为 201 Created，表示文件已成功写入。这可以通过发送 GET 请求来确认。何现有文件或创建新文件。让我们尝试创建一个新文件。

此方法可用于执行其他危险操作，例如上传 web shell 和在服务器上执行代码。

DELETE方法：

同样，DELETE 方法可用于删除现有文件。例如：

服务器以 204 No Content 响应，因为服务器满足了请求并且没有其他内容要发送。

正如预期的那样，该文件不再存在于服务器上。此方法可用于删除重要文件，通过删除网站功能导致拒绝服务

本小节重点介绍配置不当的服务器如何导致意外后果以及服务器受损。在 WebDAV 服务器上启用身份验证以防止匿名访问非常重要。

cURL：

URL（客户端 URL）是一个命令行工具和库，主要支持 HTTP 以及许多其他协议。这使它成为脚本和自动化的良好候选者。该工具至少接受一个参数，即要获取的资源

GET请求：

cURL 发出的默认 HTTP 请求是 GET 请求。让我们尝试从 GET 部分请求页面。

与浏览器不同，cURL 不能呈现 HTML 并运行 JavaScript，这意味着整个响应都是原始提供给我们的。正如我们在上面看到的，由于我们没有指定凭据，服务器返回了 401 Unauthorized 页面。可以使用“-v”开关查看原始 HTTP 请求以增加详细程度。

cURL – GET详细请求：

这次我们看到发送和接收的 HTTP 标头。 cURL 理解标准的 URL 格式，这意味着我们可以在 URL 中指定凭据。

cURL - Basic AUTH Login:

它解析凭据并添加带有编码数据的授权标头。然后服务器返回 302 Found，表示认证成功。

或者，“-u”标志也可用于指定凭据。

与浏览器不同，默认情况下 cURL 不会将我们重定向到指定位置。 “-L”标志指示 curl 遵循重定向。

这次我们成功地重定向到“/search.php”上的仪表板。 cURL 不像浏览器那样缓存凭据，这意味着我们必须在每个请求中指定它们。让我们尝试使用“port_code”参数发送一个 GET 请求。

请求成功，并返回结果。

POST请求：

让我们尝试使用 cURL 从 POST 部分登录页面。 cURL 使用的默认“Content-Type”是“application/x-www-form-urlencoded”，可以使用“-d”标志传递其数据。

当使用“-d”标志时，cURL 会自动发送一个 POST 请求。发现即使指定了有效的凭据，我们仍然在登录页面上。让我们使用“-v”开关来调试它。

上面的命令显示了整个通信过程。首先，POST 请求与凭据一起发送，由服务器验证。服务器返回 302 Found 响应并将我们重定向到仪表板。 cURL 然后尝试向仪表板发送 GET 请求，但被重定向回登录页面。

为什么会这样？仔细观察可以看出，cURL 登录后并没有重新发送它收到的 cookie。这导致仪表板身份验证失败，最终导致重定向。

“--cookie”或“--cookie-jar”选项可用于指定 cURL 中的 cookie 使用。这可以指向 /dev/null 或磁盘上的文件，cookie 将保存在其中。

这次 cookie 被附加到后续请求中，从而成功登录。

将文件名指定为参数会将 cookie 保存到文件中，以后可以使用该文件直接访问页面。

正如我们在上面看到的，第一个没有 cookie 的请求失败了，但是第二个带有“--cookie”标志的请求成功了。

Content-Type header:

也可以使用 cURL 发送 JSON 数据。这可以通过使用“-H”标志指定“application/json”标头来完成。

“-H”选项可用于指定任何标头类型。上面的响应显示使用 JSON 数据登录也是成功的。

PUT 和 DELETE 方法：

“-X”选项可用于指定要使用的请求方法。

上面的命令向服务器发送了一个 OPTIONS 请求。让我们尝试使用 PUT 方法上传文件。

我们首先创建一个名为 test.txt 的文件。 cURL 使用“@”符号来读取文件并将其内容作为数据发送。如我们所见，文件已成功上传并稍后检索。

可以类似地使用 DELETE 方法。

正如我们在上面看到的，文件被成功删除。