【THM】Web Application Basics(Web应用程序基础知识)-学习

本文相关的TryHackMe实验房间链接：https://tryhackme.com/r/room/webapplicationbasics

本文相关内容：了解 Web 应用程序的基础知识，主要包括HTTP、URL、请求方法、响应状态码和标头。

介绍

在本文中，我们将介绍 Web 应用程序的关键元素，例如 URL、HTTP 请求和 HTTP 响应。如果你刚刚开始接触Web并想要掌握相关的基本知识，或者想要构建或使用Web应用程序，那么学习本文的内容是一个完美的选择。

学习目标

通过完成本文的内容学习，你将：

• 了解什么是 Web 应用程序以及它如何在 Web 浏览器中运行。
• 分解 URL 的各个组成部分，看看它是如何帮助访问 Web 资源的。
• 了解HTTP请求和HTTP响应的工作原理。
• 熟悉不同类型的HTTP请求方法。
• 了解不同的HTTP响应代码的含义。
• 了解HTTP标头的工作原理以及它们为何对安全如此重要。

Web应用程序概述

将 Web 应用程序比作一个星球。宇航员前往星球探索其表面，类似于人们使用Web浏览器探索或浏览Web应用程序。虽然我们只看到了星球的表面，但表面下正在发生很多事情。你可以将整个星球想象成一个Web服务器，在Web服务器的表面下发生着许多事情，但我们通常只能看到表面的网页或应用程序。我们现在将探讨构成 Web 应用程序的各种组件。

前端

前端(Front End)可以被认为类似于星球的表面，是宇航员可以根据自然法则看到并与之互动的部分。 Web 应用程序需要用户与之交互，并使用多种技术（例如 HTML、CSS 和 JavaScript）来完成此操作。

HTML(超文本标记语言-Hypertext Markup Language)是 Web 应用程序的基础。它是一组指令或代码，指示Web浏览器显示什么以及如何显示。它可以与生活在星球上的简单有机体进行类比，这些生物体具有 DNA，DNA 指示了简单生物体如何组合在一起。

Web 应用程序中的CSS(层叠样式表-Cascading Style Sheets)描述了标准外观，例如某些颜色、文本类型和布局。继续与 DNA 进行类比，CSS可以与描述简单有机体的颜色、形状、大小和纹理的 DNA 部分进行比较。

JS(JavaScript)是 Web 应用程序前端的一部分，可以在 Web 浏览器中实现更复杂的活动。 HTML 可以被视为一组关于显示内容的简单指令，而 JavaScript 是一组更高级的指令，允许对显示的内容做出选择和决定。在与星球的概念类比中，JavaScript 可以被视为高级有机体的大脑，它允许根据某些事物以及与其交互的内容和方式做出决策。

后端

Web 应用程序的后端(Back End)是你在 Web 浏览器中看不到的东西，但它们对于 Web 应用程序的工作很重要。在与星球的概念类比中，Web后端可以被类比为一些非视觉上的东西，例如：保持建筑物矗立的结构、空气以及使脚保持在地面上的重力。

数据库(Database)是可以存储、修改和检索信息的地方。 Web 应用程序可能想要存储和检索有关访问者对显示或不显示内容的偏好的信息；这些信息将存储在数据库中。一个星球上可能有更高级的居民，他们会在地图中存储有关位置的信息，在日记本中撰写笔记或者将书籍放入图书馆、将文件放入文件柜中等等。

还有许多其他的基础设施(Infrastructure)组件支撑着 Web 应用程序，例如 Web 服务器、应用程序服务器、存储服务器、各种网络设备以及支持 Web 应用程序的其他软件。在一个星球上，这些东西可以类比为现有的道路、在这些道路上行驶的汽车以及为汽车提供动力的燃料等等。

WAF(Web 应用程序防火墙-Web Application Firewall)是 Web 应用程序的可选组件。它有助于过滤掉 Web 服务器上的危险请求并且能够提供元素保护。这可以被类比为一个星球的大气层将会如何保护居民免受有害紫外线的伤害。

概括

交付一个 Web 应用程序涉及许多组件，HTML、CSS 和 JavaScript 等前端组件专注于浏览器内的体验，Web 服务器、数据库或 WAF 等后端组件是使 Web 应用程序能够运行的底层引擎。

