禁欲28天！一宅男居然肝出如此详细Web安全学习笔记，学妹看完直接抽搐了！（第二弹）

Posted 李志宽

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了禁欲28天！一宅男居然肝出如此详细Web安全学习笔记，学妹看完直接抽搐了！（第二弹）相关的知识，希望对你有一定的参考价值。

2.1. 网络基础

2.1.1. 计算机通信网的组成

计算机网络由通信子网和资源子网组成。其中通信子网负责数据的无差错和有序传递，其处理功能包括差错控制、流量控制、路由选择、网络互连等。

其中资源子网是计算机通信的本地系统环境，包括主机、终端和应用程序等， 资源子网的主要功能是用户资源配置、数据的处理和管理、软件和硬件共享以及负载 均衡等。

总的来说，计算机通信网就是一个由通信子网承载的、传输和共享资源子网的各类信息的系统。

2.1.2. 通信协议

为了完成计算机之间有序的信息交换，提出了通信协议的概念，其定义是相互通信的双方（或多方）对如何进行信息交换所必须遵守的一整套规则。

协议涉及到三个要素，分别为：

  • 语法：语法是用户数据与控制信息的结构与格式，以及数据出现顺序的意义
  • 语义：用于解释比特流的每一部分的意义
  • 时序：事件实现顺序的详细说明

2.1.3. OSI七层模型

2.1.3.1. 简介

OSI（Open System Interconnection）共分为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层七层，其具体的功能如下。

2.1.3.2. 物理层

  • 提供建立、维护和释放物理链路所需的机械、电气功能和规程等特性
  • 通过传输介质进行数据流(比特流)的物理传输、故障监测和物理层管理
  • 从数据链路层接收帧，将比特流转换成底层物理介质上的信号

2.1.3.3. 数据链路层

  • 在物理链路的两端之间传输数据
  • 在网络层实体间提供数据传输功能和控制
  • 提供数据的流量控制
  • 检测和纠正物理链路产生的差错
  • 格式化的消息称为帧

2.1.3.4. 网络层

  • 负责端到端的数据的路由或交换，为透明地传输数据建立连接
  • 寻址并解决与数据在异构网络间传输相关的所有问题
  • 使用上面的传输层和下面的数据链路层的功能
  • 格式化的消息称为分组

2.1.3.5. 传输层

  • 提供无差错的数据传输
  • 接收来自会话层的数据，如果需要，将数据分割成更小的分组，向网络层传送分组并确保分组完整和正确到达它们的目的地
  • 在系统之间提供可靠的透明的数据传输,提供端到端的错误恢复和流量控制

2.1.3.6. 会话层

  • 提供节点之间通信过程的协调
  • 负责执行会话规则（如：连接是否允许半双工或全双工通信）、同步数据流以及当故障发生时重新建立连接
  • 使用上面的表示层和下面的传输层的功能

2.1.3.7. 表示层

  • 提供数据格式、变换和编码转换
  • 涉及正在传输数据的语法和语义
  • 将消息以合适电子传输的格式编码
  • 执行该层的数据压缩和加密
  • 从应用层接收消息，转换格式，并传送到会话层，该层常合并在应用层中

2.1.3.8. 应用层

  • 包括各种协议，它们定义了具体的面向用户的应用：如电子邮件、文件传输等

2.1.3.9. 总结

低三层模型属于通信子网，涉及为用户间提供透明连接，操作主要以每条链路（ hop-by-hop）为基础，在节点间的各条数据链路上进行通信。由网络层来控制各条链路上的通信，但要依赖于其他节点的协调操作。

高三层属于资源子网，主要涉及保证信息以正确可理解形式传送。

传输层是高三层和低三层之间的接口，它是第一个端到端的层次，保证透明的端到端连接，满足用户的服务质量（QoS）要求，并向高三层提供合适的信息形式。

2.2. UDP协议

2.2.1. 主要特点

  • 协议开销小、效率高。
  • UDP是无连接的，即发送数据之前不需要建立连接。
  • UDP使用尽最大努力交付，即不保证可靠交付。
  • UDP没有拥塞控制。
  • UDP支持一对一、一对多、多对一和多对多交互通信。
  • UDP的首部开销小，只有8个字节。

2.3. TCP协议

2.3.1. 简介

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由RFC 793定义。

2.3.2. TCP状态

statetransition

2.3.2.1. 三次握手

三次握手（Three-Way Handshake）是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。

第一次握手客户端将标志位 SYN 置为1，随机产生一个值 seq=s ，并将该数据包发送给服务端，客户端进入 SYN_SENT 状态，等待服务端确认。

第二次握手服务端收到数据包后由标志位 SYN=1 知道客户端请求建立连接，服务端将标志位 SYN 和 ACK 都置为1，ack=s+1，随机产生一个值 seq=k ，并将该数据包发送给客户端以确认连接请求，服务端进入 SYN_RCVD 状态。

