Open lewenweijia opened 4 years ago
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, 设置一个就好了的啊
xss之盗取cookie
1. 否定单进程浏览器
2. 多进程 + 渲染进程沙箱化
3. 跨源iframe入侵渲染进程问题引申的站点隔离(site isolation)特性
碎碎念
渲染进程职责:
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完全实现站点隔离化 (安全特性的啊)
xss只是通过js脚本来进行对渲染进程/也就是页面级别的攻击的啊, 无法侵入到浏览器/甚至操作系统的
从开发的视角: 浏览器可以划分为两个模块, [渲染进程沙盒模块] 和 [浏览器内核模块, 对渲染进程 提供资源支持]