浏览器安全

页面安全

同源策略

默认同源之间可以相互访问资源和操作DOM，不同源则会有一套限制访问的制约。

制约

DOM

限制了来自不同源的js脚本对当前DOM的读和写操作（openner、iframe等方式）

web数据

限制了来自不同源的js脚本对当前cookie、storage、DB数据的读和写操作（openner、iframe等方式）

网络

限制的通过XHR等方式向不同的源发送请求

限制XHR请求混合内容（在https站点发送http请求，XHR会报错，其他类型的资源请求主要是警告）

策略

在安全和便利之间寻找均衡，提供一定程度的控制：

页面默认可以访问第三方资源，可以通过CSP来控制

默认网络请求不可以跨域，可以通过cors控制

虽然有了CSP和CORS手段，但还是有不少安全问题，典型的是：XSS、CSRF

XSS

页面被注入恶意脚本，可以窃取用户cookie，监听用户键盘事件，修改 DOM伪装登录界面以获取用户账号密码，生成弹窗广告等

存储型XSS攻击

用户可以自定义的内容直接存储到服务器，其他用户可以直接查看该内容

应对方案：

1. 服务器对于所有用户输入的内容，转码后再存储
2. 客户端对于所有直接以html文档片段写入html的都要进行转码（主要是script和各种可以发起请求的标签属性：src、href等）
3. CSP
4. httpOnly

反射型XSS攻击

将恶意脚本拼在url中，服务器直接将恶意脚本注入html模板并返回；或者直接返回浏览器，在浏览器中由js直接写入html

应对方案：

1. 服务器对于所有需要注入html模板的内容，转码后再注入
2. 客户端对于所有直接以html文档片段写入html的都要进行转码（主要是script和各种可以发起请求的标签属性：src、href等）
3. CSP
4. httpOnly

基于DOM的XSS攻击

直接在服务器响应客户端的各个节点上（路由器，wifi，本地恶意软件等）劫持html，注入恶意脚本再返回

应对方案：

1. CSP
2. httpOnly

CSP功能

1. 限制加载其他域的资源
2. 禁止向第三方域提交数据
3. 禁止执行内联脚本和未授权的脚本
4. 上报机制，遇到攻击时可以快速发现

HttpOnly属性

cookie的属性，set cookie的时候加了这个标志，就表明只用于请求，js无法读取

CSRF

点击了恶意链接或者访问了恶意网站，仅仅使用服务器的漏洞和用户的登录态来进行攻击。

1. 自动发起恶意请求（get/post）
   1. get：src、action
   2. post：action
2. 诱导用户点击
   1. a标签的href

解决方案：

1. cookie的SameSite属性
   1. Strict：禁止从三方站点发起的请求携带自己的cookie
   2. Lax：相对于Strict放开了从三方站点点击链接和get的form表单
   3. None：不限制
2. 服务器验证请求源：请求头的Referer和Origin属性
3. 在自己的网站返回csrf token，请求的时候携带上该token，就可以防止三方站点请求（没有csrf token）

系统安全

浏览器是以站点为渲染进程最小的单元。即一个页签有多个iframe，但它们不是同一个浏览上下文组的话，会分配不同的渲染进程。

避免渲染进程被攻击进而直接攻击操作系统，浏览器架构中对渲染进程进行安全沙箱隔离，即所有的访问操作系统的操作都需要通过浏览器内核（主进程、网络进程、GPU进程等），包括cookie的读写，cache的维护，网络请求，用户交互（窗口句柄的事件）。