第三次握手客户端收到确认后，检查ack值是否为s+1，ACK标志位是否为1，如果正确则将标志位 ACK 置为1，ack=k+1，并将该数据包发送给服务端，服务端检查ack值是否为k+1，ACK标志位是否为1，如果正确则连接建立成功，客户端和服务端进入 ESTABLISHED 状态，完成三次握手。

2.3.2.2. 四次挥手

四次挥手（Four-Way Wavehand）指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。

第一次挥手客户端发送一个 FIN ，用来关闭客户端到服务端的数据传送，客户端进入 FIN_WAIT_1 状态。

第二次挥手服务端收到 FIN 后，发送一个 ACK 给客户端，确认序号为收到序号+1，服务端进入 CLOSE_WAIT 状态。

第三次挥手服务端发送一个 FIN ，用来关闭服务端到客户端的数据传送，服务端进入 LAST_ACK 状态。

第四次挥手客户端收到 FIN 后，客户端进入 TIME_WAIT 状态，接着发送一个 ACK 给服务端，确认序号为收到序号+1，服务端进入 CLOSED 状态，完成四次挥手。

2.3.3. 拥塞控制

拥塞是指网络中报文数量过多，使得服务端来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿即出现死锁现象。

TCP采用拥塞控制算法来减少或者避免拥塞现象的发生，TCP的拥塞算法有过多种实现，包括Tahoe、Reno、NewReno、Vegas、Hybla、BIC 、CUBIC、SACK、Westwood、PRR、BBR等。

2.3.4. 参考链接

2.4. DHCP协议

2.4.1. 简介

动态主机配置协议 (Dynamic Host Configuration Protocol，DHCP) 是一个用于局域网的网络协议，位于OSI模型的应用层，使用UDP协议工作，主要用于自动分配IP地址给用户，方便管理员进行统一管理。

DHCP服务器端使用67/udp，客户端使用68/udp。DHCP运行分为四个基本过程，分别为请求IP租约、提供IP租约、选择IP租约和确认IP租约。客户端在获得了一个IP地址以后，就可以发送一个ARP请求来避免由于DHCP服务器地址池重叠而引发的IP冲突。

2.4.2. DCHP 报文格式

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
+---------------+---------------+---------------+---------------+
|                            xid (4)                            |
+-------------------------------+-------------------------------+
|           secs (2)            |           flags (2)           |
+-------------------------------+-------------------------------+
|                          ciaddr  (4)                          |
+---------------------------------------------------------------+
|                          yiaddr  (4)                          |
+---------------------------------------------------------------+
|                          siaddr  (4)                          |
+---------------------------------------------------------------+
|                          giaddr  (4)                          |
+---------------------------------------------------------------+
|                          chaddr  (16)                         |
+---------------------------------------------------------------+
|                          sname   (64)                         |
+---------------------------------------------------------------+
|                          file    (128)                        |
+---------------------------------------------------------------+
|                          options (variable)                   |
+---------------------------------------------------------------+

2.4.3. 参考链接

2.4.3.1. RFC

2.5. 路由算法

2.5.1. 简介

路由算法是用于找到一条从源路由器到目的路由器的最佳路径的算法。存在着多种路由算法，每种算法对网络和路由器资源的影响都不同；由于路由算法使用多种度量标准 (metric)，所以不同路由算法的最佳路径选择也有所不同。

2.5.2. 路由选择算法的功能

源/宿对之间的路径选择，以及选定路由之后将报文传送到它们的目的地。

路由选择算法的要求：

  • 正确性：确保分组从源节点传送到目的节点
  • 简单性：实现方便，软硬件开销小
  • 自适应性：也称健壮性，算法能够适应业务量和网络拓扑的变化
  • 稳定性：能长时间无故障运行
  • 公平性：每个节点都有机会传送信息
  • 最优性：尽量选取好的路由

2.5.3. 自治系统 AS (Autonomous System)

经典定义：

  • 由一个组织管理的一整套路由器和网络。
  • 使用一种AS 内部的路由选择协议和共同的度量以确定分组在该 AS 内的路由。
  • 使用一种 AS 之间的路由选择协议用以确定分组在AS之间的路由。

尽管一个 AS 使用了多种内部路由选择协议和度量，但对其他 AS 表现出的是一个单一的和一致的路由选择策略。

2.5.4. 两大类路由选择协议

因特网的中，路由协议可以分为内部网关协议 IGP (Interior Gateway Protocol)和外部网关协议 EGP (External Gateway Protocol)。

IGP是在一个AS内部使用的路由选择协议，如RIP和OSPF协议，是域内路由选择 (interdomain routing)。当源主机和目的主机处在不同的AS中，在数据报到达AS的边界时，使用外部网关协议 EGP 将路由选择信息传递到另一个自治系统中，如BGP-4，是域间路由选择 (intradomain routing)。

2.5.5. RIP

路由信息协议 (Routing Information Protocol, RIP) 是一种基于距离 向量的路由选择协议。RIP 协议要求网络中的每一个路由器都要维护从它自己到自治系统内其他每一个目的网络的距离和下一跳路由器地址。

2.5.6. OSPF

