- 浏览器安全分为三大块:Web页面安全、浏览器网络安全和浏览器系统安全。
Web页面安全
- 什么是同源策略
- 如果两个URL的协议、域名和端口都相同,我们就称这两个URL同源。
- 浏览器默认两个相同的源之间是可以相互访问资源和操作DOM的。如果两个不同的源之间若想要相互访问资源或者操作DOM,那么会有一套基础的安全策略的制约,这就是同源策略。
- 同源策略主要表现在DOM、Web数据和网络这个三个层面。
- DOM层面:同源策略限制来自不用源的JS脚本对当前DOM对象的读写操作。
- 数据层面:同源策略限制了 不用源的站点读取当前站点的Cookie、IndexDB、LocalStorage等数据。
- 网络层面:同源策略还限制了通过XMLHttpRequest等方式将站点的数据发送给不同源的站点。XMLHttpRequest默认情况下不能访问跨域的资源。
- 安全和便利性的权衡
- 同源策略一定程度上加强了Web项目的开发和使用难度,Web时开放的,可以接入任何资源,但是同源策略要让一个页面的所有的资源都来自同一个源。因此需要同源策略对页面的引用资源开个口子,让其可以任意引用外部文件。
- XSS攻击:通过JS代码读取页面数据,如Cookie数据将其添加到恶意站点的尾部从而将当前用户的Cookie信息发送到恶意服务器。
- 针对XSS攻击,浏览器引入了内容安全策略(CSP):CSP的核心思想就是让服务器来决定浏览器能够加载哪些资源,让服务器决定浏览器是否能够执行内联JS代码。
- 跨域资源共享和跨文档消息机制:引入跨域资源共享(CORS),使用该机制可以进行跨域访问控制,从而使跨域数据传输得以安全进行。实际生成中经常需要两个不同源的DOM之间进行通信,于是浏览器中引入了跨文档消息机制,可以通过window.postMessage的JS接口来和不同源的DOM进行通信。
- 综上:页面中引入第三方资源暴露了XSS的安全问题,因此引入CSP来限制;使用XMLHttpRequest和Fetch无法直接进行跨域请求,因此浏览器引入跨域资源共享策略(CORS),让其能安全地进行跨域操作;两个不用源的DOM不可相互操作,因此浏览器实现了跨文档消息机制,让其能安全地通信。
XSS攻击
- 什么是XSS攻击
- XSS全称Cross Site Scripting即跨站脚本。XSS攻击时指黑客往HTML文件中或者DOM中注入恶意脚本,从而用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。
- 可以窃取Cookie信息:恶意JS通过
document.cookie
获取Cookie信息,然后通过XMLHttpRequest或者Fetch加上CORS(跨域资源共享)功能将数据发送给恶意服务器;恶意服务器拿到用户的Cookie信息之后,就可以在其他电脑上模拟用户的登录。 - 可以监听用户行为:恶意JS可以使用
addEventListener
接口来监听键盘事件,如果获取用户入的信用卡等信息,将其发送到恶意服务器。 - 可以通过修改DOM伪造假的登录窗口:用来获取用户输入的用户密码。
- 可以在页面内生成浮窗广告:这些广告严重地影响用户体验。
- 恶意脚本注入方式
- 存储型XSS攻击:黑客利用站点漏洞将一段恶意JS代码提交到网站的数据库中;然后用户向网站请求包含了恶意JS脚本的页面;当用户浏览该页面的时候,恶意脚本就会将用户的Cookie信息等数据上传到服务器。
- 反射型XSS攻击:恶意JS脚本属于用户发送给网站请求的一部分,随后网站又把恶意JS脚本返回给用户,当恶意js脚本在用户界面被执行时,何况就可以利用该脚本进行一些恶意操作。Web服务器不会存储反射型XSS攻击的恶意脚本,这是和存储型XSS攻击不用的地方。
- 基于DOM的XSS攻击:黑客通过各种手段将恶意脚本注入用户的页面,如通过网络劫持在页面传输过程中修改HTML页面的内容,这种劫持类型很多。有通过WiFi路由器劫持的,有通过本地恶意软件劫持的,他们的共同点实在Web资源传输过程中或者用户使用页面的过程中修改Web页面的数据。
- 如何阻止XSS攻击
- 存储型XSS和反射型XSS都需要经过Web服务器处理,因此这2者时服务端的安全漏洞,而基于DOM的XSS时在浏览器端完成的,属于前端的安全漏洞。
- 服务器对输入脚本进行过滤和转码
- 充分利用CSP(内容安全策略):限制加载其他域下的资源文件;禁止向第三方域提交数据;禁止执行内联脚本和未授权脚本;提供上报机制,这可以帮助我们尽快发现有哪些XSS攻击。
- 使用HttpOnly属性:很多XSS攻击都是用来盗用Cookie的,因此可以通过HttpOnly属性来保护Cookie的安全。HttpOnly是服务器通过HTTP响应头来设置的。set-cookie属性值 最后使用HttpOnly来标记该Cookie。对应的Cookie信息无法通过
document.cookie
来获取。
CSRF攻击
- 什么是CSRF攻击
- CSRF全称Cross-Site request forgery,所以称为"跨站请求伪造":是指黑客引诱用户打开黑客的网站,在黑客的网站中,利用用户的登录状态发起跨站请求。本质是CSRF攻击利用用户的登录状态,并通过第三方的站点来做一些事情。
- 自动发起Get请求:将恶意请求隐藏在元素上,当页面加载时,浏览器会自动发起资源请求,如果服务器未做请求判断,那么寄生在资源元素的请求就会被执行。
- 自动发起POST请求:黑客在他构建的页面隐藏了一个隐藏的表单,当用户打开站点后,这个表单会被自动执行提交。因此使用构建自动提交表单的方式,可以自动实现跨站点POST数据提交。
- 引用用户点击连接:这种方式通常出现在论坛或者恶意邮件上。点击连接的同时就是完成黑客设置请求发送。
- 和XSS不同的是,CSRF攻击不需要将恶意代码注入到用户的页面,仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。
- 如何防止CSRF攻击
- 发起CSRF攻击的三个必要条件:目标站点一定要有CSRF漏洞;用户登录过目标站点并且在浏览器上保持有该站点的登录状态;需要用户打开一个第三方站点,可以是黑客的站点也可以是一些论坛。
- CSRF攻击不会往页面注入恶意脚本,所以黑客无法通过CSRF攻击来获取用户页面数据的;其关键的一点是要能找到服务器的漏洞,所以CSRF攻击主要防护手段是提升服务器的安全性。
- 充分利用好Cookie的SameSite属性:CSRF攻击是利用登录状态发起的,而Cookie正式浏览器和服务器之间维护登录状态的一个关键数据。而CSRF攻击时从第三方站点发起的,所以要防止CSRF攻击,就需要实现从第三方站点发送请求时禁止Cookie的发送,从同一个站点发起的请求允许Cookie数据能正常发送。Cookie中的SameSite属性就解决了这个问题。
- SameSite可以在HTTP响应头中通过set-cookie字段来设置Cookie时,带上SameSite选项。SameSite用Stick、Lax和None三个指,Strict最为严格浏览器会完全禁止第三方Cookie。Lax相对宽松在跨站点的情况下,从第三方站点的连接打开和从第三方占地提交Get方式的表单这两种方式都会携带Cookie。但是第三方站点中使用Post方法或者通过img、iframe等标签加载的URL这些场景时不会携带Cookie。而None的话,在汾河情况下都会发送Cookie数据。
- 验证请求的来源站点:在服务器端验证请求来源的站点。Refer是HTTP请求头中的一个字段,记录该HTTP请求的来源地址。面对不适合暴露请求来源的场景,可以不上传Refer而是使用Refer Policy。
- 服务端验证Refer不太可靠,为此标准委员会又指定了Origin属性,XMLHttpRequest、Fetch发起跨站请求或者通过Post方法发送请求时,HTTP请求头都会带上Origin属性。Origin属性只包含域名信息,并不包含具体的URL路径。因此服务器的策略是优先判断Origin,如果没有Origin属性,在根据实际情况判读是否使用Refer值。
- CSRF Token:浏览器向服务器发送请求时,服务器生成一个CSRF Token。CSRF Token是服务器生成的字符串,然后将该字符串植入到返回的页面中。在浏览器之后发起请求时,那么需要带上页面中的CSRF Token,服务器会验证Token是否合法。第三方站点发出的请求,无法获取CSRF Token的值。
浏览器架构是如何影响操作系统安全的
- 通过浏览器漏洞进行的攻击是可以入侵到浏览器进程内部的。可以读取和修改浏览器进程内部的任意内容,还可以穿透浏览器,缓冲区溢出时最常见的攻击方式,这类工具威胁到了整个操作系统。
- 浏览器被划分为浏览器内核和渲染内核,渲染内核就是渲染进程,是在沙箱环境下运行的。浏览器内核是由网络进程、浏览器主进程和GPU进程组成的。
- 安全沙箱:利用操作系统提供的安全技术,让渲染进程在执行过程中无法访问或者修改操作系统的数据,在渲染进程需要访问系统资源的时候,需要通过浏览器其内核来实现,然后将访问的结果通过IPC转发给渲染进程。安全沙箱最小的保护单位是进程。单进程浏览器无法被安全沙箱保护。现代浏览器采用多进程架构使得安全沙箱发挥作用。
- 渲染进程:HTML解析、CSS解析、图片解析、JS执行、布局、绘制、XML解析。
- 浏览器内核:Cookie存储、Cache存储、网络请求、文件读取、下载管理、SSL/TSL、浏览器窗口管理。
- 安全沙箱负责确保渲染进程无法直接访问用户的文件系统,但渲染进程内部又访问Cookie的需求和上传文件的需求。为此现代浏览器把读写文件的操作全部放在浏览器内核中实现,然后通过IPC将操作结果发给渲染进程。
- 渲染进程内部也不能直接访问网络,如果要访问网络也是在浏览器内核内部完成。浏览器内核在处理URL之前会坚持渲染进程是否又权限请求该URL。比如跨站点请求,HTTPS站点中是否包含HTTP请求。
- 渲染进程也影响到了用户交互:渲染进程内部无法直接操作窗口句柄。渲染进程渲染出位图需要将生成好的位图发送到浏览器内核,然后浏览器内核将位图复制到屏幕上。所有的输入事件都由浏览器内核来接收,在通过IPC将事件发送给渲染进程执行。
- 站点隔离
- 所谓的站点隔离是指Chrome将同一站点(相同根域名和相同协议的地址)中相互关联的页面放到同一个渲染进程中执行。
- 起初按标签页为单位划分渲染进程。因为一个标签页可以有多个iframe,而iframe来自不同站点,这就导致多个不同站点的内容通过iframe同时运行在同一个渲染进程中。
- 操作系统面离2个A级别漏洞:幽灵(Spectre)和熔毁(Meltdown),这2个漏洞是由处理器架构导致的。入侵的进程如果没有安全沙箱的保护。那么黑客就会通过这2个漏洞发起对操作系统的攻击。
- 标签级的渲染进程重构未iframe级的渲染进程,然后严格控制同一站点策略来分配渲染进程。这就是Chrome的站点隔离。
- 安全沙箱的目的是隔离渲染进程和操作系统,让渲染进程没有访问操作系统的权限,而XSS和CSRF是利用网络资源获取用户信息,这和操作系统没有关系。