网络安全与常见攻击形式

常见web安全攻防

网站安全的重要性大家能达成一致意见，作为web作业人员必须的在设计和开发的过程中考虑安全问题，并且能有效防御。这篇文章主要的内容就是分析几种常见的攻击的类型以及防御的方法。

服务器

之前听说朋友公司服务器使用windows系统，我大吃一惊，因为windows是用户交互系统，图形界面就需要占很多内存，而且稳定性不足，你windows电脑要是一个月不关机重启一定卡的要死。所以以下几点很关键：

• Linux系统

服务器多数使用linux或Unix系统，Linux是一套免费使用和自由传播的类Unix操作系统，是一个基于POSIX和Unix的多用户、多任务、支持多线程和多CPU的操作系统。Linux继承了Unix以网络为核心的设计思想，是一个性能稳定的多用户网络操作系统。

• 安全组

若想你的web服务提供给外界，那么你的服务器必须得开启一个开放端口，http服务的默认是80端口，https服务的默认是443端口。那么为了你的服务器安全，就别开放太多端口给外界，如果你全部开放，服务器被攻破的可能性就很大了。

• nginx

既然不能开放很多端口，那么如何部署多个服务呢，使用成熟的nginx进行代理。Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。Nginx作为负载均衡服务：Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务，也可以支持作为 HTTP代理服务对外进行服务。Nginx采用C进行编写，不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多。

• https

HTTPS，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。将nginx与https结合，服务在数据会话时将会得到加密，就算被劫持，黑客也无法将其解密出来。

XSS

XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。总结：————利用用户对网站的信任来攻击

• 非持久型 XSS

非持久型 XSS 漏洞，也叫反射型 XSS 漏洞，一般是通过给别人发送带有恶意脚本代码参数的 URL，当 URL 地址被打开时，特有的恶意代码参数被 HTML 解析、执行。

非持久型 XSS 漏洞攻击有以下几点特征 :

1 . 即时性，不经过服务器存储，直接通过 HTTP 的 GET 和 POST 请求就能完成一次攻击，拿到用户隐私数据
2 . 攻击者需要诱骗点击
3 . 反馈率低，所以较难发现和响应修复
4 . 盗取用户敏感保密信息

为了防止出现非持久型 XSS 漏洞，需要确保这么几件事情 :

1 . Web 页面渲染的所有内容或者渲染的数据都必须来自于服务端。
2 . 尽量不要从 URL，document.referrer，document.forms 等这种 DOM API 中获取数据直接渲染。
3 . 尽量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.creteElement() 等可执行字符串的方法。
4 . 如果做不到以上几点，也必须对涉及 DOM 渲染的方法传入的字符串参数做 escape 转义。(其实vue，react这些框架就做到了，要执行html必须的使用v-html才行，直接写在模板中就只是文本)
5 . 前端渲染的时候对任何的字段都需要做 escape 转义编码。(escape 转义的目的是将一些构成 HTML 标签的元素转义，比如 <，>，空格 等，转义成 <，>，  等显示转义字符。)

• 持久型 XSS

持久型 XSS 漏洞，也被称为存储型 XSS 漏洞，一般存在于 Form 表单提交等交互功能，如发帖留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行。

主要注入页面方式和非持久型 XSS 漏洞类似，只不过持久型的不是来源于 URL，refferer，forms 等，而是来源于后端从数据库中读出来的数据。持久型 XSS 攻击不需要诱骗点击，黑客只需要在提交表单的地方完成注入即可，但是这种 XSS 攻击的成本相对还是很高。

攻击成功需要同时满足以下几个条件 :

1 . POST 请求提交表单后端没做转义直接入库。
2 . 后端从数据库中取出数据没做转义直接输出给前端。
3 . 前端拿到后端数据没做转义直接渲染成 DOM。

持久型 XSS 有以下几个特点 :

1 . 持久性，植入在数据库中
2 . 危害面广，甚至可以让用户机器变成 DDoS 攻击的肉鸡。
3 . 盗取用户敏感私密信息

为了防止持久型 XSS 漏洞，需要前后端共同努力 :