开放最短路径优先(Open Shortest Path First，OSPF)，这个算法名为“最短路径优先”是因为使用了 Dijkstra 提出的最短路径算法SPF，只是一个协议的名字，它并不表示其他的路由选择协议不是“最短路径优先”。

2.6. 域名系统

2.6.1. 简介

DNS是一个简单的请求-响应协议，是将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP协议的53端口。

2.6.2. 术语

2.6.2.1. mDNS

Multicast DNS (mDNS)，多播DNS，使用5353端口，组播地址为 224.0.0.251 或 [FF02::FB] 。在一个没有常规DNS服务器的小型网络内可以使用mDNS来实现类似DNS的编程接口、包格式和操作语义。mDNS协议的报文与DNS的报文结构相同，但有些字段对于mDNS来说有新的含义。

启动mDNS的主机会在进入局域网后向所有主机组播消息，包含主机名、IP等信息，其他拥有相应服务的主机也会响应含有主机名和IP的信息。

mDNS的域名是用 .local 和普通域名区分开的。

2.6.2.2. FQDN

FQDN (Fully-Qualified Domain Name) 是域名的完全形态，主要是包含零长度的根标签，例如 www.example.com. 。

2.6.2.3. TLD

Top-Level Domain (TLD) 是属于根域的一个域，例如 com 或 jp 。

TLD一般可以分为 Country Code Top-Level Domains (ccTLDs) 、Generic Top-Level Domains (gTLDs) 以及其它。

2.6.2.4. IDN

Internationalized Domain Names for Applications (IDNA) 是为了处理非ASCII字符的情况。

2.6.2.5. CNAME

CNAME即Canonical name，又称alias，将域名指向另一个域名。

2.6.2.6. TTL

Time To Live，无符号整数，记录DNS记录过期的时间，最小是0，最大是2147483647 (2^31 - 1)。

2.6.3. 请求响应

2.6.3.1. DNS记录

  • A记录

    • 返回域名对应的IPv4地址

  • NS记录

    • 域名服务器
    • 返回该域名由哪台域名服务器解析

  • PTR记录

    • 反向记录
    • 从IP地址到域名的记录

  • MX记录

    • 电子邮件交换记录
    • 记录邮件域名对应的IP地址

2.6.3.2. 响应码

  • NOERROR
No error condition
  • FORMERR
Format error - The name server was unable to interpret the query
  • SERVFAIL
Server failure - The name server was unable to process this query due to a problem with the name server
  • NXDOMAIN
this code signifies that the domain name referenced in the query does not exist
  • NOTIMP
Not Implemented - The name server does not support the requested kind of query
  • REFUSED
Refused - The name server refuses to perform the specified operation for policy reasons
  • NODATA
A pseudo RCODE which indicates that the name is valid, for the given class, but [there] are no records of the given type A NODATA response has to be inferred from the answer.

2.6.4. 域名系统工作原理

2.6.4.1. 解析过程

DNS解析过程是递归查询的，具体过程如下：

  • 用户要访问域名www.example.com时，先查看本机hosts是否有记录或者本机是否有DNS缓存，如果有，直接返回结果，否则向递归服务器查询该域名的IP地址
  • 递归缓存为空时，首先向根服务器查询com顶级域的IP地址
  • 根服务器告知递归服务器com顶级域名服务器的IP地址
  • 递归向com顶级域名服务器查询负责example.com的权威服务器的IP
  • com顶级域名服务器返回相应的IP地址
  • 递归向example.com的权威服务器查询www.example.com的地址记录
  • 权威服务器告知www.example.com的地址记录
  • 递归服务器将查询结果返回客户端

2.6.4.2. 域传送

DNS服务器可以分为主服务器、备份服务器和缓存服务器。域传送是指备份服务器从主服务器拷贝数据，并使用得到的数据更新自身数据库。域传送是在主备服务器之间同步数据库的机制。

2.6.5. 服务器类型

2.6.5.1. 根服务器

根服务器是DNS的核心，负责互联网顶级域名的解析，用于维护域的权威信息，并将DNS查询引导到相应的域名服务器。

根服务器在域名树中代表最顶级的 . 域， 一般省略。

13台IPv4根服务器的域名标号为a到m，即a.root-servers.org到m.root-servers.org，所有服务器存储的数据相同，仅包含ICANN批准的TLD域名权威信息。

2.6.5.2. 权威服务器

权威服务器上存储域名Zone文件，维护域内域名的权威信息，递归服务器可以从权威服务器获得DNS查询的资源记录。

权威服务器需要在所承载的域名所属的TLD管理局注册，同一个权威服务器可以承载不同TLD域名，同一个域也可以有多个权威服务器。

2.6.5.3. 递归服务器

递归服务器负责接收用户的查询请求，进行递归查询并响应用户查询请求。在初始时递归服务器仅有记录了根域名的Hint文件。

2.6.6. DNS利用

2.6.6.1. DGA

DGA（Domain Generate Algorithm，域名生成算法）是一种利用随机字符来生成C&C域名，从而逃避域名黑名单检测的技术手段，常见于botnet中。一般来说，一个DGA域名的存活时间约在1-7天左右。

