Fe-interview: 第 10 题：前端安全、中间人攻击

Created on 19 Jun 2020  ·  3Comments  ·  Source: lgwebdream/FE-Interview

欢迎在下方发表您的优质见解

滴滴 网络&安全
Source
picture lgwebdream
😄1

Most helpful comment

1）XSS：跨站脚本攻击

就是攻击者想尽一切办法将可以执行的代码注入到网页中。

存储型（server端）：
  • 场景：见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
  • 攻击步骤：

    • i）攻击者将恶意代码提交到目标网站的数据库中

    • ii）用户打开目标网站时，服务端将恶意代码从数据库中取出来，拼接在HTML中返回给浏览器

    • iii）用户浏览器在收到响应后解析执行，混在其中的恶意代码也同时被执行

    • iv）恶意代码窃取用户数据，并发送到指定攻击者的网站，或者冒充用户行为，调用目标网站的接口，执行恶意操作

      反射型（Server端）

与存储型的区别在于，存储型的恶意代码存储在数据库中，反射型的恶意代码在URL上

  • 场景：通过 URL 传递参数的功能，如网站搜索、跳转等。
  • 攻击步骤：

    • i）攻击者构造出特殊的 URL，其中包含恶意代码。

    • ii）用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。

    • iii）用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。

    • iv）恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

Dom 型(浏览器端）

DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

  • 场景：通过 URL 传递参数的功能，如网站搜索、跳转等。
  • 攻击步骤：

    • i）攻击者构造出特殊的 URL，其中包含恶意代码。

    • ii）用户打开带有恶意代码的 URL。

    • iii）用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。

    • iv）恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

预防方案：（防止攻击者提交恶意代码，防止浏览器执行恶意代码）
  • i）对数据进行严格的输出编码：如HTML元素的编码，JS编码，CSS编码，URL编码等等

    • 避免拼接 HTML；Vue/React 技术栈，避免使用 v-html / dangerouslySetInnerHTML

  • ii）CSP HTTP Header，即 Content-Security-Policy、X-XSS-Protection

    • 增加攻击难度，配置CSP(本质是建立白名单，由浏览器进行拦截)

    • Content-Security-Policy: default-src 'self'-所有内容均来自站点的同一个源（不包括其子域名）

    • Content-Security-Policy: default-src 'self' *.trusted.com-允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)

    • Content-Security-Policy: default-src https://yideng.com-该服务器仅允许通过HTTPS方式并仅从yideng.com域名来访问文档

  • iii）输入验证：比如一些常见的数字、URL、电话号码、邮箱地址等等做校验判断
  • iv）开启浏览器XSS防御：Http Only cookie，禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
  • v）验证码

2）CSRF：跨站请求伪造

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

攻击流程举例
  • i）受害者登录 a.com，并保留了登录凭证（Cookie）
  • ii）攻击者引诱受害者访问了b.com
  • iii）b.com 向 a.com 发送了一个请求：a.com/act=xx浏览器会默认携带a.com的Cookie
  • iv）a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
  • v）a.com以受害者的名义执行了act=xx

  • vi）攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作

    攻击类型

  • i）GET型：如在页面的某个 img 中发起一个 get 请求

  • ii）POST型：通过自动提交表单到恶意网站
  • iii）链接型：需要诱导用户点击链接
    预防方案：

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。）

  • i）同源检测：通过Header中的Origin Header 、Referer Header 确定，但不同浏览器可能会有不一样的实现，不能完全保证
  • ii）CSRF Token 校验：将CSRF Token输出到页面中（通常保存在Session中），页面提交的请求携带这个Token，服务器验证Token是否
    正确
  • iii）双重cookie验证：

    • 流程：

    • 步骤1：在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）

    • 步骤2：在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）

    • 步骤3：后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。

    • 优点：

    • 无需使用Session，适用面更广，易于实施。

    • Token储存于客户端中，不会给服务器带来压力。

    • 相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。

    • 缺点：

      -Cookie中增加了额外的字段。

      -如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。

      -难以做到子域名的隔离。

      -为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。

  • iv）Samesite Cookie属性：Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，Strict 为任何情况下都不可以作为第三方 Cookie ，Lax 为可以作为第三方 Cookie , 但必须是Get请求

3）iframe 安全

说明：
  • i）嵌入第三方 iframe 会有很多不可控的问题，同时当第三方 iframe 出现问题或是被劫持之后，也会诱发安全性问题
  • ii）点击劫持

    • 攻击者将目标网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，诱导用户点击。

  • iii）禁止自己的 iframe 中的链接外部网站的JS

    预防方案：

  • i）为 iframe 设置 sandbox 属性，通过它可以对iframe的行为进行各种限制，充分实现“最小权限“原则

  • ii）服务端设置 X-Frame-Options Header头，拒绝页面被嵌套，X-Frame-Options 是HTTP 响应头中用来告诉浏览器一个页面是否可以嵌入