浏览器安全分为三大块:Web页面安全、浏览器网络安全、浏览器系统安全。
页面中最基础、最核心的安全策略:同源策略(same-origin policy) 如果两个URL协议相同、域名相同、端口相同,就称为这两个URL同源 同源策略就是说:相同源之间可以操作DOM、读取互相之间的Cookie、indexDB、locationStorage等页面数据以及网络层面共享。 也就解释了为什么同源策略限制了XMLHttpRequest讲站点数据发送给不同源站点。
安全性和便利性是互斥的,比如上面的同源策略限制了一个页面中资源都需要来自一个源,也就是该页面的所有HTML文件、CSS文件和JS文件等资源需要部署在一台服务器,但是如果资源过多,或者说我们基于业务会将不同资源部署在不同服务器上,因此为了解决同源策略导致的页面资源必须来自同一个源这个限制: 浏览器引入了CSP内容安全策略(Content Security policy),核心思想是让服务器决定浏览器能够加载哪些资源,让服务器决定浏览器是否能执行内敛JavaScrip代码,通过CSP可以大大减少XSS攻击。
同源策略还带来的一个问题是,如果我们用XMLHttpRequest去访问另一个源,会收到限制,这个时候又引入了CORS(跨域资源共享)策略。 使用该机制可以进行跨域访问控制,从而使得数据传输得以安全进行。
同源策略还有一个问题是不能互相操作DOM,同样也提供了安全的方法解决:使用跨文档消息机制:window.postMessage的JS接口来和不同源DOM进行通信。
在同源策略的严格限制下,如果不能引入第三方资源,显然是不方便的,为此在安全和自由之间找的平衡,允许引入第三方资源,而随之而来的就是带来的页面安全问题,这些问题产生的过程,并进一步加深说明引入CSP机制的必要性。
XSS全称为:Cross Site Scripting.为了与CSS区分开,所以叫CSS。 XSS攻击指的是劫持者往HTML文件或者DOM中注入恶意脚本,而使得用户在浏览页面时利用恶意脚本实施攻击的一种手段。 当然注入JavaScript恶意脚本时,由于允许引入了第三方资源,所以浏览器无法区分这些脚本是恶意引入还是正常页面内容,注入的恶意脚本拥有所有脚本的权限,于是可能产生:窃听用户Cookie、通过addEventListener监听用户行为、修改DOM、在页面生成浮窗广告等。
那么这些恶意脚本是如何注入的呢? 通常情况下,恶意注入脚本的方式有三种:存储型XSS攻击、反射性XSS攻击和基于DOM的XSS攻击。
这个指的是劫持者正常访问网站,然后利用网站的漏洞将一段恶意代码提交到网站数据库中,然后别人访问这个上传恶意脚本的页面的时候,一些信息被上传到恶意代码上传的服务器中。
反射型XSS攻击值得是用户将一段含有恶意代码的请求提交给Web服务器,Web服务器接收到请求再次返回给浏览器端。 常见的比如通过QQ群或者邮件渠道引导用户点击恶意链接。 需要与存储型XSS攻击区别的是:反射型XSS攻击中,Web服务器并不会存储攻击的请求内容。
这个攻击比较有技术含量,需要劫持页面,将劫持的页面中修改HTML页面内容等。 这种劫持类型包括WIFI路由器劫持、本地恶意软件劫持等。共同点就是Web资源传输过程中或用户使用页面过程中劫持数据内容加以修改。
存储型和反射型XSS攻击是服务端的安全漏洞,而基于DOM的XSS攻击是在浏览器端完成从,属于前端漏洞。
CSRF:Cross-site request forgery,跨站请求伪造。主要指侵入者引诱用户打开侵入者网站,利用用户的登录态来发起跨站请求。 简单来说就是,侵入者利用用户登录态通过第三方网站做一些坏事。
在第三方网站利用用户登录态调用原网址请求转账等接口来模拟原网站请求。 当用户点击链接时,自动发起get请求。
同Get请求一样,侵入者在自己的网站使用hidden的form,自动发起POST请求。
点击链接后,自动请求转账接口。
CSRF攻击首先服务器有漏洞、用户登录过已有站点、且在第三方站点发起请求。
Cookie是浏览器和服务器直接维护登录状态的一个关键数据。 因此我们可以从第三方站点发送请求时禁止Cookie的发送,而Cookie中的SameSite属性就是解决这个问题的,使用SameSite可以有效减低CSRF的攻击。 使用方式是:在响应头上,通过set-cookie字段设置Cookie,带上SameSite选项。 通常有三个值:Strict、Lax和None。
那么,如何来验证其ing求是来自第三方站点呢? 需要使用到HTTP请求头中的Referer和Origin属性。
类似于JWT的token。
浏览器架构是如何影响操作系统安全的。
浏览器被划分为浏览器内核和渲染内核两个模块。 浏览器打开一个页面,先通过浏览器内核的网络进程下载资源,然后通过IPC将资源交给渲染进程,渲染进程进行一系列操作,最后生成图片之后,再将生成的图片返回给浏览器内核去展示这张图片。流程搞得如此复杂就是为了安全。
主要是为了避免在渲染进程中被劫持着搞破坏,而在渲染进程和操作系统之家构建了一道墙,这样劫持者就获取不到渲染进程之外的权限了,我们把这个将渲染进程和操作系统隔离的强称为安全沙箱。 然后这个安全沙箱的作用啰嗦一点就是,你渲染进程有需要使用系统权限的,通过IPC给浏览器内核发布需求,然后相应的浏览器内核将操作结果返回给渲染进程使用,这样不管如何操作系统的权限就保护住了。
首先,安全沙箱的最新保护单位是进程,也就是说如果安全沙箱应用在某个进程上,那么这个进程是没有系统权限的,比如读写本地文件、发起网络请求、调用GPU接口等,因此就可以分析渲染进程和浏览器内核的各自职责,不完全统计为:
回到小标题,影响各个模块主要是通过以下几个方面:
简单说就是,之前的浏览器多进程架构的渲染进行是根据标签页划分的,这样存在的问题是如果一个页面通过iframe包含另一个页面,那么就会存在于一个渲染进程中,这样的漏洞会给劫持者有机可乘,于是乎,Chrome将标签级的渲染进程重构为了iframe级的渲染进程。这就是站点隔离。
HTTP保持着明文规定传输数据的特征,这个环节会存在传送的数据被窃取或者篡改。
从HTTP协议来看,可以在HTTP与TCP层之间加入一个安全层,所有经过安全层的数据都会被加密或解密。 因此说HTTPS并非一个新的协议,只是加入了一个安全层,安全层的主要职责:对发起HTTP请求的数据进行加密操作和对接收到的HTTP内容进行解密操作。 接着,我们从这个安全层开始,一步一步实现由简单到复杂的HTTPS协议。
对称加密:加密和解密都使用的是相同的密钥. 存在的问题,加密套件是明文的(因为需要在传输的时候携带),所以这种方式也是可以被拿到的。
和对称加密只有一个密钥不同,非对称加密算法有 A、B 两把密钥,如果你用 A 密钥来加密,那么只能使用 B 密钥来解密;反过来,如果你要 B 密钥来加密,那么只能用 A 密钥来解密。 公开的为公钥,不公开自己用的叫私钥。 同样存在的问题是:非对称加密效率低且无法保证服务器发送给浏览器的数据是安全的。
在传输数据阶段依然使用对称加密,但是对称加密的密钥我们采用非对称加密来传输. 这样存在的一个问题是黑哥如果通过DNS劫持,将官网IP地址替换成黑哥网址,那就存在很大的风险了。 于是需要向浏览器证明"我就是我",这个就是CA机构颁发的数字证书。