通信时，客户端和服务端都运行同一套DGA算法，生成相同的备选域名列表，当需要发动攻击的时候，选择其中少量进行注册，便可以建立通信，并且可以对注册的域名应用速变IP技术，快速变换IP，从而域名和IP都可以进行快速变化。

DGA域名有多种生成方式，根据种子类型可以分为确定性和不确定性的生成。不确定性的种子可能会选用当天的一些即时数据，如汇率信息等。

2.6.6.2. DNS隧道

DNS隧道工具将进入隧道的其他协议流量封装到DNS协议内，在隧道上传输。这些数据包出隧道时进行解封装，还原数据。

2.6.7. 加密方案

作为主流的防御方案，DNS加密有五种方案，分别是 DNS-over-TLS (DoT)、DNS-over-DTLS、DNS-over-HTTPS (DoH)、DNS-over-QUIC以及DNSCrypt。

2.6.7.1. DoT

DoT方案在2016年发表于RFC7858，使用853端口。主要思想是Client和Server通过TCP协议建立TLS会话后再进行DNS传输，Client通过SSL证书验证服务器身份。

2.6.7.2. DNS-over-DTLS

DNS-over-DTLS和DoT类似，区别在于使用UDP协议而不是TCP协议。

2.6.7.3. DoH

DoH方案在发表RFC8484，使用 https://dns.example.com/dns-query{?dns} 来查询服务器的IP，复用https的443端口，流量特征比较小。DoH会对DNS服务器进行加密认证，不提供fallback选项。目前Cloudflare、Google等服务商对DoH提供了支持。

2.6.7.4. DNS-over-QUIC

DNS-over-QUIC安全特性和DoT类似，但是性能更高，目前没有合适的软件实现。

2.6.7.5. DNSCrypt

DNSCrypt使用X25519-XSalsa20Poly1305而非标准的TLS，且DNSCrypt的Client需要额外的软件，Server需要的专门的证书。

2.6.8. 相关漏洞

2.6.8.1. DNS劫持

DNS劫持有多种方式，比较早期的攻击方式是通过攻击域名解析服务器，或是伪造DNS响应的方法，来将域名解析到恶意的IP地址。

随着互联网应用的不断发展，出现了基于废弃记录的劫持方式。这种方式发生的场景是次级域名的解析记录指向第三方资源，而第三方资源被释放后，解析记录并没有取消，在这种场景下，可以对应申请第三方资源，以获取控制解析记录的能力。

2.6.8.2. 拒绝服务

DNS服务通常会开启UDP端口，当DNS服务器拥有大量二级域NS记录时，通过DNS的UDP反射攻击可以实现高倍的拒绝服务。

看到这里的大佬，动动发财的小手 点赞 + 回复 + 收藏，能【 关注 】一波就更好了

我是一名渗透测试工程师，为了感谢读者们，我想把我收藏的一些网络安全/渗透测试学习干货贡献给大家，回馈每一个读者，希望能帮到你们。

干货主要有：

①　2000多本网安必看电子书（主流和经典的书籍应该都有了）

②　php标准库资料（最全中文版）

③　项目源码（四五十个有趣且经典的练手项目及源码）

④ 网络安全基础入门、Linux运维，web安全、渗透测试方面的视频（适合小白学习）

⑤ 网络安全学习路线图（告别不入流的学习）

⑥ 渗透测试工具大全

⑦ 2021网络安全/Web安全/渗透测试工程师面试手册大全

各位朋友们可以关注+评论一波 然后加下QQ群：581499282  备注：CSDN  即可免费获取全部资料

2.6.9. 参考链接

2.6.9.1. RFC

2.6.9.2. 工具

2.6.9.3. 研究文章

2.6.9.4. 相关CVE

2.7. HTTP协议簇

内容索引:

2.7.1. HTTP标准

2.7.1.1. 报文格式

2.7.1.1.1. 请求报文格式

<method><request-URL><version>
<headers>

<entity-body>

2.7.1.1.2. 响应报文格式

<version><status><reason-phrase>
<headers>

<entity-body>

2.7.1.1.3. 字段解释

  • method

    • HTTP动词
    • 常见方法：HEAD / GET / POST / PUT / DELETE / PATCH / OPTIONS / TRACE
    • 扩展方法：LOCK / MKCOL / COPY / MOVE

  • version

    • 报文使用的HTTP版本
    • 格式为HTTP/<major>.<minor>

  • url

    • <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

