浏览器原理之四：网络、安全

禾十米
495 阅读12分钟

转行前端看的第一本书就是《图解 HTTP》，平时刷网站地址里都有 HTTP。但不知道 HTTP 还分为 HTTP1、HTTP2、HTTP3。以前，经常听到有人受钓鱼网站坑害，不知道背后原来是 CSRF 攻击，什么同源策略、安全沙箱就更看不懂了。浏览器原理第四篇，带你深入学习浏览器网络和安全。

29. HTTP/1

HTTP/0.9

1991 年提出 HTTP/0.9，主要用于学术交流，完成网络之间传递 HTML 超文本内容。完整流程如下：

  1. HTTP 基于 TCP 协议，客户端根据 IP、端口与服务器建立 TCP 连接。
  2. 建立连接后，发送 GET 请求行信息，如 GET/index.html。
  3. 服务器接收请求信息之后，读取对应 HTML 文件，将数据已 ASCII 字符流返回给客户端。
  4. HTML 文档传输完成后，断开连接。

HTTP/0.9 实现特点：

  • 只有请求行，没有 HTTP 请求头、请求体。
  • 只返回数据，没有返回头。
  • 返回文件内容以 ASSII 字符流传输。

HTTP/1.0

1994 年出现拨号上网，网景推出 Netscape 网页浏览器。万维网的发展推动了 HTTP1.0 的诞生。

HTTP1.0 核心诉求：支持多种类型的文件下载。

新增特性：

  • 为支持多种类型文件，采用请求头和响应头协商。
  • 引入状态码，返回服务器处理状态。
  • 提供 cache 机制（响应头 cache-control），缓存下载过的数据减轻服务器压力。
  • 请求头中增加 user-agent，方便服务器统计客户端基本信息。
accept: text/html
accept-encoding: gzip, deflate, br
accept-charset: ISO-8859-1,utf-8
accept-language: zh-CN,zh

content-encoding: br
content-type: text/html; charset=UTF-8

HTTP/1.1

  • 增加持久连接（默认开启），在一个 TCP 连接上可以传输多个 HTTP 请求。
  • 管线化技术（已放弃），解决队头阻塞问题。即 将多个 HTTP 请求整批提交给服务器，服务器依次返回响应数据。
  • 增加 host 请求头，支持虚拟主机（一台物理主机绑定多个虚拟主机，共用 IP，但每个虚拟主机有自己单独的域名）。
  • 引入 Chunk transfer 机制，解决动态文件传输问题。
  • 引入客户端 cookie 机制和安全机制。

30. HTTP/2

2015 年正式发布 HTTP/2.0 协议规范。

HTTP/1.1 的主要问题

带宽利用率低，主要原因如下：

  • TCP 慢启动（为减少网络拥塞的一种策略）。
  • 同时开启多条 TCP 连接，相互之间会竞争固定带宽。
  • 队头阻塞问题。

HTTP/2 新特性

多路复用

一个域名值使用一个 TCP 长连接，资源并行请求消除队头阻塞问题。HTTP/2 添加了一个二进制分帧层实现多路复用技术。。

具体请求和接收流程：

  1. 浏览器准备好请求数据。
  2. 请求数据经过二进制分帧层处理，转换为一个个带有请求 ID 的帧，通过协议栈将这些帧发送给服务器。
  3. 服务器接收到所有帧之后，将 ID 相同的帧合并为一条完整的请求信息。（服务器可以暂停之前的请求，优先处理关键资源请求）
  4. 服务器处理请求，将处理的响应行、响应头、响应体分别发送至二进制分帧层。
  5. 二进制分帧层将响应数据转换为一个个带有响应 ID 的帧，经协议栈发给浏览器。
  6. 浏览器接收到响应帧后，根据 ID 编号将帧的数据提交给对应的请求。

其他特性

  • 可设置请求优先级，如二进制帧中 PRIORITY 类型 就是用于指定或重新指定引用资源优先级。
  • 服务器推送。
  • 头部压缩。

31. HTTP/3

HTTP/2 的主要问题

  • TCP 的队头阻塞。HTTP/2 只解决了应用层面的队头阻塞问题。在 TCP 传输过程中，由于网路故障和其他原因导致单个数据包丢失会阻塞该 TCP 连接的所有请求。
  • TCP 建立连接的延时。TCP 连接需要 1.5 个 RTT，HTTPS 的 TLS 连接需要 1-2 个 RTT，当浏览器和服务器物理距离较远时，连接延时明显。
  • TCP 协议僵化。TCP 涉及到很多中间设备，如路由器、防火墙、NAT、交换机等。这些中间设备依赖很少升级的软件，这些软件使用了大量 TCP 特性。TCP 协议是通过操作系统内核实现的，操作系统的更新迟滞。

