前端小江

Appearance

回到顶部
On this page

跨域只存在于浏览器端,因为浏览器的同源策略产生了跨域，http 默认 80 端口，https 默认 443

同源策略

  • ajax 同源策略:
  1. DOM 层面：不同源站点之间不能相互访问和操作 DOM
  2. 数据层面：不能获取不同源站点的 Cookie、LocalStorage、indexDB 等数据
  3. 网络层面：不能通过 XMLHttpRequest 向不同源站点发送请求

解决方案：

  • jsonp
  • document.domain + iframe
  • location.hash + iframe
  • window.name + iframe
  • postMessage
  • 跨域资源共享（CROS）
  • nginx 代理
  • nodejs 中间件代理
  • webSocket 协议

预检请求

在发出跨域请求时，如果是非简单请求， 浏览器会自动帮你先发出一个 OPTIONS 查询请 求，称为预检， 用于确认目标资源是否支持跨域，允许后才发送在简单请求必须满足两 个条件：

  1. 使用的方法必须是（之一）：head，get，post
  2. 请求的 header 是： Accept， Accept-Language， Content-Language， Content-Type: 只限于三个值 ：application/x-www-form-urlencoded、multipart/form-data、text/plain

我们经常用的 post+ Content-Type=application/json 也属于非简单请求，这个时候可以 让服务器端设置 Access-Control-Max-Age 字段，这样在缓存未到期时间内，只会发起一次 option 请求

减少 CORS 预请求的次数

方案一：发出简单请求

方案二：服务端设置 Access-Control-Max-Age 字段，在有效时间内浏览器无需再为同一个 请求发送预检请求。但是它有局限性：只能为同一个请求缓存，无法针对整个域或者模糊匹 配 URL 做缓存

XSS

XSS 简单点来说，就是攻击者想尽一切办法将可以执行的代码注入到网页中。

分为持久型和非持久型。

持久型

持久型也就是攻击的代码被服务端写入进数据库中，这种攻击危害性很大，因为如果网 站访问量很大的话，就会导致大量正常访问页面的用户都受到攻击

例子：
对于评论功能来说，就得防范持久型 XSS 攻击，因为我可以在评论中输入以下 内容

img

这种情况如果前后端没有做好防御的话，这段评论就会被存储到数据库中，这样每个打开该 页面的用户都会被攻击到。

非持久型

一般通过修改 URL 参数的方式加入攻击代码，诱导用户访问链接从而进行攻击。

例子：
如果页面需要从 URL 中获取某些参数作为内容的话，不经过过滤就会导致攻击 代码被执行

<!-- http://www.domain.com?name=<script>alert(1)</script> -->
<div>{{name}}</div>

但是对于这种攻击方式来说，如果用户使用 Chrome 这类浏览器的话，浏览器就能自动帮助 用户防御攻击。但是我们不能因此就不防御此类攻击了，因为我不能确保用户都使用了该类 浏览器。

img

防御

转义字符

首先，对于用户的输入应该是永远不信任的。最普遍的做法就是转义输入输出的内容，对于 引号、尖括号、斜杠进行转义