2.7.1.2. 请求头列表

  • Accept

    • 指定客户端能够接收的内容类型
    • Accept: text/plain, text/html

  • Accept-Charset

    • 浏览器可以接受的字符编码集
    • Accept-Charset: iso-8859-5

  • Accept-Encoding

    • 指定浏览器可以支持的web服务器返回内容压缩编码类型
    • Accept-Encoding: compress, gzip

  • Accept-Language

    • 浏览器可接受的语言
    • Accept-Language: en,zh

  • Accept-Ranges

    • 可以请求网页实体的一个或者多个子范围字段
    • Accept-Ranges: bytes

  • Authorization

    • HTTP授权的授权证书
    • Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

  • Cache-Control

    • 指定请求和响应遵循的缓存机制 Cache-Control: no-cache

  • Connection

    • 表示是否需要持久连接 // HTTP 1.1默认进行持久连接
    • Connection: close

  • Cookie

    • HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器
    • Cookie: role=admin;ssid=1

  • Content-Length

    • 请求的内容长度
    • Content-Length: 348

  • Content-Type

    • 请求的与实体对应的MIME信息
    • Content-Type: application/x-www-form-urlencoded

  • Date

    • 请求发送的日期和时间
    • Date: Tue, 15 Nov 2010 08:12:31 GMT

  • Expect

    • 请求的特定的服务器行为
    • Expect: 100-continue

  • From

  • Host

    • 指定请求的服务器的域名和端口号
    • Host: www.github.com

  • If-Match

    • 只有请求内容与实体相匹配才有效
    • If-Match: "737060cd8c284d8af7ad3082f209582d"

  • If-Modified-Since

    • 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码
    • If-Modified-Since: Sat, 29 Oct 2018 19:43:31 GMT

  • If-None-Match

    • 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变
    • If-None-Match: "737060cd8c284d8af7ad3082f209582d"

  • If-Range

    • 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag
    • If-Range: "737060cd8c284d8af7ad3082f209582d"

  • If-Unmodified-Since

    • 只在实体在指定时间之后未被修改才请求成功
    • If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT

  • Max-Forwards

    • 限制信息通过代理和网关传送的时间
    • Max-Forwards: 10

  • Pragma

    • 用来包含实现特定的指令
    • Pragma: no-cache

  • Proxy-Authorization

    • 连接到代理的授权证书
    • Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

  • Range

    • 只请求实体的一部分，指定范围
    • Range: bytes=500-999

  • Referer

  • TE

    • 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息
    • TE: trailers,deflate;q=0.5

  • Upgrade

    • 向服务器指定某种传输协议以便服务器进行转换（如果支持）
    • Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

  • User-Agent

    • User-Agent的内容包含发出请求的用户信息
    • User-Agent: Mozilla/5.0 (Linux; X11)

  • Via

    • 通知中间网关或代理服务器地址，通信协议
    • Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

  • Warning

    • 关于消息实体的警告信息
    • Warn: 199 Miscellaneous warning

2.7.1.3. 响应头列表

  • Accept-Ranges

    • 表明服务器是否支持指定范围请求及哪种类型的分段请求
    • Accept-Ranges: bytes

  • Access-Control-Allow-Origin

    • 配置有权限访问资源的域
    • Access-Control-Allow-Origin: <origin>|*

  • Age

    • 从原始服务器到代理缓存形成的估算时间（以秒计，非负）
    • Age: 12

  • Allow

    • 对某网络资源的有效的请求行为，不允许则返回405
    • Allow: GET, HEAD

  • Cache-Control

    • 告诉所有的缓存机制是否可以缓存及哪种类型
    • Cache-Control: no-cache

  • Content-Encoding

    • web服务器支持的返回内容压缩编码类型。
    • Content-Encoding: gzip

  • Content-Language

    • 响应体的语言
    • Content-Language: en,zh

  • Content-Length

    • 响应体的长度
    • Content-Length: 348

  • Content-Location

    • 请求资源可替代的备用的另一地址
    • Content-Location: /index.htm

  • Content-MD5

    • 返回资源的MD5校验值
    • Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

  • Content-Range

    • 在整个返回体中本部分的字节位置
    • Content-Range: bytes 21010-47021/47022

  • Content-Type

    • 返回内容的MIME类型
    • Content-Type: text/html; charset=utf-8

  • Date

    • 原始服务器消息发出的时间
    • Date: Tue, 15 Nov 2010 08:12:31 GMT

  • ETag

    • 请求变量的实体标签的当前值
    • ETag: "737060cd8c284d8af7ad3082f209582d"

  • Expires

    • 响应过期的日期和时间
    • Expires: Thu, 01 Dec 2010 16:00:00 GMT

  • Last-Modified

    • 请求资源的最后修改时间
    • Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT

  • Location

  • Pragma

    • 包括实现特定的指令，它可应用到响应链上的任何接收方
    • Pragma: no-cache

  • Proxy-Authenticate

    • 它指出认证方案和可应用到代理的该URL上的参数
    • Proxy-Authenticate: Basic

  • Refresh

    • 应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）
    • Refresh: 5; url=http://www.zcmhi.com/archives/94.html

  • Retry-After

    • 如果实体暂时不可取，通知客户端在指定时间之后再次尝试
    • Retry-After: 120

  • Server

    • web服务器软件名称
    • Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)

  • Set-Cookie

    • 设置Http Cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1

  • Strict-Transport-Security

    • 设置浏览器强制使用HTTPS访问
    • max-age: x秒的时间内 访问对应域名都使用HTTPS请求
    • includeSubDomains: 网站的子域名也启用规则
    • Strict-Transport-Security: max-age=1000; includeSubDomains

  • Trailer

    • 指出头域在分块传输编码的尾部存在 Trailer: Max-Forwards

  • Transfer-Encoding

    • 文件传输编码
    • Transfer-Encoding:chunked

  • Vary

    • 告诉下游代理是使用缓存响应还是从原始服务器请求
    • Vary: *

  • Via

    • 告知代理客户端响应是通过哪里发送的
    • Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

  • Warning

    • 警告实体可能存在的问题
    • Warning: 199 Miscellaneous warning

  • WWW-Authenticate

    • 表明客户端请求实体应该使用的授权方案
    • WWW-Authenticate: Basic

  • X-Content-Type-Options

    • 配置禁止MIME类型嗅探
    • X-Content-Type-Options: nosniff

  • X-Frame-Options

    • 配置页面是否能出现在 <frame>, <iframe>, <embed>, <object> 等标签中，防止点击劫持
    • X-Frame-Options: deny

  • X-XSS-Protection

    • 配置XSS防护机制
    • X-XSS-Protection: 1; mode=block