HTTP/3 QUIC 协议

QUIC，Quick UDP Internet Connection，核心功能：

  • 基于 UDP 协议，实现类似 TCP 的流量控制、传输可靠性的功能。
  • 集成了 TLS 加密功能，实现了快速握手功能（将加密和握手结合在一起），减少 RTT。
  • 实现了在同一物理连接上拥有多个独立的逻辑数据流，解决 TCP 队头阻塞问题。

HTTP/3 的挑战：

  • 目前没有浏览器和服务器端提供对 HTTP/3 的完整支持。
  • 系统内核对 UDP 的优化远没有 TCP 的优化多。
  • 中间设备僵化，丢包率高。

32. 同源策略（页面安全）

同源策略限制

  1. DOM 层面：限制操作 DOM。
  2. 数据层面：限制读取 Cookie、IndexDB、LocalStorage 等数据。
  3. 网络层面：限制通过 XMLHttpRequest 将站点数据发给不同源的站点。

安全 vs 便利

  1. 页面中可以引用第三方资源，不过这也暴露了很多诸如 XSS 的安全问题，因此又在这种开放的基础之上引入了 CSP 来限制其自由程度。
  2. 使用 XMLHttpRequest 和 Fetch 都是无法直接进行跨域请求的，因此浏览器又在这种严格策略的基础之上引入了跨域资源共享策略，让其可以安全地进行跨域操作。
  3. 两个不同源的 DOM 是不能相互操纵的，因此，浏览器中又实现了跨文档消息机制，让其可以比较安全地通信。

33. XSS 跨站脚本攻击（页面安全）

恶意脚本危害

  • 窃取 Cookie 信息，在其他电脑模拟用户登录，操作用户账户。
  • 监听用户行为，如监听键盘时间获取用户输入的敏感信息（银行卡、账户密码等）。
  • 修改 DOM 伪造假的登录窗口，骗取用户输入用户名和密码等信息。
  • 在页面生成浮窗广告。

恶意脚本注入方式

  1. 存储型 XSS 攻击。（如 2015 年，喜马拉雅被爆出存储型 XSS 漏洞）
    1. 黑客利用站点漏洞将一段恶意 JS 代码提交网站数据库。
    2. 用户访问包含恶意 JS 脚本的页面。
    3. 用户浏览页面是，恶意脚本将用户信息等数据上传到恶意服务器。
  2. 反射型 XSS 攻击。
    1. 恶意脚本属于用户发送给网站请求中的一部分。如 http://localhost:3000/?xss=。
    2. 网站把恶意 JS 脚本返回给用户。
    3. 恶意 JS 脚本在用户页面被执行时，黑客利用该脚本做一些恶意操作。
  3. 基于 DOM 的 XSS 攻击。黑客通过手段将恶意脚本注入用户的页面中，比如网络劫持（wifi 路由器劫持，或本地恶意软件劫持）在页面传输过程中修改 HTML 内容。

阻止 XSS 攻击

  1. 服务器对输入脚本进行过滤或转码。
  2. CSP，Content Security Policy 内容安全策略，限制加载其他域下的资源，禁止向第三方域提交数据，禁止执行内联脚本和未授权的脚本，提供上报机制帮助发现 XSS 攻击。
  3. 服务器将 cookie 设置为 HttpOnly 标志，Cookie 就只能在 HTTP 请求过重中使用，防止 XSS 盗用 Cookie.
  4. 添加验证码防止脚本冒充用户提交危险操作，对不受信任的输入限制其长度。

CSP 启用方式：

  1. HTTP 头。 示例 content-security-policy: default-src https:;connect-src https:;...;
  2. 标签。 示例 参考：www.ruanyifeng.com/blog/2016/0…

34. CSRF 跨站请求伪造（页面安全）

利用用户的登录状态和服务器的漏洞来实施攻击。

CSRF 攻击条件

  1. 目标站点有 CSRF 漏洞。
  2. 用户登录目标站点，在浏览器保持站点登录状态。
  3. 用户打开第三方站点，如黑客站点、论坛。

CSRF 攻击方式

  1. 自动发起 GET 请求。（img src）
  2. 自动发起 POST 请求。（form 自动提交）
  3. 引诱用户点击。（图片下面的 a 标签）