function escape(str) {
  str = str.replace(/&/g, '&amp;')
  str = str.replace(/</g, '&lt;')
  str = str.replace(/>/g, '&gt;')
  str = str.replace(/"/g, '&quto;')
  str = str.replace(/'/g, '&#39;')
  str = str.replace(/`/g, '&#96;')
  str = str.replace(/\//g, '&#x2F;')
  return str
}

通过转义可以将攻击代码 <script>alert(1)</script> 变成

escape('<script>alert(1)</script>')
// -> &lt;script&gt;alert(1)&lt;&#x2F;script&gt;

但是对于显示富文本来说，推荐使用白名单过滤的方式。

const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
// -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
console.log(html)

以上示例使用了 js-xss 来实现，可以看到在输出中保留了 h1 标签且过滤了 script 标 签。

CSP

CSP 本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以加载和执行。 我们只需要配置规则，如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击。

通常可以通过两种方式来开启 CSP：

  • 设置 HTTP Header 中的 Content-Security-Policy
  • 设置 meta 标签的方式 <meta http-equiv="Content-Security-Policy">

这里以设置 HTTP Header 来举例

  • 只允许加载本站资源
Content-Security-Policy: default-src ‘self’
  • 只允许加载 HTTPS 协议图片
Content-Security-Policy: img-src https://*
  • 允许加载任何来源框架
Content-Security-Policy: child-src 'none'

当然可以设置的属性远不止这些，你可以通过查阅 文档 的方式来学习。

对于这种方式来说，只要开发者配置了正确的规则，那么即使网站存在漏洞，攻击者也不能 执行它的攻击代码，并且 CSP 的兼容性也不错。

img

CSRF

CSRF 中文名为跨站请求伪造。原理就是攻击者构造出一个后端请求地址，诱导用户点 击或者通过某些途径自动发起请求。如果用户是在登录状态下的话，后端就以为是用户在 操作，从而进行相应的逻辑。

例子
举个例子，假设网站中有一个通过 GET 请求提交用户评论的接口，那么攻击者就 可以在钓鱼网站中加入一个图片，图片的地址就是评论接口

<img src="http://www.domain.com/xxx?comment='attack'"/>

那么你是否会想到使用 POST 方式提交请求是不是就没有这个问题了呢？其实并不是，使用 这种方式也不是百分百安全的，攻击者同样可以诱导用户进入某个页面，在页面中通过表单 提交 POST 请求。

防御

防范 CSRF 攻击可以遵循以下几种规则：

  • Get 请求不对数据进行修改
  • 不让第三方网站访问到用户 Cookie
  • 阻止第三方网站请求接口
  • 请求时附带验证信息，比如验证码或者 Token
  • SameSite：可以对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送，可以很大程度减少 CSRF 的攻击，但是该属性目前并不是所有浏 览器都兼容。
  • 验证 Referer: 对于需要防范 CSRF 的请求，我们可以通过验证 Referer 来判断该请求 是否为第三方网站发起的。

点击劫持

点击劫持是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过 iframe 嵌套的方式 嵌入自己的网页中，并将 iframe 设置为透明，在页面中透出一个按钮诱导用户点击。

img

对于这种攻击方式，推荐防御的方法有两种。

X-FRAME-OPTIONS

X-FRAME-OPTIONS 是一个 HTTP 响应头，在现代浏览器有一个很好的支持。这个 HTTP 响 应头 就是为了防御用 iframe 嵌套的点击劫持攻击。

该响应头有三个值可选，分别是

  • DENY，表示页面不允许通过 iframe 的方式展示
  • SAMEORIGIN，表示页面可以在相同域名下通过 iframe 的方式展示
  • ALLOW-FROM，表示页面可以在指定来源的 iframe 中展示

JS 防御

对于某些远古浏览器来说，并不能支持上面的这种方式，那我们只有通过 JS 的方式来防御 点击劫持了。

<head>
  <style id="click-jack">
    html {
      display: none !important;
    }
  </style>
</head>
<body>
  <script>
    if (self == top) {
      var style = document.getElementById('click-jack')
      document.body.removeChild(style)
    } else {
      top.location = self.location
    }
  </script>
</body>

以上代码的作用就是当通过 iframe 的方式加载页面时，攻击者的网页直接不显示所有内容 了。

中间人攻击

中间人攻击是攻击方同时与服务端和客户端建立起了连接，并让对方认为连接是安全的， 但是实际上整个通信过程都被攻击者控制了。攻击者不仅能获得双方的通信信息，还能修 改通信信息。

通常来说不建议使用公共的 Wi-Fi，因为很可能就会发生中间人攻击的情况。如果你在通 信的过程中涉及到了某些敏感信息，就完全暴露给攻击方了。

当然防御中间人攻击其实并不难，只需要增加一个安全通道来传输信息 。HTTPS 就可以用来防御中间人攻击，但是并不是说使用了 HTTPS 就可以高枕无忧了， 因为如果你没有完全关闭 HTTP 访问的话，攻击方可以通过某些方式将 HTTPS 降级为 HTTP 从而实现中间人攻击。