浏览器原理

一、安全防范

1. XSS

跨站脚本攻击

1.1 攻击目的

多种可能的目的：

• 收集用户在站点上的 Cookie 信息、storage 信息等，对这些信息二次利用，对用户造成损害。
• 监听用户行为。比如通过 JavaScript 为添加监听键盘事件，窃取账户、密码等。
• 修改 DOM 伪造假的登录窗口，欺骗用户输入用户名、密码。
• 生成浮窗广告

1.2 实现原理

存储型 XSS 攻击

通过系统漏洞，将恶意脚本存储到数据库。再由数据库返回到页面，执行了恶意脚本。

反射型 XSS 攻击

未存储到数据库看，直接由服务端返回恶意脚本，并执行了恶意脚本。

比如：请求的参数中携带了恶意脚本，页面在呈现时，执行了脚本。

基于 DOM 的 XSS 攻击

基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。

黑客通过各种手段将恶意脚本注入用户的页面中，比如通过网络劫持在页面传输过程中修改 HTML 页面的内容，这种劫持类型很多，有通过 WiFi 路由器劫持的，有通过本地恶意软件来劫持的

它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。

1.3 根因

分为两类：

• 经历了服务端。参数不严谨，未校验参数
• 网络劫持

1.4 防范方法

1. 服务器对输入脚本进行过滤或转译。
2. 充分利用 CSP。禁止非法来源（站点）的脚本加载。
3. Cookie 配置 HttpOnly。即便恶意脚本被执行了，也无法获取 Cookie 信息。

2. CSRF

跨站请求伪造

2.1 攻击的目的

利用用户身份，假冒用户执行危险操作。比如：代替用户发起转账请求。

2.2 原理：

1. 用户在A站点登录
2. 用户点击第三方站点
3. 第三方站点自动向A站点发送伪造的请求（Get、Post）
4. 对用户早晨损失

2.3 根因

黑客利用用户的登录状态，通过第三方站点向目标站点伪造请求。由于服务端对请求的校验不严谨、或在客户端对 Cookie 的管理不严谨，对用户造成损失。

2.4 防范方法

1. 验证请求的来源

通常 CSRF 攻击来源于第三方站点，验证请求头中 origin、referer 是否与服务器地址一致。

2. Cookie 设置 SameSite

三方站点自动向A站点发送伪造的请求（Get、Post）时，会携带 Cookie 中的信息。所以，为 Cookie 添加 SameSite 限制，令第三方拿不到 Cookie，导致服务端校验不通过。

3. CSRF Token

正确的请求都携带CSRF Token，服务端校验CSRF Token，正确的 Token 才可以继续后续处理。因为CSRF Token存储在前端内存，第三方站点是无法拿到的。

3. 现代安全浏览器安全架构

3.1 单进程架构

Chrome 最初的架构是单进程架构，若是浏览器爆发安全漏洞，那么黑客很容易利用浏览器对操作系统发起攻击。单进程架构的特点：

• 不稳定。若浏览器中的某一功能出现异常，很可能会影响到整个浏览器。比如：页面卡死、浏览器崩溃等。
• 通过漏洞攻击操作系统。比如：缓冲区溢出漏洞，获取操作系统的 shell 发起攻击。

3.2 多进程架构

一段恶意程序，若不被执行，则不会产生危害。所以，将资源的下载过程与执行过程分开处理，更为妥善。

因此，现代安全架构采用多进程架构，化为为两个核心：

• 浏览器内核
  • 浏览器主进程
  • 网路进程
  • GPU 进程
• 渲染内核
  • 渲染进程

代码的执行主要发生在渲染进程，为渲染进程使用安全沙箱技术，将渲染进程与操作系统隔离，限制其对操作系统资源的访问和修改。

当渲染进程需要操作系统的读写功能时（如：读写本地文件、网络请求、调用 GPU 接口等），需要通过浏览器内核来实现，然后将访问的结果通过 IPC 转发给渲染进程。

安全沙箱对渲染进程的影响：

• 持久存储。对 Cookie、上传文件等，由浏览器内核通过 IPC 转发为渲染进程。
• 网络请求。由浏览器内核通过 IPC 转发为渲染进程。
• 用户交互。
  • 渲染进程生成位图，转发为浏览器内核，然后浏览器内核将位图复制到屏幕。
  • 用户输入事件，由浏览器内核通过 IPC 转发为渲染进程。

4. 数据安全

HTTP 本来一切安好，只是走歪路的人多了，才多了安全的 HTTPS。

4.1 HTTP

HTTP 最初设计的初衷仅是为了传输超文本文件，没有加密传输的需求，所以是明文传输。这就存在了中间人攻击的隐患，中间人可以窃取、篡改、伪造通信数据。

4.2 HTTPS

哪里有洞就堵哪里，给数据添加一层保护层。

对称加密

流程：

1. 协商密钥
   • 客户端、服务端协商对称密码
2. 通信
   • 使用对称密码加密通信

缺陷：

1. 密码协商过程为明文，依然可以被中间人获取，然后发生攻击行为。

非对称加密

流程：

1. 协商密钥
   • 服务端向客户端返回公钥
2. 通信
   • 服务端使用私钥加密即将发送到客户端的数据
   • 客户端使用公钥解密服务端返回的数据
   • 客户端使用公钥加密发送到服务端的数据
   • 服务端使用私钥解密客户端发送来的数据

缺陷：

1. 公钥在传输中可以被中间人获取，中间人通过公钥伪造数据
2. 非对称加密消耗资源大

对称加密+非对称加密

流程：

1. 协商密钥
   • 客户端向服务端发送随机数 A
   • 服务端返回随机数 B + 公钥
   • 客户端使用公钥加密随机 C，然后发送到服务端
   • 客户端、服务端，使用同一种算法，利用随机数 A、B、C 计算出通信的对称密钥 D
2. 通信
   • 使用密钥 D，作为对称加密的密钥进行通信

优点：

1. 中间人获取不到随机数 C，即无法获取密钥 D，则通信内容不会被窃取、伪造、监听
2. 握手时使用非对称加密；通信时使用对称加密。

缺陷：

1. 中间人可以假冒服务端，向客户端发送自己的公钥，导致通信内容不安全。
2. 客户端无法确认通信的对象是不是对的。

对称加密+数字证书

数字证书由第三方权威机构 CA 颁发给服务端，数字证书中包含：

• 服务端的基本信息（明文存储，包括组织、有效期、加密算法等）
• 服务端公钥、
• CA 的签名（一段 HASH 值）。

客户端拿到数字证书后，可以向 CA 验证服务端的身份。

流程：

1. 协商密钥
   • 客户端向服务端发送随机数 A
   • 服务端返回随机数 B + 公钥
   • 客户端验证数字证书
   • 客户端使用公钥加密随机 C，然后发送到服务端
   • 客户端、服务端，使用同一种算法，利用随机数 A、B、C 计算出通信的对称密钥 D
2. 通信
   • 使用密钥 D，作为对称加密的密钥进行通信