全部标签
写点什么
学习MySQL开源云计算行业资讯算法Python人工智能区块链Linux前端个人成长面试架构师编程企业动态新基建敏捷安全读书笔记高效工作团队管理创业活动专区生涯规划知识管理运维产品经理 查看更多

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

用户头像
Machine Gun
关注
发布于: 2021 年 05 月 28 日
禁欲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 状态



​

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  备注：infoq  即可免费获取全部资料

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

    发出请求的用户的 Email

    From: user@email.com

  • 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

    先前网页的地址，当前请求网页紧随其后,即来路

    Referer: http://www.zcmhi.com/archives/71.html

  • 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

    用来重定向接收方到非请求 URL 的位置来完成请求或标识新的资源

    Location: http://www.zcmhi.com/archives/94.html

  • 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（临时响应）

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

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

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

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

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

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

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

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

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

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 报文中。

2.9.3.5. Server Hello Done

服务端发送，一般也和 Server Hello、Certificate 和 Server Key Exchange 在一个 TCP 报文中。

2.9.3.6. Client Key Exchange

客户端发送，向服务端发送自己的公钥参数，与服务端协商密钥。

2.9.3.7. Change Cipher Spec

客户端或者服务端发送，紧跟着 Key Exchange 发送，代表自己生成了新的密钥，通知对方以后将更换密钥，使用新的密钥进行通信。

2.9.3.8. Encrypted Handshake Message

客户端或者服务端发送，紧跟着 Key Exchange 发送。进行测试，一方用自己的刚刚生成的密钥加密一段固定的消息发送给对方，如果密钥协商正确无误的话，对方可以正确解密。

2.9.3.9. New Session Ticket

服务端发送，表示发起会话，在一段时间之内(超时时间到来之前)，双方都以刚刚交换的密钥进行通信。从这以后，加密通信正式开始。

2.9.3.10. Application Data

使用密钥交换协议协商出来的密钥加密的应用层的数据。

2.9.3.11. Encrypted Alert

客户端或服务端发送，意味着加密通信因为某些原因需要中断，警告对方不要再发送敏感的数据。

2.9.4. 版本更新内容

2.9.4.1. TLS 1.3

  • 引入了 PSK 作为新的密钥协商机制

  • 支持 0-RTT 模式，以安全性降低为代价，在建立连接时节省了往返时间

  • ServerHello 之后的所有握手消息采取了加密操作，可见明文减少

  • 不再允许对加密报文进行压缩、不再允许双方发起重协商

  • DSA 证书不再允许在 TLS 1.3 中使用

  • 删除不安全的密码算法

    RSA 密钥传输 - 不支持前向安全性

    CBC 模式密码 - 易受 BEAST 和 Lucky 13 攻击

    RC4 流密码 - 在 HTTPS 中使用并不安全

    SHA-1 哈希函数 - 建议以 SHA-2 取而代之

    任意 Diffie-Hellman 组- CVE-2016-0701 漏洞

    输出密码 - 易受 FREAK 和 LogJam 攻击

2.9.5. 子协议

SSL/TLS 协议有一个高度模块化的架构，分为很多子协议，主要是：

  • Handshake 协议

    包括协商安全参数和密码套件、服务端身份认证(客户端身份认证可选)、密钥交换

  • ChangeCipherSpec 协议

    一条消息表明握手协议已经完成

  • Alert 协议

    对握手协议中一些异常的错误提醒，分为 fatal 和 warning 两个级别，fatal 类型的错误会直接中断 SSL 链接，而 warning 级别的错误 SSL 链接仍可继续，只是会给出错误警告

  • Record 协议

    包括对消息的分段、压缩、消息认证和完整性保护、加密等

2.9.6. 参考链接

2.9.6.1. RFC

2.9.6.2. Document

2.10. IPsec

2.10.1. 简介

IPsec（IP Security）是 IETF 制定的三层隧道加密协议，它为 Internet 上传输的数据提供了高质量的、可互操作的、基于密码学的安全保证。特定的通信方之间在 IP 层通过加密与数据源认证等方式，提供了以下的安全服务：

  • 数据机密性（Confidentiality）

    IPsec 发送方在通过网络传输包前对包进行加密。

  • 数据完整性（Data Integrity）

    IPsec 接收方对发送方发送来的包进行认证，以确保数据在传输过程中没有被篡改。

  • 数据来源认证（Data Authentication）

    IPsec 在接收端可以认证发送 IPsec 报文的发送端是否合法。

  • 防重放（Anti-Replay）

    IPsec 接收方可检测并拒绝接收过时或重复的报文。

2.10.2. 优点