答题

计算机上的哪个组件负责托管和交付 Web 应用程序的内容？

web server

用户可以使用哪个工具来访问 Web 应用程序并与之进行交互？

web browser

哪个组件可以充当保护层，过滤传入流量以阻止恶意攻击，并且能够确保 Web 应用程序的安全？

web application firewall

URL(统一资源定位符)

Uniform Resource Locator(统一资源定位符)

统一资源定位符(URL-Uniform Resource Locator)是一个web地址，它可以让你访问各种在线内容——无论是网页(webpage)、视频、照片还是其他媒体(media)资源。它将引导你的浏览器到达互联网上的正确位置。

URL 剖析

我们可以将 URL 视为由多个部分组成，每个部分在帮助你找到正确的资源方面发挥着不同的作用。了解这些部分如何组合在一起对于浏览 Web、开发 Web 应用程序甚至解决故障排除问题非常重要。

以下是对URL的关键组件的细分：

Scheme

方案(scheme)是用于访问网站的协议。最常见的是HTTP(HyperText Transfer Protocol-超文本传输协议)和HTTPS(Hypertext Transfer Protocol Secure-安全超文本传输协议)。 HTTPS更加安全，因为它会对连接进行加密，这就是浏览器和网络安全专家推荐使用它的原因。现在很多网站通常会强制使用HTTPS来增强保护。

User

对于需要身份验证的站点，一些 URL 可能会包含用户的登录详细信息（通常是用户名）。这种情况主要发生在需要凭据才能访问某些资源的 URL 中。然而，现在这种情况很少见，因为将登录详细信息放在 URL 中不太安全——这样可能会暴露敏感信息，从而存在安全风险。

Host/Domain

主机或域名是 URL 中最重要的一部分，因为它将告诉你正在访问哪个网站。每个域名都必须是唯一的，并且已经通过域名注册商进行了注册。从安全的角度来看，需要注意那些看起来几乎像真实域名但仍有微小差异的域名（这被称为误植域名-typosquatting）。这些假域名通常会被攻击者用于执行网络钓鱼攻击，以诱骗用户泄露敏感信息。

Port

端口号有助于将你的浏览器导航至Web服务器上的正确服务。这就像告诉服务器使用哪个门口来进行通信一样。端口号的范围是从1到65535，但最常见的是HTTP协议默认使用的80端口和HTTPS协议默认使用的443端口 。

Path

路径将指向你尝试访问的服务器上的特定文件或页面。它就像一个路线图，向浏览器显示要去哪里。网站需要保护这些路径的安全，以确保只有得到授权的用户才能访问某些敏感资源。

Query String

查询字符串(查询参数-query string)是 URL 中以问号 (?) 开头的部分。它通常用于传递搜索词或表单输入等内容。由于用户可以修改这些查询字符串，因此安全地处理它们以防止发生注入等攻击非常重要，在注入攻击中攻击者会尝试向查询字符串中添加恶意代码。

Fragment

