详解前端网络安全xss攻击、CSRF攻击、DOS攻击、页面劫持四大防范

陈_杨
2,506 阅读14分钟

小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

本文同时参与 「掘力星计划」  ，赢取创作大礼包，挑战创作激励金

前言

前端在开发项目过程中其实很少对网络安全进行全程的防范，做项目规划也不会罗列开发计划中。所以导致现在的前端开发者对这块知识越来越薄弱，其实这块往往面试就经常问到，所以建议你多学学，说不定哪天就用上了

1. XSS

涉及的面试题 什么是XSS攻击？如何预防XSS攻击

1.1 基础简析

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

XSS攻击的危害包括：

1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号

2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

3、盗窃企业重要的具有商业价值的资料

4、非法转账

5、强制发送电子邮件

6、网站挂马

7、控制受害者机器向其它网站发起攻击

1.2 原因解析

主要原因： 过于信任客户端提交的数据!

解决办法: 不信任客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理后方可进行下一步的操作.

进一步分析:

客户端提交的数据本身就是应用所需的，但是恶心攻击者利用网站对客户端提提交数据的信任，在数据中插入一些符号以及JavaScript代码，那么这些数据就会成为应用代码中给的一部分了，那么攻击者就可以肆无忌惮的展开攻击

因此我们绝对不可信任任何客户端提交的数据

根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种

1.3 类型

1.3.1 存储型(持久性)

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

常见的场景以及案例：

案例：微博论坛等用户发帖、提交文章评论等地方

  1. 将恶意代码提交到数据库

  2. 数据库将其保存

  3. 他用户查看帖子或者评论

  4. 服务端返回恶意代码并被拼接到客户端页面

  5. 恶意代码可能通过自执行或者用户点击执行来弹出广告或者获取用户的cookie等个人隐私并上报到攻击者数据库

1.3.2 非持久型（反射型）

非持久型XSS是指发送请求时，XSS代码出现在请求的URL中，作为参数提交到服务器，服务器解析并响应。响应结果中包含XSS代码，最后浏览器解析并执行，从概念上可以看出，反射型XSS代码首先是出现在URL中，然后需要服务端解析，最后需要浏览器之后XSS代码才能攻击

常见的场景以及案例：

案例：带有诱导性的链接的按钮邮件等。

1.攻击者在一些链接的参数中加入恶意代码并诱导用户点击

2.用户通过点击将请求参数传入服务端

3.服务端获取参数并拼接返回给客户端

4.客户端执行恶意代码冒充用户进行权限操作或者盗取用户的cookie等个人隐私并上报攻击者数据库

1.3.3 DOM型攻击

DOM型和反射性都是通过诱导用户点击链接执行，并且都是临时型的，但是反射型属于服务端安全漏洞而DOM型属于客户端安全漏洞

常见的场景以及案例：

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

2.用户打开带有恶意代码的 URL。

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

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

1.4 防御方法

#### 通常有两种方式用来防御

1.4.1 转义字符

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

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

function escape(str) {
  str = str.replace(/&/g, '&')
  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
}

通过转义可以将攻击代码 变成

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

但是对于显示富文本来说，显然不能通过上面的办法来转义所有字符，因为这样会把需要的格式也过滤掉。对于这种情况，通常采用白名单过滤的办法，当然也可以通过黑名单过滤，但是考虑到需要过滤的标签和标签属性实在太多，更加推荐使用白名单的方式。

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)
1.4.2 CSP

内容安全策略 (CSP) 是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等。无论是数据盗取、网站内容污染还是散发恶意软件，这些攻击都是主要的手段

CSP 的主要目标是减少和报告 XSS 攻击 ，XSS 攻击利用了浏览器对于从服务器所获取的内容的信任。恶意脚本在受害者的浏览器中得以运行，因为浏览器信任其内容来源，即使有的时候这些脚本并非来自于它本该来的地方。

CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略所有的其他脚本 (包括内联脚本和HTML的事件处理属性)。

作为一种终极防护形式，始终不允许执行脚本的站点可以选择全面禁止脚本执行

CSP本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以进行加载和执行，我们只需要配置规则，如何拦截是由浏览器自己实现的，我们可以通过这种方式来尽量减少XSS攻击 开启CSP的方式(如果使用CSP) 1 你可以使用 Content-Security-Policy HTTP头部 来指定你的策略，像这样:

设置HTTP Header中的Content-Security-Policy: policy

2 设置meta标签的方式

meta http-equiv=“Content-Security-Policy” content=“default-src ‘self’; img-src https://*; child-src ‘none’;”>

常见用例(设置HTTP Header来举例)

  • 一个网站管理者想要所有内容均来自站点的同一个源 (不包括其子域名) 只允许加载本站资源

Content-Security-Policy: default-src ‘self’

  • 一个网站管理者允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)

Content-Security-Policy: default-src ‘self’ *.trusted.com

  • 一个网站管理者允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得)，所有脚本必须从特定主机服务器获取可信的代码.

Content-Security-Policy: default-src ‘self’; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

  • 只允许加载HTTPS协议图片

Content-Security-Policy: img-src https://*

  • 允许加载任何来源框架

Content-Security-Policy: child-src ‘none’

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

