32 ｜ 同源策略：为什么XMLHttpRequest不能跨域请求资源–Web页面安全
浏览器安全分为三大块：Web页面安全、浏览器网络安全、浏览器系统安全。
同源策略
页面中最基础、最核心的安全策略：同源策略(same-origin policy) 如果两个URL协议相同、域名相同、端口相同，就称为这两个URL同源 同源策略就是说：相同源之间可以操作DOM、读取互相之间的Cookie、indexDB、locationStorage等页面数据以及网络层面共享。 也就解释了为什么同源策略限制了XMLHttpRequest讲站点数据发送给不同源站点。
安全和便利性权衡
安全性和便利性是互斥的，比如上面的同源策略限制了一个页面中资源都需要来自一个源，也就是该页面的所有HTML文件、CSS文件和JS文件等资源需要部署在一台服务器，但是如果资源过多，或者说我们基于业务会将不同资源部署在不同服务器上，因此为了解决同源策略导致的页面资源必须来自同一个源这个限制： 浏览器引入了CSP内容安全策略(Content Security policy),核心思想是让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能执行内敛JavaScrip代码，通过CSP可以大大减少XSS攻击。
同源策略还带来的一个问题是，如果我们用XMLHttpRequest去访问另一个源，会收到限制，这个时候又引入了CORS(跨域资源共享)策略。 使用该机制可以进行跨域访问控制，从而使得数据传输得以安全进行。
同源策略还有一个问题是不能互相操作DOM，同样也提供了安全的方法解决：使用跨文档消息机制：window.postMessage的JS接口来和不同源DOM进行通信。
33 | 跨站脚本攻击（XSS）：为什么Cookie中有HttpOnly属性？–Web页面安全
在同源策略的严格限制下，如果不能引入第三方资源，显然是不方便的，为此在安全和自由之间找的平衡，允许引入第三方资源，而随之而来的就是带来的页面安全问题，这些问题产生的过程，并进一步加深说明引入CSP机制的必要性。
XSS攻击
XSS全称为：Cross Site Scripting.为了与CSS区分开，所以叫CSS。 XSS攻击指的是劫持者往HTML文件或者DOM中注入恶意脚本，而使得用户在浏览页面时利用恶意脚本实施攻击的一种手段。 当然注入JavaScript恶意脚本时，由于允许引入了第三方资源，所以浏览器无法区分这些脚本是恶意引入还是正常页面内容，注入的恶意脚本拥有所有脚本的权限，于是可能产生：窃听用户Cookie、通过addEventListener监听用户行为、修改DOM、在页面生成浮窗广告等。
恶意脚本注入方式
那么这些恶意脚本是如何注入的呢？ 通常情况下，恶意注入脚本的方式有三种：存储型XSS攻击、反射性XSS攻击和基于DOM的XSS攻击。
存储型XSS攻击
这个指的是劫持者正常访问网站，然后利用网站的漏洞将一段恶意代码提交到网站数据库中，然后别人访问这个上传恶意脚本的页面的时候，一些信息被上传到恶意代码上传的服务器中。
反射型XSS攻击
反射型XSS攻击值得是用户将一段含有恶意代码的请求提交给Web服务器，Web服务器接收到请求再次返回给浏览器端。 常见的比如通过QQ群或者邮件渠道引导用户点击恶意链接。 需要与存储型XSS攻击区别的是：反射型XSS攻击中，Web服务器并不会存储攻击的请求内容。
基于DOM的XSS攻击
这个攻击比较有技术含量，需要劫持页面，将劫持的页面中修改HTML页面内容等。 这种劫持类型包括WIFI路由器劫持、本地恶意软件劫持等。共同点就是Web资源传输过程中或用户使用页面过程中劫持数据内容加以修改。
如何防止XSS攻击
存储型和反射型XSS攻击是服务端的安全漏洞，而基于DOM的XSS攻击是在浏览器端完成从，属于前端漏洞。
- 服务器要对输入脚本进行过滤和转码
- 充分利用CSP：限制加载其它源文件、禁止向第三方域提交数据、进行执行内敛脚本和未授权脚本等
- 使用HttpOnly属性：使用这个属性主要是为保护Cookie安全，通过服务器的HTTP响应头设置，设置之后无法通过JS来读取这段Cookie。
34 | CSRF攻击：陌生链接不要随便点
CSRF:Cross-site request forgery,跨站请求伪造。主要指侵入者引诱用户打开侵入者网站，利用用户的登录态来发起跨站请求。 简单来说就是，侵入者利用用户登录态通过第三方网站做一些坏事。
发起跨站请求伪造的方式有以下三种
自动发起get请求
在第三方网站利用用户登录态调用原网址请求转账等接口来模拟原网站请求。 当用户点击链接时，自动发起get请求。
自动发起POST请求
同Get请求一样，侵入者在自己的网站使用hidden的form，自动发起POST请求。
引诱用户点击链接
点击链接后，自动请求转账接口。
如何防止CSRF攻击
CSRF攻击首先服务器有漏洞、用户登录过已有站点、且在第三方站点发起请求。
充分利用好Cookie的SameSite属性
Cookie是浏览器和服务器直接维护登录状态的一个关键数据。 因此我们可以从第三方站点发送请求时禁止Cookie的发送，而Cookie中的SameSite属性就是解决这个问题的，使用SameSite可以有效减低CSRF的攻击。 使用方式是：在响应头上，通过set-cookie字段设置Cookie，带上SameSite选项。 通常有三个值：Strict、Lax和None。
- Strict最为严格，严格禁止第三方网站发起请求的时候携带Cookie。
- Lax:宽松一些，体现在Get请求会携带Cookie，POST和img、iframe等标签加载的URL，不会携带Cookie。
- None:任何情况都会携带Cookie。
验证请求的来源站点
那么，如何来验证其ing求是来自第三方站点呢？ 需要使用到HTTP请求头中的Referer和Origin属性。
- Referer记录HTTP请求的来源地址。
- 在服务器验证Referer并不是很可靠，于是加入了Origin属性。Origin属性只包含了域名信息。 服务器端会验证Origin，如果不包含Origin，再根据实际情况判断是否使用Referer。
CSRF Token
类似于JWT的token。
35 ｜ 安全沙箱：页面和系统之家的隔离墙
浏览器架构是如何影响操作系统安全的。
安全视角下的多进程架构
浏览器被划分为浏览器内核和渲染内核两个模块。 浏览器打开一个页面，先通过浏览器内核的网络进程下载资源，然后通过IPC将资源交给渲染进程，渲染进程进行一系列操作，最后生成图片之后，再将生成的图片返回给浏览器内核去展示这张图片。流程搞得如此复杂就是为了安全。
安全沙箱
主要是为了避免在渲染进程中被劫持着搞破坏，而在渲染进程和操作系统之家构建了一道墙，这样劫持者就获取不到渲染进程之外的权限了，我们把这个将渲染进程和操作系统隔离的强称为安全沙箱。 然后这个安全沙箱的作用啰嗦一点就是，你渲染进程有需要使用系统权限的，通过IPC给浏览器内核发布需求，然后相应的浏览器内核将操作结果返回给渲染进程使用，这样不管如何操作系统的权限就保护住了。
安全沙箱如何影响各个模块
首先，安全沙箱的最新保护单位是进程，也就是说如果安全沙箱应用在某个进程上，那么这个进程是没有系统权限的，比如读写本地文件、发起网络请求、调用GPU接口等，因此就可以分析渲染进程和浏览器内核的各自职责，不完全统计为：
- 渲染进程：HTML解析、CSS解析、JS执行、图片解码、布局、绘制、XML解析等
- 浏览器内核：Cookie存储、Cache存储、网络请求、文件读取、下载管理、SSl/TSL、浏览器窗口管理、GPU调用接口等。
回到小标题，影响各个模块主要是通过以下几个方面：
- 持久存储：以Cookie举例，渲染进程通过JS读取Cooki其实说，渲染进程先通过IPC机制向浏览器内核发送请求，然后浏览器内核处理完Cooki后再返回给渲染进程，网络文件缓存的读取也是这样操作。
- 网络访问：网络访问是，渲染进程通过IPC向浏览器内核发送请求，浏览器内核看到这是一个网络请求，就会先检查是否有权限请求该URL符合要求(是否跨域等、是否在HTTS中保护了HTTP请求)
- 用户交互：安全沙箱影响了非常重要的用户交互，一句话总结就是用户的鼠标和键盘操作时间都是通过浏览器内核实现的，同样大约是之前的流程。
站点隔离
简单说就是，之前的浏览器多进程架构的渲染进行是根据标签页划分的，这样存在的问题是如果一个页面通过iframe包含另一个页面，那么就会存在于一个渲染进程中，这样的漏洞会给劫持者有机可乘，于是乎，Chrome将标签级的渲染进程重构为了iframe级的渲染进程。这就是站点隔离。
36 | HTTPS：让数据传输更安全
HTTP保持着明文规定传输数据的特征，这个环节会存在传送的数据被窃取或者篡改。
HTTP协议栈中引入安全层
从HTTP协议来看，可以在HTTP与TCP层之间加入一个安全层，所有经过安全层的数据都会被加密或解密。 因此说HTTPS并非一个新的协议，只是加入了一个安全层，安全层的主要职责：对发起HTTP请求的数据进行加密操作和对接收到的HTTP内容进行解密操作。 接着，我们从这个安全层开始，一步一步实现由简单到复杂的HTTPS协议。
1. 使用对称加密
对称加密：加密和解密都使用的是相同的密钥. 存在的问题，加密套件是明文的(因为需要在传输的时候携带)，所以这种方式也是可以被拿到的。
2. 使用非对称加密
和对称加密只有一个密钥不同，非对称加密算法有 A、B 两把密钥，如果你用 A 密钥来加密，那么只能使用 B 密钥来解密；反过来，如果你要 B 密钥来加密，那么只能用 A 密钥来解密。 公开的为公钥，不公开自己用的叫私钥。 同样存在的问题是：非对称加密效率低且无法保证服务器发送给浏览器的数据是安全的。
3. 对称加密和非对称加密混合使用
在传输数据阶段依然使用对称加密，但是对称加密的密钥我们采用非对称加密来传输. 这样存在的一个问题是黑哥如果通过DNS劫持，将官网IP地址替换成黑哥网址，那就存在很大的风险了。 于是需要向浏览器证明"我就是我"，这个就是CA机构颁发的数字证书。
