持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第5天，点击查看活动详情

随着互联网的日益壮大，我们已经离不开网络了，网络安全法也早已在2017年6月1日开始实施。 信息安全越来越重要，而网络安全也是非常庞大，这篇文章用前端的角度，以浏览器安全为载体，讲述前端安全。

前端安全

本文将从前端安全作为起点，先列出黑客有可能在前端做出的攻击手段，然后再分别列出前端反制措施。本文主要有以下几点：

• 几种前端攻击手段
• 阻止 XSS 攻击
• 阻止 CSRF 攻击
• 阻止中间人攻击

前端攻击手段

XSS/XSRF :

XSS指的是跨站脚本攻击（Cross Site Script），因为缩写与CSS相同，所以跨站脚本攻击缩写用的XSS。跨站脚本攻击分为两种类型，分别是非持久型攻击和持久型攻击，其原理是利用用户对某个指定网站的信任，被恶意用户进行了web攻击(通常这种攻击会利用js实现)。

• 非持久型攻击
  • 反射型（Server端）场景：
    • 攻击者构造出特殊的 URL，其中包含恶意代码。
    • 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
    • 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
    • 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
  • Dom 型(浏览器端）场景：
    • 攻击者构造出特殊的 URL，其中包含恶意代码。
    • 用户打开带有恶意代码的 URL。
    • 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
    • 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
• 持久型攻击
  • 攻击者将恶意代码提交到目标网站的数据库中
  • 用户打开目标网站时，服务端将恶意代码从数据库中取出来，拼接在HTML中返回给浏览器
  • 用户浏览器在收到响应后解析执行，混在其中的恶意代码也同时被执行
  • 恶意代码窃取用户数据，并发送到指定攻击者的网站，或者冒充用户行为，调用目标网站的接口，执行恶意操作

CSRF :

CSRF是跨站请求伪造，和XSS不同，这个执行环境在黑客那边，主要是通过cookie等手段，拿到攻击对象的信息后，再冒充攻击对象给服务器发送信息。

• 受害者登录目标网站A。
• 受害者以某种方式接触到恶意网站B的链接。
• 受害者点击链接访问网站B, 网站B中的js代码执行, 偷偷向目标网站A发送某个请求。
• 由于受害者登录过网站A, 因此请求携带了网站A的相关cookie凭证，最后请求成功执行。

XS-Leaks :

XS-Leaks是跨站数据泄漏攻击，使恶意网站能够在访问者不知情的情况下在后台与其他网站交互时从访问者那里收集个人数据，新类别的漏洞也不同于跨站点请求伪造 ( CSRF ) 攻击，后者利用Web应用程序对浏览器客户端的信任来代表用户执行意外操作，它们可以被武器化为推断有关用户的信息。

• 清空HTTP缓存资源。
• 使攻击者访问恶意页面。其中恶意页面需要加载受害者在某社交媒体平台的照片。该照片会保存在HTTP缓存中，并以受害者用户名命名。
• 使攻击者访问恶意页面，然后需要加载/tim.png的照片出来，但是由于本地缓存没有，因此无法加载；然后需要加载/alice.png的照片，由因为刚好是Alice，因此加载成功。
• 看到加载成功的结果，攻击者可以断定，受害人是Alice。

请求劫持 :

请求劫持指的是DNS服务器(DNS解析各个步骤)被篡改，修改了域名解析的结果，使得访问到的不是预期的ip，相当于给攻击对象加了一层代理，当攻击对象访问目标页面时，就会被代理到黑客准备好的网站。

中间人攻击 :

中间人攻击指的是使用HTTPS的页面，在HTTPS加密过程中，在客户端和服务端中间，插入了黑客。

阻止 XSS 攻击

我们知道持久型攻击和非持久型攻击都是需要经过 Web 服务器来处理的，因此可以认为这两种类型的漏洞是服务端的安全漏洞。

而基于 DOM 的 XSS 攻击全部都是在浏览器端完成的，因此基于 DOM 的 XSS 攻击是属于前端的安全漏洞。但无论是何种类型的 XSS 攻击，它们都有一个共同点，那就是首先往浏览器中注入恶意脚本，然后再通过恶意脚本将用户信息发送至黑客部署的恶意服务器上。所以要阻止 XSS 攻击，我们可以通过阻止恶意 JavaScript 脚本的注入和恶意消息的发送来实现。接下来我们就来看看一些常用的阻止 XSS 攻击的策略。

• 服务器对输入脚本进行过滤或转码
  • 不管是反射型还是存储型 XSS 攻击，我们都可以在服务器端将一些关键的字符进行转码
• 充分利用 CSP
  • 限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的
  • 禁止向第三方域提交数据，这样用户数据也不会外泄
  • 禁止执行内联脚本和未授权的脚本
  • 还提供了上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题
• 使用 Cookie 的 HttpOnly 属性
  • 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
• 验证码
  • 加一道验证环节，将黑客挡在验证外

阻止 CSRF 攻击

上面说 CSRF 攻击是通过获取用户 Cookie 去实现的。那我们首先就要考虑在 Cookie 上来做文章。

充分利用好 Cookie 的 SameSite 属性，当一些关键的 Cookie 设置为 Strict 或者 Lax 模式，这样在跨站点请求时，这些关键的 Cookie 就不会被发送到服务器，从而使得黑客的 CSRF 攻击失效。

除了Cookie之外，还可以验证请求的来源站点。

通过在 HTTP 请求头中 Referer 和 Origin，验证该 HTTP 请求的来源地址，就可以阻止第三方应用请求服务器了。

除了使用以上两种方式来防止 CSRF 攻击之外，还可以采用 CSRF Token 来验证，这个流程比较好理解，大致分为两步

• 在浏览器向服务器发起请求时，服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的字符串，然后将该字符串植入到返回的页面中
• 在浏览器端如果要发起转账的请求，那么需要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求，那么将无法获取到 CSRF Token 的值，所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求

阻止 中间人攻击

在讲阻止中间人攻击之前，我们要先了解下 HTTPS 是如何加密传输的，这里简单描述下 HTTPS 的非对称加密与对称加密的协作，与 HTTPS 的加密过程。先来看下面这张图

在 HTTPS 请求的时候，先基于 HTTP 协议进行连接，也就是说该有的 TCP 那些都会有，就是在 HTTP 连接之后，加了一个 SSL 协议，这个协议是加密和验证应用程序(如浏览器)和 Web 服务器之间发送的数据的协议。

• 客户端先发起请求
• 服务端响应请求，并带上 CA 证书与公钥，（注意：服务端此时用的加密方式是非对称加密）
• 客户端去权威证书机构验证证书
• 验证成功后，客户端取出服务端给的公钥，和一个随机码，生成出一个新的密文
• 将密文传输给服务端，服务端使用私钥解密
• 这时服务端和客户端同时有相同的秘钥，他们就可以通过这个秘钥，运用对称加密的方式去传输密文

那我们怎么阻止中间人攻击呢，就是我们使用正规的 CA 证书机构，因为那些大型的正规的证书机构会定时和浏览器同步证书，如果有中间人冒充证书机构，浏览器商就会发现，这样黑客就无机可乘了。

最后，让我们一起加油吧！