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

1 同源策略：为什么XMLHttpRequest不能跨域请求资源？

同源策略主要表现在 DOM、web 数据和网络这三个层面。
浏览器让出的同源策略安全性：

页面中可以嵌入第三方资源：会引起XSS攻击，解决方案是浏览器引入了内容安全策略CSP，其核心思想是让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能够执行内联JavaScript代码。
跨域资源共享和跨文档消息机制

2 跨站脚本攻击（XSS）：为什么Cookie中有HttpOnly属性

Cross site scripting: XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。

反射型XSS攻击：恶意 JavaScript 脚本属于用户发送给网站请求中的一部分，随后网站又把恶意 JavaScript 脚本返回给用户。当恶意 JavaScript 脚本在用户页面中被执行时，黑客就可以利用该脚本做一些恶意操作。
基于DOM的XSS攻击：利用各种手段将恶意脚本注入用户的页面中，如WI-FI路由器劫持，本地恶意软件劫持，在web资源传输过程中修改web页面数据

服务器对传入的脚本进行过滤或转码
充分利用CSP
限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
禁止向第三方域提交数据，这样用户数据也不会外泄；
禁止执行内联脚本和未授权的脚本；
提供上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。
使用HttpOnly属性：用 HttpOnly 标记的 Cookie 只能使用在 HTTP 请求过程中，所以无法通过 JavaScript 来读取这段 Cookie

CSRF 英文全称是 Cross-site request forgery，所以又称为“跨站请求伪造”，是指黑客引诱用户打开黑客的网站，在黑客的网站中，利用用户的登录状态发起的跨站请求。

发起CSRF攻击的必要条件：目标站点有CSRF漏洞、用户登录过该站点并在浏览器上保持了登录状态、需要用户打开一个第三方站点

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

验证请求来源的站点：
Referer：HTTP头的一个字段，记录该HTTP请求的来源地址
Origin：比起Referer，只需带上域名信息，无需详细的path。
优先判断origin
CSRF Token：第一步，服务器生成一个CSRF Token，植入到返回的页面；第二步，浏览器发起请求时要带上CSRF Token

CPS 指的是内容安全策略，它的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行。配置好规则后，如何拦截由浏览器自己实现。配置方式有以下两种：

通过浏览器漏洞进行的攻击是可以入侵到浏览器进程内部的，可以读取和修改浏览器进程内部的任意内容，还可以穿透浏览器，在用户的操作系统上悄悄地安装恶意软件、监听用户键盘输入信息以及读取用户硬盘上的文件内容。

将渲染进程和操作系统隔离的这道墙就是我们要聊的安全沙箱。

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

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

安全层的作用：对发起HTTPS请求的数据进行加密操作，对接收到的HTTP数据进行解密操作

使用对称加密，指加密和解密都是用的相同密钥

浏览器发送它所支持的加密套件列表和一个随机数 client-random，这里的加密套件是指加密的方法，加密套件列表就是指浏览器能支持多少种加密方法列表。
服务器会从加密套件列表中选取一个加密套件，然后还会生成一个随机数 service-random，并将 service-random 和加密套件列表返回给浏览器。
最后浏览器和服务器分别返回确认消息。

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

首先浏览器还是发送加密套件列表给服务器。
然后服务器会选择一个加密套件，将加密套件和公钥一道发送给浏览器。（不过和对称加密不同的是，使用非对称加密时服务器上需要有用于浏览器加密的公钥和服务器解密 HTTP 数据的私钥）
最后就是浏览器和服务器返回确认消息。

存在的问题：

5.1.3 第三版对称加密和非对称加密搭配使用：在传输数据阶段依然使用对称加密，但是对称加密的密钥我们采用非对称加密来传输。

5.1.4 第四版添加数字证书

免费申请SSL证书：freessl.cn/