防止 CSRF 攻击

  1. 利用 Cookie 的SameSite属性，第三方站点发送请求时禁止 Cookie 的发送。
  2. 服务器通过 HTTP 头的 Referer 和 Origin 属性，验证请求来源的站点。
  3. CSRF Token。服务器生成 Token 返回到页面中，从页面发起的请求可以带上 Token，但第三方站点发起的请求无法获取到 CSRF。

35. 安全沙箱 （系统安全）

现代浏览器架构，在多进程基础上，引入安全沙箱，隔离操作系统和渲染进程。因为渲染进程执行 DOM 解析、CSS 解析、网络图片解码等，最容易受到攻击。安全沙箱最小保护单位是进程。

渲染进程不能直接与操作系统交互，因此在浏览器内核中实现了持久存储、网络访问和用户交互等一系列与操作系统交互的功能，然后通过 IPC 和渲染进程进行交互。

窗口句柄

操作系统提供的一个界面，允许应用程序在该界面进行绘制。

为限制渲染进程监控到用户输入事件，渲染进程无法操作窗口句柄。

  • 渲染进程渲染出位图后需要发送到浏览器内核，浏览器内核将位图复制到屏幕上。
  • 用户输入事件由操作系统传递给浏览器内核，浏览器内核根据假面状态调度事件。（焦点在地址栏，输入事件在浏览器内核内部处理；焦点在页面，浏览器内核会将事件转发给渲染进程）

站点隔离

Chrome 将同一站点中相互关联的页面放到同一渲染进程中执行。

iframe 级的渲染进程避免恶意 iframe 利用操作系统的 A 级漏洞（Spectre/Meltdown）入侵到进程内部，攻击操作系统。

36. HTTPS（网络安全）

从协议栈层面看，HTTPS 在 HTTP 和 TCP 之间插入了一个安全层 SSL/TLS，所有经过安全层的数据都会被加密或者解密。

加密方式

对称加密

加密和解密使用相同的密钥。

实现过程：

  1. 浏览器向服务器发送 加密套件列表（支持的加密方法列表）和 client-randow。
  2. 服务器返回给浏览器 从列表中选中的加密套件 和 service-randow。
  3. 浏览器、服务器，使用相同的方法混合 两个 randow 生成密钥 master secret。
  4. 然后就可以使用密钥和加密套件进行数据的加密传输。

存在的问题：加密套件和随机数的传输都是明文，黑客可以拿到生成密钥来伪造或篡改数据。

❓❓ 疑问：第 3 步的 “相同方法”，具体指的什么呢？

非对称加密

存在 A\B 两把密钥，使用 A 加密，就只能用 B 解密。

实现过程：

  1. 浏览器向服务器发送 加密套件列表。
  2. 服务器返回给浏览器 从列表中选中的加密套件和用于浏览器加密的公钥。
  3. 双方确认后，浏览器就可以发送公钥加密数据给服务器。

存在的问题：

  1. 非对称加密的效率太低。
  2. 无法保证服务器发送给浏览器的数据安全。

混合加密

数据传输阶段使用对称加密，对称加密的密钥使用非对称加密传输。

实现过程：

  1. 浏览器向服务器发送 加密套件列表、非对称加密套件列表和 client-randow。
  2. 服务器返回给浏览器 从列表中选中的加密套件、非对称加密套件、service-randow 和公钥。
  3. 浏览器利用两个 randow 计算出 pre-master，利用公钥对 pre-master 加密，向服务器发送加密后的数据。
  4. 服务器使用私钥解密 pre-master 数据，返回确认消息。
  5. 浏览器、服务器 使用 client-random、service-random 和 pre-master 使用同一套方法生成密钥，用于对称加密传输。

❓❓ 疑问：黑客不能拿到第 1、2 步中的数据，生成 pre-master 吗？

数字证书

黑客可通过 DNS 劫持正常 IP 替换成黑客 IP，完成后面的混合加密过程。因此需要权威机构颁发的数字证书。

数字证书的作用：

  1. 向浏览器证明服务器的身份。
  2. 同时数字证书中包含了服务器公钥。

数字证书包含的信息：公钥、组织信息、CA 信息、有效时间、证书序号、CA 数字签名（使用 HASH 函数计算极客时间提交的明文信息并的出信息摘要，使用 CA 私钥对信息摘要加密后的密文就是 CA 颁发给极客时间的数字签名）。

操作系统中会内置信任的顶级 CA 的证书信息（包含公钥），如果这个 CA 链中没有找到浏览器内置的顶级的 CA，证书也会被判定非法。

系列文章

浏览器原理之一：大体看看

浏览器原理之三：页面

浏览器原理之二：JS、V8

avatar
文章
阅读
粉丝