浏览器安全（上）
原创
前几篇文章梳理了浏览器中的网络、进程视角和线程视角下的渲染，这篇文章将整理一下浏览器中涉及到的安全知识
本文主要从安全视角分析展开分析各视角下的常用攻击手段及应对策略
安全的不同视角
浏览器的特点就是开放，通过同一的浏览入口（浏览器应用）可以访问任何资源服务，开放的最大特点使任何资源都可以接入其中，通过互联网我们访问任何站点的资源，甚者可以加载并且执行其他网站的脚本，图片，音视频及下载资源等
通常用户使用浏览器访问互联网资源的环境如下图：
对于浏览器用户来说，访问网络资源只需要一台个人终端，终端有可运行浏览器的操作系统、浏览器应用、连通互联网，互联网连接可用的服务，这便是整体运行环境，其中任何环节被攻击都有可能带来安全问题，根据上诉描述，从微观到宏观、从局部到整体来对安全分类
- web页面的安全：黑客以攻击web页面为入口，通过各种手段使页面被劫持插入恶意脚本，通过cookie/storage等窃取用户信息，伪造用户登陆进行恶意操作，对于跨站资源的引入及利用脚本消息通信恶意篡改页面，插入广告等。
- 浏览器的安全：黑客可以间接攻击浏览器，让浏览器程序奔溃，进而让用户无法打开页面，这也是浏览器多进程架构演进的主要原因
- 操作系统的安全：黑客利用浏览器可以访问操作系统资源的权限来间接的让操作系统崩溃，或者通过浏览器来给操作系统注入木马，进而达到窃取用户信息的行为，这也是安全沙箱所设计的初衷。
- 网络通信的安全：黑客可以利用http的明文传输，劫持请求，伪造响应等来诱导用户进行错误资源的访问。
- 服务器的安全：黑客可以模拟请求，对服务端进行恶意的访问，占据服务资源以影响正常的请求等手段让服务不可用
web页面安全
在了解web页面安全之前，我们先来了解什么是浏览器的同源策略，浏览器权衡同源策略而带来的两种攻击方式
同源策略（Same Origin Policy）
同源的定义，url协议、端口、域名完全完全相同称为同源站点，来看nodejs文档内的一张经典图形，origin属性包括rotocol和host，不包括username或password。浏览器默认相同源之间是可以相互访问资源和操作 DOM 的，两个不同源的站点若想相互访问或者操作DOM，就要有安全策略的制约，这种策略称为同源策略。
同源的安全策略限制主要从以下几个方面考虑
1 DOM层面限制
- 同源策略限制了来自不同源的js脚本对DOM对象读写的操作，在同源情况下一个页面中打开同源页面，对象
opener就是指向父页面的window对象。
例如：从文章列表，点击任何一篇文章，新标签打开页面，我们会发现两个页面是同源的，origin都为https://cloud.tencent.com，则可以在新打开的标签页面中使用opener操作文章列表页面的window的对象，可以对父页面的document进行增删改操作。
- 如果是不同源的页面，使用opener对象操作父页面的dom则会报错 Blocked a frame with origin
"https://www.xxxx.cn" from accessing a cross-origin frame.
例如：打开百度首页，然后点击菜单学术（https://xueshu.baidu.com/），可以观察两个页面仍然是同一个站点，都是baidu.com域名下的子站点，但是却不满足同源策略，我们在子页面中使用opener来操作副页面的dom
2 数据层面限制
同源策略对dom层面的限制，使用opener可以让同源站点之间相互操作，opener既是父页面的window对象，可知对于父页面的cookie，localstorage等也可以通过opener来访问
同理，不同源的站点对于数据的访问是有限制的
3 网络通信层面的限制
对于网络层面的限制应该是前端开发同学遇到频率最高的，当异步请求不同源服务或者通过代理访问时，常会遇到如下图的错误。
这是由于同源策略限制了通过XMLHttpRequest和Fetch等方式将站点数据发送不同源站点，跨域站点之间访问，必须通过某种协商机制来确认相互访问的信任。例如使用服务端反向代理或者请求头的控制。
跨站资源的引入放开（CDN）
同源策略限制了所有的资源都来自于同一个源，也就是html、js、css、图片等都必须部署在同一域下，但这违背了web的开放特性，由于cdn的出现，有很多基础js库，ui组件库（例如：jquery，vue，react，bootstrab，elementui，antdui等）都是使用cdn方式引入，对于同一个站点的图片、音视频、字体等资源也会cdn的方式同一管理，既提高了访问速度又提升了用户的体验。
XSS攻击（Cross Site Scripting）
同源策略对页面的资源引用放开，让其可以任意引入外部文件，对于便利性的考虑也会带来安全风险，黑客也正是利用了这点便利制造了XSS（跨站脚本攻击）
xss攻击是黑客往html/dom中注入恶意脚本，在用户浏览页面时进行如下恶意行为：
- 修改DOM：伪造用户的登陆界面，获取用户账号密码
- 监听用户操作：监听键盘鼠标等输入设备的信息
- 窃取cookie数据：利用站点漏洞，窃取cookie来模拟用户登录、请求用户数据
- 生成广告：在页面内生成浮窗广告，影响用户体验
那么黑客是怎么利用脚本窃取数据的呢？
1 存储型XSS攻击（利用服务端的漏洞）
下图为存储型xss攻击的原理
存储型XSS的攻击说明：
- 黑客利用站点的漏洞，将一段恶意的js代码提交到网站的数据库
- 用户向网站请求包含了恶意js的页面
- 恶意脚本通过访问cookie或获取用户表单提交的信息上传到黑客服务器
- 黑客利用客户的cookie或账号密码信息模拟登陆进行恶意行为
2 反射性XSS攻击（利用服务端的漏洞）
下图为反射型XSS的攻击原理
反射型XSS攻击过程：
- 黑客通过各种途径散布带有恶意脚本的链接，并诱导用户点击
- 用户从黑客提供的入口点击进入
- 由于服务端过滤的漏洞，将带有恶意脚本资源返回的同时也将恶意脚本返回
通过以上方式，将恶意脚本注入到了用户可访问的范围，恶意脚本便可以为所欲为。从原理图也可以看出，反射型XSS攻击和存储型XSS攻击的不同之处是 资源服务器不会存储恶意脚本，而是通过请求链路服务器过滤考虑不周全的漏洞原样返回了攻击脚本。
3 DOM型XSS攻击（利用客户端漏洞）
下图为DOM型XSS的攻击原理
- 黑客在数据传输过程中进行劫持
- 将劫持的html内容进行修改
- 用户访问修改过后的html页面内容
这种劫持通常是通过路由器，或者本地的恶意软件来劫持页面，此攻击手段的特点是发生资源传输过程中的劫持篡改，不涉及到资源服务器
XSS防范措施
存储型XSS攻击和反射型XSS攻击都是利用web服务器的漏洞，而DOM型式是在传输过程中篡改页面，无论是何种类型，它们的共同的特点是往浏览器页面中注入恶意脚本，然后通过恶意脚本将用户信息发送至黑客部署的服务器，所以要阻止XSS攻击，通过阻止恶意js脚本注入和恶意消息上报来入手
- 服务端的严格校验：服务端对输入内容进行严格过滤和转码
- 实施严格的CSP（内容安全策略）：
- 禁止向第三方域提交数据
- 限制加载第三方域js脚本
- 禁止执行内联脚本或未授权的脚本
- 上报监控，主动监控用户数据传输上报
- HttpOnly属性：通过使用httponly标记cookie，来限制js读取cookie
- 复杂的输入校验：增强输入校验层级控制，例如短信验证码，图片验证码，长度，不同类型字符整合
CSRF攻击(Cross Site Request Forgery)
CSRF攻击(Cross Site Request Forgery)：跨站请求伪造，是指黑客引诱用户打开黑客的网址，在黑客的网站中获取用户的登陆态利用第三方站点做信息获取篡改等操作。
和XSS不同，CSRF攻击不需要注入恶意代码到用户界面，主要是利用服务器逻辑处理漏洞，利用有效的链接构造恶意的行为。
CSRF攻击的必要条件：
- 浏览器保存用户的登陆态：用户要登陆过目标站点，并且在浏览器保持了站点的登陆状态
- 服务器逻辑漏洞：目标站点一定要存在CSRF漏洞
- 第三方站点可以读取用户登陆态：用户需要打开一个第三方站点，可以是论坛、邮箱、黑客的站点，点击黑客伪造的请求
- 自动发起求get/post请求：黑客利用图片等障眼法发起get请求，利用隐藏表单方式将在用打开链接后，提交参数将请求参数发送至后台实现逻辑漏洞攻击
- 诱导用户点击链接：利用图片、邮箱链接等实现诱导用户点击
黑客利用浏览器中保存的登陆态、服务端漏洞，诱导客户点击第三方站点伪造的请求，实现恶意操作
CSRF防范措施
知道了CSRF攻击的必要条件：登陆态和服务端逻辑漏洞的利用，所以防范措施也从这两点入手：
- （登陆态防护）避免cookie被第三方站点利用：大部分网站使用了cookie来存储登陆台，保护cookie不被第三方站点利用尤为重要，合理利用cookie的samesite属性
- strict：严格校验，严格校验站点是否为同源
- lax：较宽松校验，在跨站点的情况下，从第三方网站打开链接，get方式提交表单都会携带cookie，但如果在第三方站点中使用了post方法，或者通过img，iframe等标签加载的url，会禁止cookie发送
- none：不校验第三方站点是否为同源或同一站点，任何情况下都会发送cookie
- （服务端加强校验）验证请求来源：在服务端验证请求源站点origin属性，请求方法，请求header等
- （客户端来源验证）为请求打标记：
- 服务端返回给浏览器唯一签名
- 浏览器携带签名token发送请求
- 服务端验证签名有效性，确保客户端可信
未完，后续浏览器稳定性视角和网络视角分析。。。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。