浏览器安全

浏览器安全可以分为 三大块 —Web页面安全、浏览器网络安全 和 浏览器系统安全

  • 同源策略：为什么XMLHTTPRequest不能跨域请求资源？

    1. 页面中最基础、最核心的安全策略：同源策略

    2. 如果两个 URL协议、域名和端口都相同，我们就称这两个 URL 同源。

    3. 浏览器默认2个相同的源之间是可以相互访问资源和操作DOM的。两个不同的源之间若想要相互访问资源或者操作 DOM，那么会有一套基础的安全策略的制约，我们把这称为同源策略。
      具体表现在

      1. DOM

        1
        { let pdom = opener.document.body.style.display = "none"}

      2. Web数据
        无法去读Cookie、IndexDB 或者 LocalStorage 等内容

      3. 网络 XMLHTTPRequest 不能跨域请求资源

    4. 安全性和便利性的权衡
      同源策略会隔离不同源的DOM、页面数据和网络通信，为了便利性，浏览器让出一些安全性来满足灵活性
      2大问题：XSS 攻击 CSRF攻击

      1. 页面中可以嵌入第三方资源，比如将不同的资源部署到不同的CDN上时候，CDN上的资源就部署在另外的域名上
        容易引发XSS攻击，为了解决XSS攻击，浏览器引入了内容安全策略，称为CSP。
        CSP的核心思想就是让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能够执行内联JS代码

      2. 跨域资源共享和跨文档消息机制

        1. 跨域资源共享 CORS Corss Origin Resource Sharing
          跨域资源共享 CORS 详解
          CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。
          因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信
        2. 跨文档消息机制
          HTML5中的跨文档消息传递

  • 跨站脚本攻击（XSS）：为什么Cookie 中有 HttpOnly属性？

    1. XSS 全称是Cross Site Scripting XSS 攻击是指黑客往HTML文件中或者DOM中注入恶意脚本，从而在用户浏览页面时候利用注入的恶意脚本对用户实施攻击的一种手段

    2. 恶意脚本可以做的事情 1. 窃取Cookie信息 2. 监听用户行为 3. 修改DOM 伪造假的登陆窗口 4. 生成浮动窗口广告

    3. 攻击类型

      1. 存储型XSS 攻击
        将恶意代码存储到存在漏洞的服务器，访问含有恶意脚本的页面，上传用户信息到恶意服务器

      2. 反射型 XSS 攻击
        我们会发现用户将一段含有恶意代码的请求提交给 Web 服务器，Web 服务器接收到请求时，又将恶意代码反射给了浏览器端，
        Web 服务器不会存储 反射型 XSS 攻击的恶意脚本 黑客经常会通过 QQ 群或者邮件等渠道诱导用户去点击这些恶意链接

      3. 基于DOM 的XSS 攻击
        基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的，它们的共同特点是在Web资源传输过程或者在用户使用页面的过程中修改

    4. 如何阻止XSS攻击

      1. 存储型 XSS 攻击和反射型 XSS 攻击 - 利用服务器阻止
        1. 服务器对输入脚本进行过滤或转码
        2. 充分利用CSP
        3. 限制加载其他域下的资源文件，这样即使黑客插入了一个JS文件，这个JS文件也是无法被加载的
        4. 禁止向第三方域提交数据，这样用户也不会外泄
        5. 禁止执行内联脚本和未授权的脚本
        6. 提供了上报机制，帮助我们尽快发现有哪 XSS 攻击，以便尽快修复问题
        7. 使用HttpOnly 属性，阻止脚本读取Cookie
      2. 基于 DOM 的 XSS 利用 HTTPS

  • CSRF 攻击： 陌生链接不要随便点

  1. CSRF 英文全称是 Cross-site request forgery， 称为“跨站请求伪造”，黑客利用用户的登陆状态，并通过第三方做一些事情

  2. 如何实现CSRF

    1. 自动发起get请求 ， 黑客将转账的请求接口隐藏在 img 标签内
    2. 自动发起POST请求 ， 当用户打开黑客的站点时，是自动提交 POST 请求
    3. 引诱用户点击链接 ， 美女图片 而这个下载地址实际上是黑客用来转账的接口，一旦用户点击了这个链接，那么他的极客币就被转到黑客账户上了

  3. 如何防止 CSRF 攻击

    1. 在 HTTP 响应头中，通过 set-cookie 字段设置 Cookie 时，可以带上 SameSite 选项
      如果你从极客时间的页面中访问 InfoQ 的资源，而 InfoQ 的某些 Cookie 设置了 SameSite = Strict 的话，那么这些 Cookie 是不会被发送到 InfoQ 的服务器上的。只有你从 InfoQ 的站点去请求 InfoQ 的资源时，才会带上这些 Cookie

    2. 服务器验证请求的来源站点

      1. Referfer 是 Http 请求头中的一个字段，记录了该 HTTP 请求的来源地址
      2. Origin： Origin 属性只包含了域名信息，并没有包含具体的 URL 路径

    3. CSRF Token

      1. 在浏览器向服务器发起请求时候，服务器生成一个CSRF Token。CSRF Token 其实 就是服务器生成的字符串，该字符串植入到返回的页面中

      2. 在浏览器如果要发起转账请求的时候，需要带上页面中的 CSRF Token, 然后服务器会验证Token是否合法。如果是从第三方站点发出的请求，将无法获取到 这个值，所以即使发出来请求，服务器因为token不争气而拒绝请求

  • 安全沙箱：页面和系统之间的隔离墙

    1. 页面安全和操作系统安全

    2. 渲染进程放在安全沙箱中：HTML 解析，CSS 解析，执行JS，图片解码，渲染出位图

      1. 为什么一定要通过浏览器内核去请求资源，再将数据转发给渲染进程，而不直接从进程内部去请求网络资源？
      2. 为什么渲染进程只负责生成图片，生成图片还要经过IPC 通知 浏览器内核模块，然后让浏览器内核去负责图片

    3. 将渲染进程和操作系统隔离的这道墙就是我们要聊的安全沙箱，安全沙箱,
      浏览器中的安全沙箱是利用操作系统提供的安全技术，让渲染进程在执行过程中无法访问或者修改操作系统中的数据，在渲染进程需要访问系统资源的时候，需要通过浏览器内核来实现，然后将访问的结果通过 IPC 转发给渲染进程

    4. 渲染进程和浏览器内核各自有哪些职责

      1. 渲染进程：HTML解析，CSS 解析，图片解码，JS 执行，布局，绘制，XML解析
      2. 浏览器内核：Cookie存储，Cache 存储，网络请求，文件读取，下载管理 ，SSL/TSL ，浏览器窗口管理
  1. 安全沙箱如何影响各个模块功能
    1. 持久存储 Cookie 读取， 缓存文件的读写
    2. 网络访问
    3. 用户交互
    4. 站点隔离：由于最初都是按照标签页来划分渲染进程的，所以如果一个标签页里面有多个不同源的 iframe，那么这些 iframe 也会被分配到同一个渲染进程中，这样就很容易让黑客通过 iframe 来攻击当前渲染进程。而站点隔离会将不同源的 iframe 分配到不同的渲染进程中，这样即使黑客攻击恶意 iframe 的渲染进程，也不会影响到其他渲染进程的
  • HTTPS：让数据传输更安全（网络安全协议）
    1. 对称加密和非对称加密搭配使用
    2. 浏览器向服务器发送对称加密套件列表、非对称加密套件列表 和随机数 client-random
    3. 服务器保存随机数client-random,选择对称加密和非对称加密的套件，然后生成随机数service-random, 向浏览器发送选择的加密套件，service-random和公钥
    4. 浏览器保存公钥，并生成随机数pre-master,然后利用公钥对 pre-master 加密，并向服务器发送加密后的数据；
    5. 最后服务器拿出自己的私钥，解密出 pre-master 数据，并返回确认消息。
    6. 服务器和浏览器就有了共同的 client-random、service-random 和 pre-master，然后服务器和浏览器会使用这三组随机数生成对称密钥，因为服务器和浏览器使用同一套方法来生成密钥，所以最终生成的密钥也是相同的

  1. 添加数字证书

    1. 对浏览器来说，数字证书有2个作用：一个是通过数字证书向浏览器证明服务器的身份，另一个是数字证书里面包含了服务器公钥

    2. 增加数字证书后，有2点不同：

      1. 服务器没有直接返回公钥给浏览器，而是返回了数字证书，而公钥是包含在数字证书中
      2. 浏览器端多了一个验证数字证书的操作，只有验证了证书后，才继续走后面的流程

    3. CA 向极客时间签发认证的数字证书，包含了极客时间的公钥、组织信息、CA的信息、有效时间、证书序列号等，这些信息都是明文的，同时包含CA 的签名

    4. 数字签名：首先 CA 使用 Hash 函数来计算极客时间提交的明文信息，并得出信息摘要；然后 CA 再使用它的私钥对信息摘要进行加密，加密后的密文就是 CA 颁给极客时间的数字签名。这就相当于房管局在房产证上盖的章，这个章是可以去验证的，同样我们也可以通过数字签名来验证是否是该 CA 颁发的。

  2. 浏览器如何验证数字证书？

    1. 采用 CA 签名时相同的 Hash 函数来计算并得到信息摘要 A；然后再利用对应 CA 的公钥解密签名数据，得到信息摘要 B；对比信息摘要 A 和信息摘要 B