2. CSRF

面试题:什么是CSRF攻击？如何防范CSRF攻击

2.1 基础简析

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

2.2 原理

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

也就是完成一次CSRF攻击，受害者必须依次完成两个步骤:

  1. 登录受信任的网站，并在本地生成Cookie
  2. 在不登出信任网站的情况下，访问危险网站

你也许有疑问:如果我不满足以上两个条件中的一个，我就不会收到CSRF攻击。

的确如此，但是你不能保证以下情况的发生：

  1. 你不能保证你登录了一个网站后，不再打开一个tab页面并访问其他页面
  2. 你不能保证你关闭浏览器后，你的本地Cookie立刻过期，你的上次会话已经结束.(事实上，关闭浏览器不能结束一个会话，)

2.3 危害(CSRF可以做什么)

攻击者盗用了你身份，以你的名义发送恶意请求,CSRF能够做的事情:以你的名义发送邮件，盗取你的账号甚至是购买商品，虚拟货币的转账，个人隐私泄露和财产安全

2.4 类型

2.4.1 主动型攻击

  1. 受害者访问a.com并在自己浏览器留下a.com的登录态

  2. 攻击者诱导受害者访问三方网站b.com

  3. 三方网站b.com植有访问a.com接口的恶意代码（删除/增加/修改等）

  4. 受害者点击b.com时候，b.com带着a.com的登陆凭证冒充受害用户执行对a.com的恶意操作

2.4.2 被动型攻击

  1. 攻击者在a.com发布带有恶意链接的帖子或者评论（提交对a.com带有增删改的诱导型img/form/a标签）

  2. 当其他拥有登录态的受害者点击该评论的恶意链接冒用受害者登录凭证发起攻击

CSRF主要是冒用受害者登录凭证发起恶意的增删改并不会窃取受害者隐私信息

2.5 如何预防CSRF攻击

  1. 禁止三方网站获取cookie,比如设置Chrome的SameSite属性

弊端：SameSite试用阶段，兼容性不是很理想

  1. 服务端通过Referer Header 和 Origin Header来进行同源验证

弊端1：攻击者可以部分修改或者隐藏referer

弊端2: 某些浏览器或者操作会丢失origin头部，比如302重定向

弊端3：HTTPS页面跳转到HTTP页面，所有浏览器Referer都丢失。

弊端4：对于被动性攻击并不能识别

其他： 某些低版本浏览器对origin和referer并不是很稳定，各种意想不到的结果，极其不稳定

  1. 利用token来鉴别，三方跨站请求并不能获取到头部的token，本站的接口在请求前都会在请求头增加token用于身份鉴权，三方请求并不会携带token

弊端1：token鉴权对服务端压力较大，许专门开辟服务器用于token鉴权，耗费服务器成本并且增加请求时间

弊端2：对于页面ajax,fetch等异步请求外的其他请求如form提交，a链接等需要去挨个加token，不能形成统一的token增加入口，存在部分疏漏

相对而言token鉴权算是比较好的一种防护措施

  1. 利用双重cookie来认证，在每个请求的参数都附加scrfCookie='随机数'防御参数，并在cookie中混入该防御参数值，服务端将请求头部的cookie中防御cookie参数和请求参数所带的该参数进行比对

弊端： 前后分离的代码，后端接口和前端可能不同源，比如前端www.xx.com,后端接口为api.xx.com,前端要拿到后端接口域下的cookie必须将cookie都放在xx.com下面才能保证所有子域都可以拿到，这样反而增加xss攻击风险得不偿失

3. DOS攻击

3.1 基础简析

DOS攻击通过在网站的各个环节进行攻击，使得整个流程跑不起来，以达到瘫痪服务为目的。最常见的就是发送大量请求导致服务器过载宕机

3.2 防范措施

  • 扩容服务器【有钱公司玩的】
  • 进行实时监控，封禁某些恶意密集型请求IP段
  • 增加接口验证，对于某些敏感接口，进行单个IP访问次数限制
  • 进行静态资源缓存，隔离源文件的访问，比如CDN加速

4. 页面劫持

4.1 基础简析

攻击者通过请求的数据传输过程进行数据修改，或者对网站域名进行泛域名解析以重定向网站，在网站中注入广告等

4.2 类型

  1. 跳转型劫持，通过泛域名解析等将用户访问的页面打到其他网站，以进行恶意竞争，或者打到一些钓鱼网站进行用户个人利益和其他网站利益名誉侵害

  2. 注入型劫持，对于网站的请求资源进行拦截修改，加入恶意代码或者广告等

4.3 如何预防网络劫持

  • 最有效且暴力的直接换成HTTPS，建立安全通道
  • 进行漏洞监控，根据实际情况做出调整

5. 总结

点击劫持算是一种很多人不大关注的攻击，他需要诱使用户与页面进行交互，实施的攻击成本更高。另外开发者可能会觉得是用户犯蠢，不重视这种攻击方式。

番外篇：中间人攻击

涉及面试题:什么是中间人攻击?如何防范中间人攻击

中间人攻击（Man-in-the-MiddleAttack，简称“MITM攻击”）是一种“间接”的入侵攻击，这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间人”。

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

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

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

avatar
文章
阅读
粉丝