页面安全

[lewenweijia]

xss只是通过js脚本来进行对渲染进程/也就是页面级别的攻击的啊, 无法侵入到浏览器/甚至操作系统的

• 页面层面的资料不安全
• 操作系统层面的资料不安全

稳定性视角下的浏览器多进程架构
安全视角下的浏览器多进程架构
  所以页面的工作需要独立进程进行隔离开的效果的啊
  !! 渲染进程作为安全沙箱 ---> 通过IPC和系列浏览器内核进程访问(浏览器主进程/网络进程/其他)

从开发的视角: 浏览器可以划分为两个模块, [渲染进程沙盒模块] 和 [浏览器内核模块, 对渲染进程 提供资源支持]

浏览器?:
页面循环(JS执行上下文/V8)/页面/网络/安全

浏览器安全?:
1. web页面安全
2. 浏览器系统安全
3. 浏览器网络安全

csrf? 利用服务器的漏洞和用户的登录态来进行攻击
恶意页面中的请求构造:
1. 自动get请求: img标签, 如果服务器支持get方法修改数据 + 没有对请求做安全权限校验
2. 自动post请求: form+script标签
3. 用户手动get请求: a标签

浏览器SOP下的两个"后门"
1. 请求第三方资源: iframe/img/video/js/css
2. CORS策略正大光明请求第三方资源
安全
1. csp来反约束请求第三方资源的"后门"
2. httponly防止xss场景下的cookie泄露
3. samesite和origin属性来防止csrf <-- 民间方法是通过csrf token的啊
``

[lewenweijia]

csrf的三个必要条件:
1. 目标站点/目标服务器有csrf漏洞
2. 用户登录过目标站点, 有登录态的保留
3. 用户打开恶意站点

特点:
1. 攻击者无法通过csrf获取用户的页面数据
2. 关键的, 攻击者需要提前找到目标站点的csrf漏洞

防范:
1. cookie的sameSite属性, 如果是第三方站点发起的请求, 禁止浏览器发送某些关键cookie数据到服务器
   - strict: 完全禁止第三方网站进行cookie的提交
   - lax: 第三方站点的post方法/img/iframe, 不携带cookie, 也就是大多数不懈怠
     链接a/prerender/method为get的form标签
   - none: 任何情况都发送cookie(默认情况, 也是不支持这种功能的浏览器的情况)
   (samesite属性: 防止csrf和用户追踪的啊)
2. 验证请求的来源站点
   请求头中的referer/origin属性
   referer -> 该http的请求的请求来源地址(浏览器提供给开发者可以不上传referer) <- referer plicy
   引用者策略, 有些场景不适合将来源URL暴露给服务器(用户隐私问题: 例如广告投放, 一些人在敏感网站接触
   到该广告)
   Referer本身定位就不是做这件事的, 不靠谱. W3C又定制了Origin, 重要场合, XHR, Fetch发起跨站/
   通过post方法发送请求, 都会带上origin属性
   : origin不包含path信息(安全考虑), referer包含路径信息
   服务器应该采用的策略是优先判定origin, 如果请求中没有origin, 根据实际条件判断referer
3. csrf token
   

一次setcookie, 设置一个就好了的啊

[lewenweijia]

xss之盗取cookie

1. 否定单进程浏览器
2. 多进程 + 渲染进程沙箱化
3. 跨源iframe入侵渲染进程问题引申的站点隔离(site isolation)特性

[lewenweijia]

碎碎念

渲染进程职责:
DOM解析, CSS解析, 网络图片解码

渲染进程工作流水线: 
1. 接受网络进程IPC过来的资源, 进行解析, 绘制, 生成图片
2. 将图片通过IPC交付给浏览器主进程, 浏览器主进程负责图片/位图的上屏展示(和显卡交互)


网络资源是不可信的, 很有可能黑客通过网络内容进行攻击, 突破渲染进程中系统级的漏洞
随意下载内容, OK. 但是执行这些内容就要十分小心了, 单恰恰渲染进程需要对网络内容
进行消费: HTML, JS, CSS, 图片编解码

沙箱的最小保护单位是进程的呢
让进程沙箱化 -> 意味着封锁该进程对系统资源(IO, 设备)的操作权限(例如读写本地文件, 发送网络请求
  , 调用GPU接口
  
渲染进程职责: HTML/XML解析, CSS解析, 图片解码, JS执行, 布局, 绘制
浏览器内核职责: Cookie存储, Cache存储, 网络请求, 文件请求, 下载管理, SSL/TLS, 浏览器窗口管理

渲染进程要使用持久存储的功能? 渲染进程向浏览器内核发送需求, 浏览器内核实现, 通过IPC将结果转发给渲染进程

浏览器内核会检查渲染进程各种需求(文件/网络)执行前的权限校验的啊 

系统提供UI界面句柄给浏览器, 浏览器将界面句柄发生的内容, 通过IPC转发到渲染进程,
也就是渲染进程是无法直接操作窗口句柄的

浏览器对UI窗口句柄的处理:
1. 如果是浏览器本身的交互(例如地址栏), 那么浏览器内核自己处理
2. 如果是落在渲染进程出的图的区域, 那么将输入事件转发给渲染进程

限制渲染进程监控用户输入时间的能力, 所有的键盘/鼠标都是要经过浏览器内核这个代理层的啊


浏览器内核对渲染进程的沙箱化具体表现: 持久存储, 网络访问, 用户交互 <- 让这些功能不能直接让渲染
进程直接交互, 都需要经过浏览器内核这一层, 渲染进程永远在最后方位!

目前操作系统必然的两个A级系统漏洞: 幽灵(spectre)和熔毁(Meltdown)

网络的不确定内容就是突破口啊
黑客通过向渲染进程分发恶意内容, 入侵渲染进程, 再利用A级系统漏洞入侵操作系统

1. iframe进程化, 而不是作为渲染进程的某一线程(site isolation)
2. 2019/10/20, 安卓版的Chrome完全实现站点隔离化 (安全特性的啊)