2.7.1.4. HTTP状态返回代码 1xx（临时响应）

表示临时响应并需要请求者继续执行操作的状态代码。

Code代码说明
100继续服务器返回此代码表示已收到请求的第一部分，正在等待其余部分
101切换协议请求者已要求服务器切换协议，服务器已确认并准备切换

2.7.1.5. HTTP状态返回代码 2xx （成功）

表示成功处理了请求的状态代码。

Code代码说明
200成功服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页
201已创建请求成功并且服务器创建了新的资源
202已接受服务器已接受请求，但尚未处理
203非授权信息服务器已成功处理了请求，但返回的信息可能来自另一来源
204无内容服务器成功处理了请求，但没有返回任何内容
205重置内容m服务器成功处理了请求，但没有返回任何内容
206部分内容服务器成功处理了部分GET请求

2.7.1.6. HTTP状态返回代码 3xx （重定向）

表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

Code代码说明
300多种选择针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301永久移动请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302临时移动服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303查看其他位置请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304未修改自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305使用代理请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。
307临时重定向服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

2.7.1.7. HTTP状态返回代码 4xx（请求错误）

这些状态代码表示请求可能出错，妨碍了服务器的处理。

Code代码说明
400错误请求服务器不理解请求的语法。
401未授权请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。
403禁止服务器拒绝请求。
404未找到服务器找不到请求的网页。
405方法禁用禁用请求中指定的方法。
406不接受无法使用请求的内容特性响应请求的网页。
407需要代理授权此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408请求超时服务器等候请求时发生超时。
409冲突服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410已删除如果请求的资源已永久删除，服务器就会返回此响应。
411需要有效长度服务器不接受不含有效内容长度标头字段的请求。
412未满足前提条件服务器未满足请求者在请求中设置的其中一个前提条件。
413请求实体过大服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414请求的 URI 过长请求的 URI（通常为网址）过长，服务器无法处理。
415不支持的媒体类型请求的格式不受请求页面的支持。
416请求范围不符合要求如果页面无法提供请求的范围，则服务器会返回此状态代码。
417未满足期望值服务器未满足"期望"请求标头字段的要求。

2.7.1.8. HTTP状态返回代码 5xx（服务器错误）

这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

Code代码说明
500服务器内部错误服务器遇到错误，无法完成请求。
501尚未实施服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码。
502错误网关服务器作为网关或代理，从上游服务器收到无效响应。
503服务不可用服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504网关超时服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505HTTP 版本不受支持服务器不支持请求中所用的 HTTP 协议版本。

2.7.2. HTTP 版本

2.7.2.1. HHTTP

HTTP 是基于 TCP/IP 协议的应用层协议，主要规定了客户端和服务器之间的通信格式，默认使用80端口。

2.7.2.2. HTTP 0.9

HTTP 0.9最早在1991年发布，仅支持GET命令，请求格式只有简单的 GET /url ，服务端仅响应HTML，响应完毕后关闭TCP连接。

2.7.2.3. HTTP 1.0

1996年5月，HTTP/1.0 版本发布，丰富了传输的格式和内容，还引入了POST、HEAD两个动词。从1.0开始，必须在尾部添加协议版本。在1.0中，也引入了状态码(status code)、多字符集支持、多部分发送(multi-part type)、权限(authorization)、缓存(cache)、内容编码(content encoding)等内容。

HTTP 1.0 版的主要缺点是，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢(slow start)，所以，HTTP 1.0版本的性能比较差。

2.7.2.4. HTTP 1.1

1997年1月，HTTP/1.1 版本发布，进一步完善了 HTTP 协议。1.1版本主要是引入了持久连接、管道机制、Content-Length、分块传输编码等内容。管道机制即在同一个TCP连接里面，客户端可以同时发送多个请求，这样就改进了HTTP协议的效率。PUT、PATCH、HEAD、 OPTIONS、DELETE等动词方法也是在HTTP 1.1版本引入的。另外1.1版本新增了Host字段，用于指定服务器的域名，这也是后来虚拟主机得以发展的基础。

虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。如果有一个请求很慢，就会阻塞后面的请求。