1 . 后端在入库前应该选择不相信任何前端数据，将所有的字段统一进行转义处理。
2 . 后端在输出给前端数据统一进行转义处理。
3 . 前端在渲染页面 DOM 的时候应该选择不相信任何后端数据，任何字段都需要做转义处理。

• 基于字符集的 XSS

其实现在很多的浏览器以及各种开源的库都专门针对了 XSS 进行转义处理，尽量默认抵御绝大多数 XSS 攻击，但是还是有很多方式可以绕过转义规则，让人防不胜防。比如「基于字符集的 XSS 攻击」就是绕过这些转义处理的一种攻击方式，比如有些 Web 页面字符集不固定，用户输入非期望字符集的字符，有时会绕过转义过滤规则。

以基于 utf-7 的 XSS 为例，utf-7 是可以将所有的 unicode 通过 7bit 来表示的一种字符集 (但现在已经从 Unicode 规格中移除)。这个字符集为了通过 7bit 来表示所有的文字, 除去数字和一部分的符号,其它的部分将都以 base64 编码为基础的方式呈现。

<script>alert("xss")</script>
可以被解释为：
+ADw-script+AD4-alert(+ACI-xss+ACI-)+ADw-/script+AD4-

可以形成「基于字符集的 XSS 攻击」的原因是由于浏览器在 meta 没有指定 charset 的时候有自动识别编码的机制，所以这类攻击通常就是发生在没有指定或者没来得及指定 meta 标签的 charset 的情况下。

避免这种 XSS：

1 . 记住指定 <meta charset="utf-8">
2 . XML 中不仅要指定字符集为 utf-8，而且标签要闭合

• 基于 Flash 的跨站 XSS

基于 Flash 的跨站 XSS 也是属于反射型 XSS 的一种，虽然现在开发 ActionScript 的产品线几乎没有了，但还是提一句吧，AS 脚本可以接受用户输入并操作 cookie，攻击者可以配合其他 XSS（持久型或者非持久型）方法将恶意 swf 文件嵌入页面中。主要是因为 AS 有时候需要和 JS 传参交互，攻击者会通过恶意的 XSS 注入篡改参数，窃取并操作cookie。

避免方法 :

1 . 严格管理 cookie 的读写权限
2 . 对 Flash 能接受用户输入的参数进行过滤 escape 转义处理

• 未经验证的跳转 XSS

有一些场景是后端需要对一个传进来的待跳转的 URL 参数进行一个 302 跳转，可能其中会带有一些用户的敏感（cookie）信息。如果服务器端做302 跳转，跳转的地址来自用户的输入，攻击者可以输入一个恶意的跳转地址来执行脚本。

防止这类漏洞 :

1 . 对待跳转的 URL 参数做白名单或者某种规则过滤
2 . 后端注意对敏感信息的保护, 比如 cookie 使用来源验证。

CSRF

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。总结：————利用网站对用户的信任来攻击

那么 CSRF 到底能够干嘛呢？你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。

所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。

可以理解为有一个小偷在你配钥匙的地方得到了你家的钥匙，然后拿着要是去你家想偷什么偷什么。

• CSRF 攻击必须要的条件

CSRF 攻击必须要有三个条件 :

1 . 用户已经登录了站点 A，并在本地记录了 cookie
2 . 在用户没有登出站点 A 的情况下（也就是 cookie 生效的情况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。
3 . 站点 A 没有做任何 CSRF 防御

你也许会问：「如果我不满足以上三个条件中的任意一个，就不会受到 CSRF 的攻击」。其实可以这么说的，但你不能保证以下情况不会发生 :

1 . 你不能保证你登录了一个网站后，不再打开一个 tab 页面并访问另外的网站，特别现在浏览器都是支持多 tab 的。
2 . 你不能保证你关闭浏览器了后，你本地的 cookie 立刻过期，你上次的会话已经结束。
3 . 上图中所谓的攻击网站 B，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

• 预防 CSRF

CSRF 的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的 CSRF 防御也都在服务端进行。主要从以下两个方面入手 :

