浏览器安全（下）
原创
上篇文章从web页面安全的角度分析了浏览器的同源策略，XSS跨站脚本攻击和CSRF跨站请求伪造的攻防方式，本节课将从浏览器稳定性和网络安全的视角分析浏览器的安全
浏览器进程安全
在浏览器渲染（进程视角）这篇文章中，分析了浏览器架构演进过程及原因，主要是考虑的原因是从浏览器的稳定性出发，
在架构升级过程中浏览器的安全漏洞直接影响着操作系统的安全，所以浏览器的安全至关重要。
与XSS，CSRF攻击的区别
- XSS/CSRF攻击是利用客户端脚本或服务器漏洞，获取并利用用户在站点的身份信息，进行模拟用户身份，盗取用户信息等恶意行为，无法对操作客户端操作系统进行攻击
- 浏览器的漏洞是可以入侵到浏览器进程内部，穿透浏览器，在客户端操作系统上安装恶意软件，监听用户信息输入，盗取用户磁盘文件信息
通过上图可以看出来，黑客主要是从渲染进程做为攻击入口，利用操作系统开放给浏览器系统调用，对操作系统发起攻击，接下来看一下浏览器是如何利用安全沙箱技术保护操作系统安全
安全沙箱
在浏览器的多进程架构中利用了进程隔离和引入了安全沙箱技术，浏览器的功能主要是由浏览器内核和渲染内核完成，内核工作如下：
浏览器内核：对进程的管理，与操作系统的交互，获取用户的输入及图像输出（浏览器的主进程、网络进程、GPU进程、GUI、文件等）
渲染内核：解析执行脚本，合成图像，与浏览器内核交互（DOM解析、CSS解析、脚本执行、合成图像）
安全沙箱又是什么呢？
渲染进程是攻击的入口，如果渲染进程存在系统级别的漏洞，有可能通过渲染进程的控制权限获得操作系统的控制权限。如果一个站点发起了恶意程序下载，网络进程下载后并不执行，只有渲染进程对文件或程序进行执行时（解析dom、css，脚本执行等）才会真正的发起攻击，所以渲染进程和操作系统之间必须建立安全的隔离机制，黑客获取渲染进程的权限无法获取之外的任何权限，这就是安全沙箱的作用。
接下来看浏览器是如何设计安全沙箱，及带来的影响：
安全沙箱最小的保护单位是进程，浏览器将渲染进程封装在安全沙箱内，使得渲染进程不能直接操作缓存文件数据、网络数据、用户交互等，这些操作都会直接或间接的调用了操作系统的API，浏览器将其封装在浏览器内核中。
持久数据读写
渲染进程有对cookie及文件上传下载需求，而安全沙箱使渲染进程无法直接访问文件系统，在浏览器多进程架构模型中浏览器将读写文件的操作封装在浏览器内核中，通过进程间通信将结果发送给渲染进程，具体表现如下：
- 浏览器内核负责对网络下载的文件的缓存及读取
- 浏览器对cookie数据的统一管理
网络读写
安全沙箱的保护，渲染进程不能直接访问网络，需要通过浏览器内核请求下载：
- 浏览器内核检查渲染进程请求url权限（如xhr、fetch的跨站请求）
- 检查通过浏览器内核通过网络进程下载数据，通过IPC将数据传递给渲染进程
用户交互
浏览器的GUI是操作系统提供给应用程序界面(窗口句柄)的一个实现，浏览器应用程序可以在窗口句柄绘制，接受用户输入等消息。操作系统利用窗口句柄将用户输入和UI应用程序建立数据交互链接。
由于安全沙箱，窗口句柄不能直接被渲染进程访问，所以渲染进程需要如下改进：
- 由浏览器内核负责位图输出显示（渲染进程只负责渲染合成位图然后发送给浏览器内核）
- 由操作系统将用户输入传递给浏览器内核（限制渲染进程直接与操作系统交互，防止监控用户输入的能力），浏览器内核根据当前界面状态判断如何调度事件
- 焦点位于页面，则浏览器内核将输入事件转发给渲染进程
- 焦点位于地址栏菜单栏等，则输入事件会被浏览器主进程处理
站点隔离
浏览器早期多进程架构中，是按照标签页来划分渲染进程，如果一个标签页嵌套了很多站点的iframe，按照标签页划分渲染进程会导致页面内的iframe共用渲染进程数据，有可能受到XSS的攻击，嵌入恶意站点的iframe，盗取当前站点用户数据。
在浏览器渲染进程视角那篇文章里，讲了什么是同一站点（协议相同、根域名相同），站点隔离就是浏览器将同一站点分配在同一渲染进程中。之所以使用站点隔离的原因如下：
- 防止进程对操作系统的影响：处理器的架构使操作系统有两个A级漏洞（幽灵、熔毁），黑客可以通过漏洞入侵到进程内部，如果不存在安全沙箱的保护下，则可以通过进程对操作系统发起攻击
- 防止进程之间相互数据泄露：防止页面内嵌入恶意站点iframe读取当前站点渲染进程的数据，所以将不同的站点分配在不同进程中，做到内容数据隔离，互不影响。
上诉分析了渲染进程的重要地位，从安全角度考虑浏览器多进程架构把渲染进程与操作系统分隔，将持久数据的读写、网络读写、用户交互的操作封装在浏览器内核中，由浏览器内核与操作系统交互，把不同的站点分配在独立的渲染进程中，保证不同站点互不影响。
接下来从浏览器网络资源请求角度分析安全性
浏览器网路安全
在客户端和服务器之间，数据会经过用户电脑、wifi路由器、运营商机房和目标服务器，由于HTTP的明文传输，在每个环节都有可能被黑客窃取、伪造和篡改。于是便有了https，在http协议中加入了安全层，这就是https
https的几种实现方式：
对称加密
加解密使用相同的密钥，客户端在传输数据前需要与服务端协商加密方式，获得加解密的密钥
- 安全层协商过程：
- 客户端传递可用加密方法和客户端随机数
- 服务端接确认加密方法，返回加密方法和服务端随机数
- 加密传输：
- 客户端和服务端利用随机串合成密钥，使用密钥加密数据发送
- 服务端也利用相同的方法合成密钥解密数据
优势：加解密效率高，速度快
劣势：传输随机数、加密方法是明文的，合成密钥的算法是公开的，所以黑客依然可以截获破解
非对称加密
与对称加密的不同之处是，非对称加密由两把密钥，数据只能使用一把密钥加密，另外一把密钥解密，把客户端可以获取到的密钥称为公钥，保存在服务端的密钥称为私钥，私钥不公开，公钥是公开的
- 安全层协商过程：
- 客户端发送加密列表给服务器
- 服务器确认加密列表并派发公钥
- 传输数据：
- 客户端使用公钥加密数据
- 服务端使用私钥解密数据
优势：安全级别比对称加密要高，在客户端向服务端发送数据阶段即使黑客截获数据也无法通过公钥解密
劣势：
- 加密要传输的大数据效率很低，影响到加解密速度。
- 服务端发送给客户端使用私钥加密，客户端使用公钥解密，但是公钥的传输是明文的，黑客依然可以获取服务端返回的数据
对称与非对称加密结合
在传输数据阶段依然使用对称加密保证数据加密效率，但加密的密钥是使用非对称加密来传输
- 安全层协商阶段：
- 客户端向服务端发送对称加密套件列表、非对称加密套件列表、客户端随机数
- 服务端确认对称和非对称加密方法，生成服务端随机数，并派发公钥一并返回
- 客户端保存公钥，生成新的随机数并用公钥加密，发送给服务端
- 服务端接收后使用私钥解出客户端新的随机数，并返回确认
- 传输数据阶段：
- 客户端利用三组随机数合成密钥，加密传输数据
- 服务端同样利用三组随机数解密数据
优势：解决了大数据非对加解密效率的问题，也解决了密钥在传输过程中被破解的问题
劣势：客户端无法证明服务端可靠。公钥和私钥都依赖服务端，如果黑客使用DNS劫持站点，将IP指向重定向到黑客服务器，那将黑客完全可以模拟一整套的公私钥，对于客户端来说并不知道是服务器
数字证书验证
数字证书的主要作用是验证服务端可信，携带服务器的公钥给客户端。它是由第三方权威机构（CA），由CA向服务器颁发合法证书，服务端把数字证书发送给客户端，客户端进行验证服务端是否可信
使用数字证书验证的流程：
- 申请证书阶段：
- 服务端准备信息：准备公私钥，将公钥、公司、站点等信息提交给CA申请证书
- CA验证服务器派发证书：CA通过线上/线下验证服务器提交信息，验证通过则CA向服务器签发认证数字证书（包括CA的签名，CA的信息、及服务端提交的信息，有效时间，证书序列号等）
- 安全层协商阶段：
- 客户端发送对称加密列表、非对称加密列表、客户端随机数
- 服务端确认对称、非对称加密套件，一并返回服务端随机数、数字证书
- 客户端验证数字证书
- 客户端使用内置的CA验证数字证书
- 证书验证通过，使用证书中携带的公钥+客户端生成的随机数发送给服务端
- 服务端接收消息使用私钥解出随机数，返回确认信息
- 传输数据阶段（同对称和非对称加密混合方式）
以上通过引入了第三方权威机构为服务器签发数字证书，服务端利用数字证书的方式传递公钥，操作系统通过内置的CA根证书验证证书，通过公钥非对称加密的方式生成加密密钥，通过对称方式传递数据，这就是最终https的方案。
思考题：如果根证书被篡改了呢？
（完）
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。