2.7.2.5. SPDY

2009年，谷歌公开了自行研发的 SPDY 协议，用于解决 HTTP/1.1 效率不高的问题，而后被当做 HTTP/2 的基础。

2.7.2.6. HTTP/2

2015年，HTTP/2 发布，HTTP/2是一个二进制协议，头信息和数据体都是二进制，统称为帧(frame)，帧分为头信息帧和数据帧。HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序回应。

2.7.3. HTTPS

2.7.3.1. 简介

HTTPS (HyperText Transfer Protocol over Secure Socket Layer)可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL。

2.7.3.2. 交互

2.7.3.2.1. 证书验证阶段

  • 浏览器发起 HTTPS 请求

  • 服务端返回 HTTPS 证书

    • 其中证书包含：

      • 颁发机构信息
      • 公钥
      • 公司信息
      • 域名
      • 有效期
      • 指纹
  • 客户端验证证书是否合法，如果不合法则提示告警

2.7.3.2.2. 数据传输阶段

  • 当证书验证合法后，在本地生成随机数
  • 通过公钥加密随机数，并把加密后的随机数传输到服务端
  • 服务端通过私钥对随机数进行解密
  • 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

2.7.3.3. CA

CA (Certificate Authority) 是颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

2.7.4. Cookie

2.7.4.1. 简介

Cookie（复数形态Cookies），类型为「小型文本文件」，指某些网站为了辨别用户身份而储存在用户本地终端上的数据。

2.7.4.2. 属性

2.7.4.2.1. name

cookie的名称。

2.7.4.2.2. value

cookie的值。

2.7.4.2.3. expires

当 Expires 属性缺省时，表示是会话性 Cookie，在用户关闭浏览器时失效。

2.7.4.2.4. max-age

max-age 可以为正数、负数、0。如果 max-age 属性为正数时，浏览器会将其持久化，当 max-age 属性为负数，则表示该 Cookie 只是一个会话性 Cookie。当 max-age 为 0 时，则会立即删除这个 Cookie。Expires 和 max-age 都存在的条件下，max-age 优先级更高。

2.7.4.2.5. domain

指定Cookie的域名，默认是当前域名。domain设置时可以设置为自身及其父域，子域可以访问父域的Cookie，反之不能。

2.7.4.2.6. path

指定一个 URL 路径，这个路径必须出现在要请求的资源的路径中才可以发送对应的 Cookie。

2.7.4.2.7. secure

只能通过 HTTPS 传输。

2.7.4.2.8. httponly

限制Cookie仅在HTTP传输过程中被读取，一定程度上防御XSS攻击。

2.7.4.2.9. SameSite

SameSite 支持 Strict / Lax / None 三种值。Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。Lax 允许部分第三方请求携带 Cookie，主要是链接、预加载、GET 表单三种情况。Cookie 的 SameSite 属性为 None ，且设置了 Secure 时，无论是否跨站都会发送 Cookie。

2.7.5. WebDAV

2.7.5.1. 简介

WebDAV （Web-based Distributed Authoring and Versioning） 一种基于 HTTP 1.1协议的通信协议。它扩展了HTTP 1.1，在GET、POST、HEAD等几个HTTP标准方法以外添加了一些新的方法，使应用程序可对Web Server直接读写，并支持写文件锁定、解锁，以及版本控制等功能。

支持的方法具体为：

  • OPTIONS

    • 获取服务器的支持

  • GET / PUT / POST / DELETE

    • 资源操作

  • TRACE

    • 跟踪服务器
  • HEAD

  • MKCOL

    • 创建集合
  • PROPFIND / PROPPATCH
  • COPY / MOVE
  • LOCK / UNLOCK

2.7.5.2. 相关CVE

2.7.6. 参考链接

2.7.6.1. RFC

  • RFC 3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)
  • RFC 3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
  • RFC 3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol
  • RFC 4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources
  • RFC 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
  • RFC 5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH
  • RFC 5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)

2.7.6.2. Blog

2.8. 邮件协议族

2.8.1. 简介

2.8.1.1. SMTP

SMTP (Simple Mail Transfer Protocol) 是一种电子邮件传输的协议，是一组用于从源地址到目的地址传输邮件的规范。不启用SSL时端口号为25，启用SSL时端口号多为465或994。

2.8.1.2. POP3

POP3 (Post Office Protocol 3) 用于支持使用客户端远程管理在服务器上的电子邮件。不启用SSL时端口号为110，启用SSL时端口号多为995。

2.8.1.3. IMAP

IMAP (Internet Mail Access Protocol)，即交互式邮件存取协议，它是跟POP3类似邮件访问标准协议之一。不同的是，开启了IMAP后，您在电子邮件客户端收取的邮件仍然保留在服务器上，同时在客户端上的操作都会反馈到服务器上，如：删除邮件，标记已读等，服务器上的邮件也会做相应的动作。不启用SSL时端口号为143，启用SSL时端口号多为993。

2.8.2. 防护策略

2.8.2.1. SPF