1 . 正确使用 GET，POST 请求和 cookie
2 . 在非 GET 请求中增加 token

我们一般都是按照如下规则设计应用的请求：

1 . GET 请求常用在查看，列举，展示等不需要改变资源属性的时候（数据库 query 查询的时候）
2 . POST 请求常用在 From 表单提交，改变一个资源的属性或者做其他一些事情的时候（数据库有 insert、update、delete 的时候）

现在restful-api盛行，不同的操作都有不同的请求方式：
查询 GET
更新 PUT
新建 Post
删除 Delete

现在都是用户登录获取token，其他业务接口都是需要用户带上token在请求头中才能访问的，不然会被中间件拦截，都无法进入到控制器。

SQL 注入

SQL 注入漏洞（SQL Injection）是 Web 开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。

而造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入，使攻击者成功的向服务器提交恶意的 SQL 查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。

很多 Web 开发者没有意识到 SQL 查询是可以被篡改的，从而把 SQL 查询当作可信任的命令。殊不知，SQL 查询是可以绕开访问控制，从而绕过身份验证和权限检查的。更有甚者，有可能通过 SQL 查询去运行主机系统级的命令。

• SQL注入的简单案例

密码验证的接口根据输入的用户名和密码查询数据表，如果查到用户记录的话，则认证通过。

let sql = "SELECT * " +
      "FROM t_user "+
      "WHERE username='"+userName+"' " +
      "AND pwd='"+password+"'";

访问ERP系统（对密码输入框进行SQL注入）

1）用户名输入：随便输。 2）密码输入：’ OR ‘1’='1

实际执行的sql语句如下：

SELECT * FROM t_user WHERE username='1qwerwterrt' AND pwd='' OR '1'='1';

所以 OR ‘1’='1 就成了万能密码，解决这个问题的话就是对密码进行加密，现在后端项目开发的话也不会去写sql语句了，都是建model，使用orm，也会对sql语句进行加密、过滤

DDOS攻击

• 什么是DDOS攻击？

DDOS攻击全称为：分布式拒绝服务攻击，是指击者利用大量“肉鸡”对攻击目标发动大量的正常或非正常请求、耗尽目标主机资源或网络资源，从而使被攻击的主机不能为合法用户提供服务。

DDOS攻击的本质是：利用木桶原理，寻找利用系统应用的瓶颈；阻塞和耗尽；当前问题：用户的带宽小于攻击的规模，噪声访问带宽成为木桶的短板。

其实cc攻击也属于ddos攻击的一种。对于这类的攻击，用软硬件结合的方式来防御是最有效的。单独 防御都是蛮吃力的

CC攻击

• 什么是CC攻击？

CC攻击时一种以网站页面为攻击目标的应用层攻击，攻击时选择服务器开放的页面中需要较多资源开销的应用。例如占用大量CPU资源进行运算或需要大量访问数据库的应用。主要是以.asp、.jsp、.php、.cgi等结尾的页面资源。

在CC防护上，经济实力好的可以选择购买DDOS高防设备，因为CC攻击也属于DDOS攻击的一种。经济实力一般，可以考虑安装防护软件。安全狗或者360网站卫士。个人趋向于安全狗，同时安装服务器安全狗和网站安全狗可以有效地防护CC攻击。可以有效地防止服务器因为受到CC攻击而产生CPU使用率100%的情况出现。

• CC攻击特点

1 . CC攻击来的IP都是真实的，分散的；
2 . CC攻击的数据包都是正常的数据包；
3 . CC攻击的请求，全都是有效的请求，无法拒绝的请求；
4 . 因为cc攻击的是网页，服务器什么都可以连接，ping也没问题，但是网页就是访问不；
5 . 但是iis一开服务器一会就死，而且被攻击后就老丢包。不知道是不是cc攻击，syn 攻击频率才78ack攻击频率663.

• DDOS攻击和CC攻击的区别？