片段(片段标识符-fragment)是 URL 中以井号 (#) 开头的部分，它有助于指向网页的特定部分(在单个页面内导航到特定的部分)，例如直接跳转到特定标题或表格。用户也可以修改它，与查询字符串一样，检查和清理此处的任何可疑数据以避免注入攻击等问题也非常重要。

答题

哪种协议能够提供加密通信以确保 Web 浏览器和 Web 服务器之间的安全数据传输？

HTTPS

什么术语描述了注册由热门网站拼写错误而得到的变体域名并利用用户错误以尝试从事欺诈活动的做法？

Typosquatting(误植域名)

URL 的哪一部分可以被用于 将附加信息（例如搜索词或表单输入）传递到 Web 服务器？

Query String

HTTP消息

HTTP 消息是指在用户（客户端）和 Web 服务器之间进行信息交换的数据包。这些消息对于理解 Web 应用程序如何工作非常重要，因为它们显示了用户的请求和服务器的响应是如何通信的。

想象一个HTTP请求和HTTP响应的示例，你可以在其中看到方法(method)、URL、标头(headers)和状态码(status codes)等关键部分。这些内容使得客户端-服务器之间的交互成为可能。

HTTP消息有两种类型：

• HTTP请求(HTTP Requests)：由用户发送以触发 Web 应用程序上的操作(actions) 的消息。
• HTTP响应(HTTP Responses)：由服务器发送以响应用户的请求 的消息。

每条HTTP消息都会遵循特定的格式，这有助于用户和服务器顺利通信。

Start Line 起始行

起始行就像消息的介绍，它会告诉你正在发送什么类型的消息 - 是来自用户的请求还是来自服务器的响应；该行还提供了有关如何处理消息的一些重要细节。

Headers 标头

标头由键值对组成，提供了有关HTTP消息的额外信息。它们会向处理请求或响应的客户端和服务器发出指令。这些标头涵盖了各种各样的内容，例如安全、内容类型等，可以确保通信过程中一切顺利。

Empty Line 空行

空行是一个小分隔器，它会将标头与正文分隔开。它很重要，因为它显示了标头在哪里停止以及消息的实际内容从哪里开始。如果没有这个空行，消息就可能会变得混乱，并且客户端或服务器可能会误解它，从而导致发生错误。

Body 正文

正文是实际数据所存储的地方。在请求消息中，正文可能包含了用户想要发送到服务器的数据（如表单数据）。在响应消息中，正文是服务器用于放置用户请求的内容（例如网页或API数据）的地方。

为什么理解HTTP消息很重要

• HTTP消息是 Web 应用程序通信方式的基础，如果它们的结构正确，一切都会顺利进行。
• 了解它们的工作原理能够帮助你更好地诊断 Web 通信中的问题，这意味着你的 Web 应用程序具有更好的性能和可靠性。
• 这对于安全也至关重要。了解HTTP消息有助于你实施强大的安全措施来保护传输过程中的数据。

答题

Web 服务器在处理完客户端请求后 将会返回哪个 HTTP 消息？

HTTP response

HTTP 消息中的标头后面是什么？

Empty Line

HTTP请求：请求行和请求方法

HTTP请求是用户发送到 Web 服务器以与 Web 应用程序进行交互并执行某些操作的请求。由于这些请求通常是用户和 Web 服务器之间的第一个连接点，因此了解它们的工作原理非常重要 - 特别是涉及到网络安全的时候。

一个HTTP请求的关键部分包括方法（例如，GET 或 POST）、路径（例如，/login）和版本（例如， HTTP/1.1）。这些元素构成了客户端（用户）与服务器的通信方式的基础。

请求行

请求行（或起始行）是HTTP请求的第一部分，它将告诉服务器正在处理哪种请求。它包含三个主要部分： HTTP方法、 URL 路径和HTTP版本。

示例： METHOD /path HTTP/version

HTTP 方法

HTTP方法会告诉服务器 用户想要对 URL 路径所标识的资源执行什么操作。以下是一些最常见的HTTP方法及其可能存在的安全问题：

GET

用于从服务器获取(fetch)数据而不进行任何更改。注意！确保你只公开了允许用户查看的数据。避免在 GET 请求中放入令牌或密码等敏感信息，因为它们可能会被显示为明文。

POST

将数据发送到服务器，通常是为了创建或更新某些内容。注意！始终验证和清理输入以避免发生 SQL 注入或XSS等攻击。

PUT

替换或更新服务器上的某些内容。注意！在接受请求之前，请确保用户有权限进行更改。

DELETE

从服务器中删除某些内容。注意！就像 PUT 方法一样，确保只有得到授权的用户才能删除资源。

除了上面这些常用的HTTP方法之外，还有一些在特定情况下使用的其他方法：

PATCH 修补/补丁

用于更新资源的一部分。它对于进行小的更改而不替换整个内容很有用，但是仍应该始终验证数据以避免不一致。

HEAD

与 GET 方法类似，但它仅检索标头，而不检索完整内容。它可以方便地检查元数据，而无需下载完整的响应。

OPTIONS 选项

告诉你哪些方法可用于特定资源，帮助客户端了解它们可以使用服务器做什么。

TRACE 追踪

与 OPTIONS 类似，它将显示允许使用哪些方法，通常用于调试。许多服务器出于安全原因会禁用它。

tips：由于使用TRACE方法会回显完整的请求信息，包括可能包含的敏感数据（如Cookie、认证信息等），因此在使用它时需要特别小心。通常建议在生产环境中禁用TRACE方法，以防止潜在的安全风险，如跨站追踪（Cross-Site Tracing, XST）攻击。

CONNECT 连接

用于创建安全连接，例如 HTTPS。它并不常见，但对于加密通信至关重要。

以上这些方法中的每一种都有其自己的一组安全规则。例如， PATCH 请求应该被验证以避免不一致，如果不需要，应禁用 OPTIONS 和 TRACE 方法，以避免可能的安全风险。

URL 路径

URL 路径告诉服务器在哪里可以找到用户所请求的资源。例如，在URLhttps://tryhackme.com/api/users/123 中，路径/api/users/123标识了特定用户。

攻击者经常会尝试操纵 URL 路径来进行漏洞利用，因此以下几点至关重要：

• 验证 URL 路径以防止发生未经授权的访问；
• 清理路径以避免发生注入攻击；
• 通过进行隐私和风险评估来保护敏感数据；

遵循这些做法有助于保护你的 Web 应用程序免受一些常见攻击的影响。

HTTP 版本

HTTP版本将显示客户端和服务器之间进行通信所使用的协议版本，以下是关于最常见的HTTP协议版本的快速概述：

HTTP/0.9 (1991)

第一个版本，仅支持 GET 请求。

HTTP/1.0 (1996)

添加了标头并且能够更好地支持不同类型的内容，还改进了缓存。

HTTP/1.1 (1997)

带来了持久化连接、分块传输编码和更好的缓存，它至今仍被广泛使用。

HTTP/2 (2015)

引入了多路复用、标头压缩和优先级等功能，以提高性能。

HTTP/3 (2022)

基于HTTP/2 构建，但使用新的协议 (QUIC) 来实现更快、更安全的连接。

尽管HTTP/2和HTTP/3提供了更好的速度和安全性，但许多系统仍然在使用HTTP/1.1，因为它得到了良好的支持并且适用于大多数现有设置；然而升级到HTTP/2或HTTP/3可以提供显著的性能改进和安全性改进，因此越来越多的系统开始慢慢采用HTTP/2和HTTP/3。

答题

哪个 HTTP 协议版本被广泛采用，并且仍然是 Web 通信最常用的版本，以引入持久化连接和分块传输编码等功能而闻名？

HTTP/1.1

哪种 HTTP 请求方法描述了目标资源的通信选项，允许客户端确定 Web 服务器支持哪些 HTTP 方法？

OPTIONS

在 HTTP 请求中，哪个组件指定客户端请求的 Web 服务器上的特定资源或端点（通常出现在 URL 中的域名之后）？

URL Path

HTTP请求：标头和正文

请求标头

请求标头允许将有关请求的额外信息传送到 Web 服务器，一些常见的请求标头如下所示：

常见的请求标头

Request Header 请求标头	Example 示例	Description 描述
Host	Host: tryhackme.com	指定请求所针对的 Web 服务器的名称
User-Agent 用户代理	User-Agent: Mozilla/5.0	共享有关请求来源的 Web 浏览器的信息
Referer 引用页/来源页	Referer: https://www.google.com/	指示请求来自哪一个 URL
Cookie	Cookie: user_type=student; room=introtowebapplication; room_status=in_progress	Web 服务器预先要求 Web 浏览器存储的信息将会保存在 Cookie 中
Content-Type 内容类型	Content-Type: application/json	描述请求中数据的类型或格式

tips：“Referer”(注意拼写，这个单词实际为“referrer”的错误拼写，但在HTTP协议中被广泛使用)是HTTP请求标头中的一种。

请求正文

在 HTTP 请求（例如 POST 和 PUT）中，数据会被发送到 Web 服务器，而不是从 Web 服务器中请求数据，因此数据将位于 HTTP 请求正文中。数据的格式可以有多种，一些常见的格式包括 URL Encoded 、 Form Data 、 JSON 或 XML 。

• URL Encoded (application/x-www-form-urlencoded)

  请求正文的一种格式，其中的数据以键值对的形式构建( key=value )。多个键值对之间用&符号分隔，例如key1=value1&key2=value2 。特殊字符会采用百分比编码，即URL编码。

  POST /profile HTTP/1.1
  Host: tryhackme.com
  User-Agent: Mozilla/5.0
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 33
  
  name=Aleksandra&age=27&country=US
  

• Form Data (multipart/form-data)

  请求正文的一种格式，允许发送多个数据块，其中每个块将由边界字符串分隔。边界字符串是请求本身所定义的标头。这种类型的格式可用于发送二进制数据，例如将文件或图像上传到 Web 服务器时。

  POST /upload HTTP/1.1
  Host: tryhackme.com
  User-Agent: Mozilla/5.0
  Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
  
  ----WebKitFormBoundary7MA4YWxkTrZu0gW
  Content-Disposition: form-data; name="username"
  
  aleksandra
  ----WebKitFormBoundary7MA4YWxkTrZu0gW
  Content-Disposition: form-data; name="profile_pic"; filename="aleksandra.jpg"
  Content-Type: image/jpeg
  
  [Binary Data Here representing the image]
  ----WebKitFormBoundary7MA4YWxkTrZu0gW--
  

• JSON (application/json)

  请求正文的一种格式，在这种格式中，可以使用JSON(JavaScript Object Notation-JavaScript对象表示法)结构发送数据。数据的格式为"name : value"所构成的名称-值对。多个名称-值对之间将以逗号进行分隔，并且会全部包含在一个大括号 { } 内。

  POST /api/user HTTP/1.1
  Host: tryhackme.com
  User-Agent: Mozilla/5.0
  Content-Type: application/json
  Content-Length: 62
  
  {
      "name": "Aleksandra",
      "age": 27,
      "country": "US"
  }
  

• XML (application/xml)

  请求正文的一种格式，在XML格式中，数据将被组织在标签(tags)内，标签具有开始和结束。这些标签可以相互嵌套。你可以在下面的示例中看到标签的开始和结束情况，该示例用于发送名为 Aleksandra 的用户的详细信息。

  POST /api/user HTTP/1.1
  Host: tryhackme.com
  User-Agent: Mozilla/5.0
  Content-Type: application/xml
  Content-Length: 124
  
  <user>
      <name>Aleksandra</name>
      <age>27</age>
      <country>US</country>
  </user>
  

答题

哪个 HTTP 请求标头指定了请求发送到的 Web 服务器的域名？

Host

HTTP 请求中表单提交的默认内容类型是什么？其中的数据会被编码为查询字符串格式的键=值对。

application/x-www-form-urlencoded

HTTP 请求的哪一部分包含了附加信息（例如主机、用户代理和内容类型），用以指导 Web 服务器应该如何处理请求？

Request Headers

HTTP响应：状态行和状态码

当你与一个 Web 应用程序进行交互时，服务器会发送回一个HTTP响应，让你知道请求是否成功或者请求出现了问题。这些响应包括一个状态码和一个简短的说明(被称为原因短语-Reason Phrase)，它们可以让你深入了解服务器会如何处理你的请求。

状态行

每个HTTP响应中的第一行被称为状态行(Status Line)，它能为你提供三个关键信息：

1. HTTP版本：这会告诉你正在使用哪个版本的HTTP 。
2. 状态码：可以显示请求结果的三位数字。
3. 原因短语-Reason Phrase：以人类可读的方式解释状态码的短消息。

由于我们已经在上文的第5小节中介绍了与HTTP版本相关的一些信息，因此我们在本小节中会重点关注状态码(Status Codes)和原因短语(Reason Phrases)。

状态码和原因短语

状态码是告诉你请求是成功还是失败的数字，而原因短语(Reason Phrase)则会说明发生了什么。状态码可以被分为下面五个主要的类别：

信息性响应(100-199)

这些状态码意味着服务器已收到部分请求并且正在等待其余的请求。这是一个“keep going-继续前进”的信号。

成功响应(200-299)

这些状态码意味着一切都按预期进行。服务器会处理请求并发送回客户端所请求的数据。

重定向消息 (300-399)

这些状态码将告诉你-你所请求的资源已移至其他位置。此时通常还会提供新的 URL。

客户端错误响应 (400-499)

出现这些状态码表明请求本身存在问题。也许 URL 是错误的，或者你缺少一些必需的信息，例如身份验证等。

服务器错误响应 (500-599)

这些状态码意味着服务器在尝试满足请求时遇到错误。这些错误通常是服务器端的问题，而不是客户端的错误。

常见状态码

以下是一些最常见的状态码：

100 (Continue)

服务器收到请求的第一部分并准备好处理其余的部分。

200 (OK)

请求成功，服务器正在发送回用户所请求的资源。

301 (Moved Permanently)

你所请求的资源已永久地移动到了新的 URL 处，从现在开始请你使用新的 URL来进行资源请求。

404 (Not Found)

这表示服务器无法在给定的 URL 处找到资源，请仔细检查你提供的地址是否正确。

500 (Internal Server Error)

服务器端出现了问题，并且服务器无法处理你的请求。

答题

HTTP 响应的哪一部分会提供关于 HTTP 版本、状态码以及响应结果的简要说明？

Status Line

哪一类 HTTP 响应码表明 Web 服务器遇到内部问题或无法满足客户端的请求？

Server Error Responses

哪个 HTTP 状态码表示在 Web 服务器上找不到所请求的资源？

404

HTTP响应：标头和正文

响应标头

当 Web 服务器响应HTTP请求时，它会包含HTTP响应标头，这些标头基本上是键值(key-value)对。这些标头可以提供有关响应的重要信息，并且告诉客户端（通常是浏览器）应该如何处理它。

查看下面的HTTP响应示例的示意图，其中标头会被突出显示。 Content-Type 、 Content-Length和Date等关键标头为我们提供了有关服务器发回的响应的重要详细信息。

必需的响应标头

一些响应标头对于确保HTTP响应正常工作至关重要，它们将提供客户端和服务器正确处理所有内容所需的基本信息。以下是一些重要的响应标头：

• Date 日期：

  示例: Date: Fri, 23 Aug 2024 10:43:21 GMT

  此标头会显示服务器生成响应的确切日期和时间。

• Content-Type 内容类型：
  示例: Content-Type: text/html; charset=utf-8

  此标头会告诉客户端它正在获取什么类型的内容，例如是 HTML、 JSON还是其他内容，此处还包括字符集（如 UTF-8），可用于帮助浏览器正确显示内容。

• Server 服务器：
  示例: Server: nginx

  该标头将显示正在处理请求的服务器软件类型。它有利于调试(debugging)，但也可能会泄露对攻击者有用的服务器信息，因此许多人会删除或掩盖这一部分信息。

其他常见的响应标头

除了基本的响应标头之外，还有其他常见的响应标头，它们会向客户端或浏览器提供附加说明，并帮助控制如何处理响应。

• Set-Cookie 设置Cookie ：
  示例: Set-Cookie: sessionId=38af1337es7a8

  这会将 cookie 从服务器发送到客户端，然后客户端将存储这些 cookie 并将其与将来的请求一起发回。为了保证安全，请确保cookie设置了HttpOnly标志（这样JavaScript就无法访问它们）和Secure标志（这样它们仅会通过 HTTPS 发送）。

• Cache-Control 缓存控制：
  示例: Cache-Control: max-age=600

  该标头会告诉客户端在再次检查服务器之前可以缓存 响应消息 多长时间。如果需要的话，它还可以防止敏感信息被缓存（使用no-cache ）。

• Location 定位：
  示例: Location: /index.html

  这个标头可用于重定向 (3xx) 响应。如果资源已移动，它会告诉客户端下一步该去哪里。如果用户可以在请求期间修改此标头，请小心验证和清理它，否则，你最终可能会遇到开放重定向漏洞攻击，在此类攻击中，攻击者可以将用户重定向到有害的恶意站点。

在Cookie中设置HttpOnly标志之后会有以下特点：

1. 不可通过客户端脚本访问：当一个Cookie被设置为HttpOnly时，它不能通过JavaScript（例如，使用document.cookie属性）进行访问。这样可以有效防止恶意代码获取Cookie中的敏感信息并执行攻击。
2. 仍可通过HTTP协议访问：尽管HttpOnly Cookie对于客户端脚本不可见，但它们仍然可以通过HTTP标头在客户端和服务器之间传递。这意味着HttpOnly Cookie在保持安全性的同时仍然可以正常工作。

响应正文

HTTP响应正文(body)是实际数据所在的位置，例如服务器发送回客户端的HTML、 JSON 、图像等。为了防止跨站脚本 (XSS) 等注入攻击，请务必先清理并转义任何输入数据（尤其是用户所生成的内容），然后再将它们包含在响应消息中。

答题

哪个 HTTP 响应标头可以泄露有关 Web 服务器的软件和版本的信息，如果不删除，可能会使其面临安全风险？

Server

应该在 Set-Cookie HTTP 响应标头中的 cookie 中添加哪个标志，以确保它们仅通过 HTTPS 传输，从而防止它们在未加密传输期间被暴露？

Secure

应该在 Set-Cookie HTTP 响应标头中的 cookie 中添加哪个标志，以防止通过 JavaScript 访问它们，从而增强针对 XSS 攻击的安全防护？

HttpOnly

HTTP安全标头

HTTP安全标头可以通过提供针对跨站点脚本 ( XSS )、点击劫持等攻击的缓解措施，来帮助提高 Web 应用程序的整体安全性，现在我们将深入研究以下几种安全标头：

• Content-Security-Policy (CSP)：内容安全策略；
• Strict-Transport-Security (HSTS)：严格传输安全；
• X-Content-Type-Options
• Referrer-Policy：来源策略。

你可以使用像https://securityheaders.io/这样的站点来分析任何网站的安全标头(并且能够查看相关的标头分析报告)，经过本小节的学习之后，你将有望更好地理解 标头分析报告 的内容。

内容安全策略(CSP-Content-Security-Policy)标头

CSP 标头是一个附加的安全层，可以帮助缓解跨站点脚本 ( XSS ) 等常见攻击。恶意代码可能托管在单独的网站或域上，并会被注入到易受攻击的网站中。 CSP为管理员提供了一种方式来说明哪些域或源被认为是安全的，并可以为XSS等攻击提供一层缓解措施。

在这个标头的信息中，你可能会看到诸如 default-src 或 script-src 等已定义的属性，以及其他多种属性。这些属性为管理员提供了不同粒度级别的配置选项，用于定义允许哪些域加载何种类型的内容。其中，self 是一个特殊关键字，表示仅允许与托管当前网站的域相同的域名进行资源加载。

查看下面的CSP标头示例：

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.tryhackme.com; style-src 'self'

我们可以看到上述示例所使用的一些属性：

• default-src

  -它指定使用默认策略 self，表示允许与当前页面同源（协议+域名+端口完全匹配）的资源加载(允许从当前网站中加载资源)。

• script-src

  -它指定了可以从何处加载脚本的策略，策略被设置为self(允许从当前网站中加载脚本)以及允许加载https://cdn.tryhackme.com站点上所托管的脚本。

• style-src

  -它指定了可以从何处加载 CSS 样式表的策略，如果被设置为self 则表示仅允许从当前网站中加载CSS。

严格传输安全Strict-Transport-Security (HSTS)标头

HSTS 标头可确保 Web 浏览器始终通过 HTTPS 进行连接，我们来看一个 HSTS 的示例：

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

以下是 HSTS 标头示例按指令进行细分的情况：

• max-age

  -设置的到期时间（以秒为单位）。

• includeSubDomains
  -一个可选设置，用于指示浏览器将此设置应用于所有子域。

• preload

  -这个可选设置允许网站被包含在预加载(preload)列表中，浏览器甚至可以在第一次访问网站之前使用预加载列表来强制执行 HSTS。

X-Content-Type-Options标头

X-Content-Type-Options 标头可用于指示浏览器不要猜测资源的MIME时间，而仅使用 Content-Type 标头。下面是一个相关示例：

X-Content-Type-Options: nosniff

以下是 X-Content-Type-Options 标头示例按指令进行细分的情况：

• nosniff
  -该指令指示了浏览器不要嗅探或猜测MIME类型。

Referrer-Policy标头

此标头可以控制当用户从源 Web 服务器开始重定向时（例如当用户单击超链接时）发送到目标 Web 服务器的信息量，这个标头可以让网络管理员控制共享哪些信息。以下是关于Referrer-Policy的一些示例：

• Referrer-Policy: no-referrer
• Referrer-Policy: same-origin
• Referrer-Policy: strict-origin
• Referrer-Policy: strict-origin-when-cross-origin

以下是按指令对 Referrer-Policy 标头进行细分的情况：

• no-referrer 无来源信息

  -这将完全禁止发送有关referrer(来源信息)的任何信息

• same-origin 同源

  -该策略仅在目标地址与当前页面同源时才会发送来源信息（referrer）。此机制适用于需要传递站内超链接的来源信息，但避免将其泄露至外部网站的场景。

• strict-origin 严格来源
  -该策略仅在协议保持不变时，将来源信息（referrer）限制为仅发送源域名（origin）。例如：当从HTTPS连接跳转至另一个HTTPS连接时，才会发送来源信息。

• strict-origin-when-cross-origin 跨源时严格来源

  -该策略与 strict-origin 类似，但针对同源请求时会发送完整的URL路径（包含协议、域名和路径），而跨源请求时仅发送源域名（协议+域名）。

注意事项

以下是一些常见的HTTP安全标头：

1. Content-Security-Policy (CSP)：用于限制页面可以加载的资源类型和来源，防止跨站脚本（XSS）和数据注入攻击。

2. Strict-Transport-Security (HSTS)：强制浏览器仅通过HTTPS访问网站，防止中间人攻击。

3. X-Frame-Options：防止点击劫持攻击，控制页面是否可以在iframe中加载。

4. X-XSS-Protection：启用浏览器内置的跨站脚本（XSS）过滤器，防止XSS攻击。

5. X-Content-Type-Options：防止浏览器执行MIME嗅探，确保Content-Type标头的正确性。

6. Access-Control-Allow-Origin：控制跨域资源共享（CORS），限制哪些来源可以访问资源。

7. Set-Cookie：用于设置cookie，可以包含Secure和HttpOnly标志，增强cookie的安全性。

8. Referrer-Policy：控制Referrer标头的发送行为，减少敏感信息的泄露。

答题

在内容安全策略 (CSP-Content Security Policy) 配置中，可以设置哪个属性来定义将从何处加载脚本？

script-src

配置严格传输安全 (HSTS-Strict-Transport-Security) 标头以确保一个网站的所有子域也在使用 HTTPS 时，应该包含哪个指令以将安全策略应用于主域及其子域？

includeSubDomains

哪个 HTTP 标头指令可用于防止浏览器将文件解释为与服务器指定的 MIME 类型不同的 MIME 类型，从而缓解 内容类型-嗅探攻击？

nosniff

实践练习：发出HTTP请求

在与本文相关的TryHackMe实验房间中，单击本小节页面右侧的“查看站点”按钮以在拆分视图中启动静态站点。

这是一个用于演示发出HTTP请求的模拟器。请利用你从上述小节中所学到的知识，完成以下答题任务。

如果在本小节中启动的静态站点不可见，请单击实验房间页面顶部的蓝色显示拆分视图按钮。

答题

向/api/users发出GET请求，获得的flag是什么？

THM{YOU_HAVE_JUST_FOUND_THE_USER_LIST} 。

向/api/user/2发出POST请求，并将 Bob 的国家/地区从UK更新为US，我们可以获得的flag是什么？(注意区分大小写)

THM{YOU_HAVE_MODIFIED_THE_USER_DATA} 。

向/api/user/1发出DELETE请求以删除用户，获得的flag是什么？

THM{YOU_HAVE_JUST_DELETED_A_USER} 。

本文小结

我们希望你更好地去学习构成 Web 应用程序的元素，在完成本文内容的阅读之后，希望你对以下内容有了更多了解：

• 常见的Web应用程序涉及哪些组件；
• 统一资源定位符(URL-Uniform Resource Locator)的结构是什么样的；
• HTTP消息、请求、标头和响应是什么；
• 安全标头的重要性。