IPsec 具有以下优点：

  • 支持 IKE（Internet Key Exchange，因特网密钥交换），可实现密钥的自动协商功能，减少了密钥协商的开销。可以通过 IKE 建立和维护 SA 的服务，简化了 IPsec 的使用和管理。

  • 所有使用 IP 协议进行数据传输的应用系统和服务都可以使用 IPsec，而不必对这些应用系统和服务本身做任何修改。

  • 对数据的加密是以数据包为单位的，而不是以整个数据流为单位，这不仅灵活而且有助于进一步提高 IP 数据包的安全性，可以有效防范网络攻击。

2.10.3. 构成

IPsec 由四部分内容构成：

  • 负责密钥管理的 Internet 密钥交换协议 IKE（Internet Key Exchange Protocol）

  • 负责将安全服务与使用该服务的通信流相联系的安全关联 SA（Security Associations）

  • 直接操作数据包的认证头协议 AH（IP Authentication Header）和安全载荷协议 ESP（IP Encapsulating Security Payload）

  • 若干用于加密和认证的算法

2.10.4. 安全联盟（Security Association，SA）

IPsec 在两个端点之间提供安全通信，端点被称为 IPsec 对等体。

SA 是 IPsec 的基础，也是 IPsec 的本质。SA 是通信对等体间对某些要素的约定，例如，使用哪种协议（AH、ESP 还是两者结合使用）、协议的封装模式（传输模式和隧道模式）、加密算法（DES、3DES 和 AES）、特定流中保护数据的共享密钥以及密钥的生存周期等。建立 SA 的方式有手工配置和 IKE 自动协商两种。

SA 是单向的，在两个对等体之间的双向通信，最少需要两个 SA 来分别对两个方向的数据流进行安全保护。同时，如果两个对等体希望同时使用 AH 和 ESP 来进行安全通信，则每个对等体都会针对每一种协议来构建一个独立的 SA。

SA 由一个三元组来唯一标识，这个三元组包括 SPI（Security Parameter Index，安全参数索引）、目的 IP 地址、安全协议号（AH 或 ESP）。

SPI 是用于唯一标识 SA 的一个 32 比特数值，它在 AH 和 ESP 头中传输。在手工配置 SA 时，需要手工指定 SPI 的取值。使用 IKE 协商产生 SA 时，SPI 将随机生成。

2.10.5. IKE

IKE（RFC2407，RFC2408、RFC2409）属于一种混合型协议，由 Internet 安全关联和密钥管理协议（ISAKMP）和两种密钥交换协议 OAKLEY 与 SKEME 组成。IKE 创建在由 ISAKMP 定义的框架上，沿用了 OAKLEY 的密钥交换模式以及 SKEME 的共享和密钥更新技术，还定义了它自己的两种密钥交换方式。

IKE 使用了两个阶段的 ISAKMP：

第一阶段，协商创建一个通信信道（IKE SA），并对该信道进行验证，为双方进一步的 IKE 通信提供机密性、消息完整性以及消息源验证服务； 第二阶段，使用已建立的 IKE SA 建立 IPsec SA（V2 中叫 Child SA）。

2.11. Wi-Fi

2.11.1. 简介

Wi-Fi 又称“无线热点”或“无线网络”，是 Wi-Fi 联盟的商标，一个基于 IEEE 802.11 标准的无线局域网技术。

2.11.2. 攻击

2.11.2.1. 暴力破解

WiFi 密码是基于预置的秘钥，可以通过抓取报文的方式在本地快速的批量进行密码爆破尝试。

2.11.2.2. 伪造热点

AP 可以动态的广播自己，客户也可以主动发送探针请求。可以伪造 AP 发送对探针请求的响应包，来让客户端错误的识别。

2.11.2.3. 秘钥重装攻击

该漏洞由 Vanhoef 发现。Wi-Fi 在握手时双方会更新秘钥，该攻击通过重放握手信息，令客户端重新安装相同的秘钥。

2.11.2.4. Dragonblood

最新版的 WPA3 标准在实现上存在一些问题，同样由 Vanhoef 发现。包含拒绝服务攻击、降级攻击、侧信道泄露等。

2.11.3. 参考链接

最后多说几句：

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

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

干货主要有：

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

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

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

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

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

⑥ 渗透测试工具大全

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

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

​

划线
评论
复制
发布于: 2021 年 05 月 28 日阅读数: 59
JavaPython网络安全Weblinux运维
用户头像

Machine Gun

关注

还未添加个人签名 2021.03.28 加入

需要获取网络安全/渗透测试学习资料工具的朋友可联系V：machinegunjoe666 免费索取

评论

发布
暂无评论
Copyright © 2021, Geekbang Technology Ltd. All rights reserved. 极客邦控股（北京）有限公司 | 京 ICP 备 16027448 号 - 5京公网安备京公网安备 11010502039052号
禁欲28天！一宅男居然肝出如此详细Web安全学习笔记，学妹看完直接抽搐了！（第二弹）