CC攻击是DDOS（分布式拒绝服务）的一种，相比其它的DDOS攻击CC似乎更有技术含量一些。这种攻击你见不到真实源IP，见不到特别大的异常流量，但造成服务器无法进行正常连接。最让站长们忧虑的是这种攻击技术含量低，利用更换IP代理工具和一些IP代理一个初、中级的电脑水平的用户就能够实施攻击。因此，大家有必要了解CC攻击的原理及如果发现CC攻击和对其的防范措施。

• CC攻击的防护

对于CC攻击．其防御必须采用多种方法，而这些方法本质上也是在提高服务器的并发能力。

• 1、服务器垂直扩展和水平扩容

资金允许的情况下，这是最简单的一种方法，本质上讲，这个方法并不是针对CC攻击的，而是提升服务本身处理并发的能力，但确实提升了对CC攻击的承载能力。垂直扩展：是指增加每台服务器的硬件能力，如升级CPU、增加内存、升级SSD固态硬盘等。水平扩容：是指通过增加提供服务的服务器来提升承载力。上述扩展和扩容可以在服务的各个层级进行，包括：应用服务器、数据库服务器和缓存服务器等等。

• 2、数据缓存(内存级别，不要用文件)

对于服务中具备高度共性，多用户可重用，或单用户多次可重用的数据，一旦从数据库中检索出，或通过计算得出后，最好将其放在缓存中，后续请求均可直接从缓存中取得数据，减轻数据库的检索压力和应用服务器的计算压力，并且能够快速返回结果并释放进程，从而也能缓解服务器的内存压力。要注意的是，缓存不要使用文件形式，可以使用redis、mem—cached等基于内存的nosql缓存服务，并且与应用服务器分离，单独部署在局域网内。局域网内的网络IO肯定比起磁盘IO要高。为了不使局域网成为瓶颈，千兆网络也是有必要的。

• 3、页面静态化

与数据缓存一样，页面数据本质上也属于数据，常见的手段是生成静态化的html页面文件，利用客户端浏览器的缓存功能或者服务端的缓存服务，以及CDN节点的缓冲服务，均可以降低服务器端的数据检索和计算压力，快速响应结果并释放连接进程。

• 4、用户级别的调用频率限制

不管服务是有登陆态还是没登陆态，基于session等方式都可以为客户端分配唯一的识别ID(后称作SID)，服务端可以将SID存到缓存中。当客户端请求服务时，如果没有带SID(cookie中或请求参数中等)，则由服务端快速分配一个并返回。可以的话，本次请求可以不返回数据，或者将分配SID独立出业务服务。当客户端请求时带了合法SID(即SID能在服务端缓存中匹配到)，便可以依据SID对客户端进行频率限制。而对于SID非法的请求，则直接拒绝服务。相比根据IP进行的频率限制，根据SID的频率限制更加精准可控，可最大程度地避免误杀隋况。

• 5、IP限制
  最后，IP限制依然可以结合上述规则一起使用，但是可以将其前置至)JCb层的防火墙或负载均衡器上去做，并且可以调大限制的阈值，防止恶意访问穿透到应用服务器上，造成应用服务器压力。

恶意爬虫

像百度这样的搜索引擎都是利用爬虫获取网络信息，然后从这些数据中分析出相关的内容。由此还衍生除了seo这个职业，为了让自己的网站能在搜索上排在前面，需要seo做很多优化。除此之外，爬虫还被利用到了很多地方，像一般的抢票软件，偷别人数据的黑手。

假如现在自己的服务被别人用爬虫每1分钟爬取一次（还是比较良心的了），一个这样干的人还好，要是一千个呢，甚至成千上万，那就会造成服务器的压力，解决这种问题多有以下方法：

• 针对搜索引擎的爬虫

搜索引擎还是很正规的，所以他们的爬虫还是遵循robots协议————robots是网站跟爬虫间的协议，用简单直接的txt格式文本方式告诉对应的爬虫被允许的权限，也就是说robots.txt是搜索引擎中访问网站的时候要查看的第一个文件。可以配置文件来禁止他们爬取，当一个搜索蜘蛛访问一个站点时，它会首先检查该站点根目录下是否存在robots.txt，如果存在，搜索机器人就会按照该文件中的内容来确定访问的范围；如果该文件不存在，所有的搜索蜘蛛将能够访问网站上所有没有被口令保护的页面。