发件人策略框架 (Sender Policy Framework, SPF) 是一套电子邮件认证机制，用于确认电子邮件是否由网域授权的邮件服务器寄出，防止有人伪冒身份网络钓鱼或寄出垃圾邮件。SPF允许管理员设定一个DNS TXT记录或SPF记录设定发送邮件服务器的IP范围，如有任何邮件并非从上述指明授权的IP地址寄出，则很可能该邮件并非确实由真正的寄件者寄出。

2.8.2.2. DKIM

域名密钥识别邮件 (DomainKeys Identified Mail, DKIM) 是一种检测电子邮件发件人地址伪造的方法。发送方会在邮件的头中插入DKIM-Signature，收件方通过查询DNS记录中的公钥来验证发件人的信息。

2.8.2.3. DMARC

基于网域的消息认证、报告和一致性 (Domain-based Message Authentication, Reporting and Conformance, DMARC) 是电子邮件身份验证协议，用于解决在邮件栏中显示的域名和验证的域名不一致的问题。要通过 DMARC 检查，必须通过 SPF 或/和 DKIM 的身份验证，且需要标头地址中的域名必须与经过身份验证的域名一致。

2.8.3. 参考链接

2.8.3.1. RFC

2.8.3.2. 相关文档

2.8.3.3. 研究文章

2.9. SSL/TLS

2.9.1. 简介

SSL全称是Secure Sockets Layer，安全套接字层，它是由网景公司(Netscape)在1994年时设计，主要用于Web的安全传输协议，目的是为网络通信提供机密性、认证性及数据完整性保障。如今，SSL已经成为互联网保密通信的工业标准。

SSL最初的几个版本(SSL 1.0、SSL2.0、SSL 3.0)由网景公司设计和维护，从3.1版本开始，SSL协议由因特网工程任务小组(IETF)正式接管，并更名为TLS(Transport Layer Security)，发展至今已有TLS 1.0、TLS1.1、TLS1.2、TLS1.3这几个版本。

如TLS名字所说，SSL/TLS协议仅保障传输层安全。同时，由于协议自身特性(数字证书机制)，SSL/TLS不能被用于保护多跳(multi-hop)端到端通信，而只能保护点到点通信。

SSL/TLS协议能够提供的安全目标主要包括如下几个：

  • 认证性

    • 借助数字证书认证服务端端和客户端身份，防止身份伪造

  • 机密性

    • 借助加密防止第三方窃听

  • 完整性

    • 借助消息认证码(MAC)保障数据完整性，防止消息篡改

  • 重放保护

    • 通过使用隐式序列号防止重放攻击

为了实现这些安全目标，SSL/TLS协议被设计为一个两阶段协议，分为握手阶段和应用阶段：

握手阶段也称协商阶段，在这一阶段，客户端和服务端端会认证对方身份(依赖于PKI体系，利用数字证书进行身份认证)，并协商通信中使用的安全参数、密码套件以及MasterSecret。后续通信使用的所有密钥都是通过MasterSecret生成。 在握手阶段完成后，进入应用阶段。在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信。

2.9.2. 协议

TLS 包含几个子协议，比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。

2.9.2.1. 记录协议

记录协议(Record Protocol)规定了 TLS 收发数据的基本单位记录(record)。

2.9.2.2. 警报协议

警报协议(Alert Protocol)用于提示协议交互过程出现错误。

2.9.2.3. 握手协议

握手协议(Handshake Protocol)是 TLS 里最复杂的子协议，在握手过程中协商 TLS 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。

2.9.2.4. 变更密码规范协议

变更密码规范协议(Change Cipher Spec Protocol)是一个“通知”，告诉对方，后续的数据都将使用加密保护。

2.9.3. 交互过程

2.9.3.1. Client Hello

Client Hello 由客户端发送，内容包括客户端的一个Unix时间戳(GMT Unix Time)、一些随机的字节(Random Bytes)，还包括了客户端接受的算法类型(Cipher Suites)。

2.9.3.2. Server Hello

Server Hello 由服务端发送，内容包括服务端支持的算法类型、GMT Unix Time以及Random Bytes。

2.9.3.3. Certificate

由服务端或者客户端发送，发送方会会将自己的数字证书发送给接收方，由接收方进行证书验证，如果不通过的话，接收方会中断握手的过程。一般跟在Client / Server Hello报文之后。

2.9.3.4. Server Key Exchange

由服务端发送，将自己的公钥参数传输给了客户端，一般也和Server Hello与Certificate在一个TCP报文中。

<

以上是关于禁欲28天！一宅男居然肝出如此详细Web安全学习笔记，学妹看完直接抽搐了！（第二弹）的主要内容，如果未能解决你的问题，请参考以下文章

想自学软件测试？字节大佬熬夜7天肝出这份超详细学习指南！

想自学软件测试？字节大佬熬夜7天肝出这份超详细学习指南！

熬夜肝出 3w 字测试开发学习路线

设计模式之总结篇

22岁精神小伙居然利用 Linux 内核漏洞实现 Docker 逃逸！！

22岁精神小伙居然利用 Linux 内核漏洞实现 Docker 逃逸