• 针对单ip的恶意开发者

有的开发者需要数据，但是自己又生产不出来，那怎么办，爬取别人的了，而且还定时任务的去操作，甚至还会把频率调的很高，为了保证数据的最新状态。针对这类人可以使用nginx来做ip限流，如果你觉得这样还是对他们太好了，可以在服务中封ip。将用户的真实ip存库，定期查看异常的ip将其封掉，还能制定自己的筛选算法。

• 针对技术雄厚的大公司，就爬取一次

有的小公司也有自己的过人之处，每个公司都有自己一块独有的领域，大公司一般啥都要做，但是没深入的行业前期就会抄别人，甚至偷别人的成果，想之前公司被某讯大公司投了内容，放到自己的平台。（1）这种情况，可以通过维权。当然，一个技术人员怎么能说这种话，当然是可以对接口数据加密，如果已经使用了https那基本就很安全了，可以对数据进行二次加密。

网络劫持攻击

很多的时候，我们的网站不是直接就访问到我们的服务器上的，中间会经过很多层代理，如果在某一个环节，数据被中间代理层的劫持者所截获，他们就能获取到使用你网站的用户的密码等保密数据。比如，我们的用户经常会在各种饭馆里面，连一些奇奇怪怪的wifi，如果这个wifi是黑客所建立的热点wifi，那么黑客就可以结果该用户收发的所有数据。这里，建议站长们网站都使用https进行加密。这样，就算网站的数据能被拿到，黑客也无法解开。

如果你的网站还没有进行https加密的化，则在表单提交部分，最好进行非对称加密–即客户端加密，只有服务端能解开。这样中间的劫持者便无法获取加密内容的真实信息了。

控制台注入代码

不知道各位看官有没有注意到天猫官网控制台的警告信息，如下图所示，这是为什么呢？因为有的黑客会诱骗用户去往控制台里面粘贴东西（欺负小白用户不懂代码），比如可以在朋友圈贴个什么文章，说:"只要访问天猫，按下F12并且粘贴以下内容，则可以获得xx元礼品"之类的，那么有的用户真的会去操作，并且自己隐私被暴露了也不知道。

天猫这种做法，也是在警告用户不要这么做，看来天猫的前端安全做的也是很到位的。不过，这种攻击毕竟是少数，所以各位看官看一眼就行，如果真的发现有的用户会被这样攻击的话，记得想起天猫的这种解决方案。

钓鱼

钓鱼也是一种非常古老的攻击方式了，其实并不太算前端攻击。可毕竟是页面级别的攻击，我们也来一起聊一聊。我相信很多人会有这样的经历，QQ群里面有人发什么兼职啦、什么自己要去国外了房子车子甩卖了，详情在我QQ空间里啦，之类的连接。打开之后发现一个QQ登录框，其实一看域名就知道不是QQ，不过做得非常像QQ登录，不明就里的用户们，就真的把用户名和密码输入了进去，结果没登录到QQ，用户名和密码却给人发过去了。

这种钓鱼方式比较有意思，重点在于我们比较难防住这种攻击，我们并不能将所有的页面链接都使用js打开。所以，要么就将外链跳转的连接改为当前页面跳转，要么就在页面unload的时候给用户加以提示，要么就将页面所有的跳转均改为window.open，在打开时，跟大多数钓鱼防治殊途同归的一点是，我们需要网民们的安全意识提高。

平时开发要注意些什么？

1 . 开发时要提防用户产生的内容，要对用户输入的信息进行层层检测
2 . 要注意对用户的输出内容进行过滤(进行转义等)
3 . 重要的内容记得要加密传输(无论是利用https也好，自己加密也好)
4 . get请求与post请求，要严格遵守规范，不要混用，不要将一些危险的提交使用jsonp完成。
5 . 对于URL上携带的信息，要谨慎使用。
6 . 心中时刻记着，自己的网站哪里可能有危险。

参考文献

• 聊一聊WEB前端安全那些事儿
• 常见web安全攻防总结