前后端网络攻击类型

1.DDoS攻击

分布式拒绝服务（Distributed Denial of Service，简称DDoS）是指将多台计算机联合起来作为攻击平台，通过远程连接，利用恶意程序对一个或多个目标发起DDoS攻击，消耗目标服务器性能或网络带宽，从而造成服务器无法正常地提供服务。【主要针对的是后端服务器】

攻击原理：通常，攻击者使用一个非法账号将DDoS主控程序安装在一台计算机上，并在网络上的多台计算机上安装代理程序。在所设定的时间内，主控程序与大量代理程序进行通讯，代理程序收到指令时对目标发动攻击，主控程序甚至能在几秒钟内激活成百上千次代理程序的运行。

1.1.DDoS攻击危害

重大经济损失：在遭受DDoS攻击后，您的源站服务器可能无法提供服务，导致用户无法访问您的业务，从而造成巨大的经济损失和品牌损失。

例如：某电商平台在遭受DDoS攻击时，网站无法正常访问甚至出现短暂的关闭，导致合法用户无法下单购买商品等。

数据泄露：黑客在对您的服务器进行DDoS攻击时，可能会趁机窃取您业务的核心数据。

恶意竞争：部分行业存在恶性竞争，竞争对手可能会通过DDoS攻击恶意攻击您的服务，从而在行业竞争中获取优势。

例如：某游戏业务遭受了DDoS攻击，游戏玩家数量锐减，导致该游戏业务几天内迅速彻底下线。

泛洪攻击：通常情况下TCP三次握手建立连接。第一次握手之后服务端会对线程、连接等需要的内存资源、相关参数进行评估并初始化，之后响应到客户端，完成第二次握手。该攻击就是客户端恶意发送握手连接但是不会触发第三次握手，导致服务端一直消耗系统资源，无法处理正常合法请求。

1.2.常见的DDoS攻击类型

DDoS攻击分类	攻击子类	描述
畸形报文	畸形报文主要包括Frag Flood、Smurf、Stream Flood、Land Flood、IP畸形报文、TCP畸形报文、UDP畸形报文等	畸形报文攻击指通过向目标系统发送有缺陷的IP报文，使得目标系统在处理这样的报文时出现崩溃，从而达到拒绝服务的攻击目的。
传输层DDoS攻击	传输层DDoS攻击主要包括Syn Flood、Ack Flood、UDP Flood、ICMP Flood、RstFlood等。	以Syn Flood攻击为例，它利用了TCP协议的三次握手机制，当服务端接收到一个Syn请求时，服务端必须使用一个监听队列将该连接保存一定时间。因此，通过向服务端不停发送Syn请求，但不响应Syn+Ack报文，从而消耗服务端的资源。当监听队列被占满时，服务端将无法响应正常用户的请求，达到拒绝服务攻击的目的。
DNS DDoS攻击	DNS DDoS攻击主要包括DNS Request Flood、DNS Response Flood、虚假源+真实源DNS Query Flood、权威服务器攻击和Local服务器攻击等。	以DNS Query Flood攻击为例，其本质上执行的是真实的Query请求，属于正常业务行为。但如果多台傀儡机同时发起海量的域名查询请求，服务端无法响应正常的Query请求，从而导致拒绝服务。
连接型DDoS攻击	连接型DDoS攻击主要是指TCP慢速连接攻击、连接耗尽攻击、Loic、Hoic、Slowloris、 Pyloris、Xoic等慢速攻击。	以Slowloris攻击为例，其攻击目标是Web服务器的并发上限。当Web服务器的连接并发数达到上限后，Web服务即无法接收新的请求。Web服务接收到新的HTTP请求时，建立新的连接来处理请求，并在处理完成后关闭这个连接。如果该连接一直处于连接状态，收到新的HTTP请求时则需要建立新的连接进行处理。而当所有连接都处于连接状态时，Web将无法处理任何新的请求。Slowloris攻击利用HTTP协议的特性来达到攻击目的。HTTP请求以\r\n\r\n标识Headers的结束，如果Web服务端只收到\r\n，则认为HTTP Headers部分没有结束，将保留该连接并等待后续的请求内容。
Web应用层DDoS攻击	Web应用层攻击主要是指HTTP Get Flood、HTTP Post Flood、CC等攻击。	通常应用层攻击完全模拟用户请求，类似于各种搜索引擎和爬虫一样，这些攻击行为和正常的业务并没有严格的边界，难以辨别。Web服务中一些资源消耗较大的事务和页面。例如，Web应用中的分页和分表，如果控制页面的参数过大，频繁的翻页将会占用较多的Web服务资源。尤其在高并发频繁调用的情况下，类似这样的事务就成了早期CC攻击的目标。由于现在的攻击大都是混合型的，因此模拟用户行为的频繁操作都可以被认为是CC攻击。例如，各种刷票软件对网站的访问，从某种程度上来说就是CC攻击。CC攻击瞄准的是Web应用的后端业务，除了导致拒绝服务外，还会直接影响Web应用的功能和性能，包括Web响应时间、数据库服务、磁盘读写等。

1.3.判断业务是否已遭受DDoS攻击

出现以下情况时，您的业务可能已遭受DDoS攻击：

1. 网络和设备正常的情况下，服务器突然出现连接断开、访问卡顿、用户掉线等情况。
2. 服务器CPU或内存占用率出现明显增长。
3. 网络出方向或入方向流量出现明显增长。
4. 您的业务网站或应用程序突然出现大量的未知访问。
5. 登录服务器失败或者登录过慢。

参考阿里文档

2.跨站脚本攻击（XSS）

跨站脚本攻击（Cross Site Script，简称XSS）通常指黑客通过HTML注入方式篡改了网页并插入恶意脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击行为。XSS漏洞可被用于用户身份窃取（特别是管理员）、行为劫持、挂马、蠕虫、钓鱼等。跨站脚本攻击是目前Web客户端安全中最严重的漏洞。

跨站脚本攻击根据效果的不同可以分为以下三种。

• 反射型XSS攻击：页面仅把用户输入直接回显在页面或源码中，诱导用户点击访问包含恶意代码的URL。
• 存储型XSS攻击：XSS攻击代码存储在服务器中。由于用户可能会主动浏览被攻击页面，此种方法危害较大。
• DOM型XSS攻击：通过修改页面的DOM节点形成XSS。

常见发生位置：所有涉及到用户可控的输入输出点，如个人信息、文章、留言等。

防御措施：

• 对重要的Cookie字段使用HTTPOnly参数。
• 检查所有用户可控输入。对所有的输入点进行严格的检查，过滤或拦截所有不符合当前语境的输入。由于一般无法预期所有可能的输出点语境，此种方法效果较差。
• 检查所有用户输入的输出点。由于XSS攻击最终是发生在输出点，因此需要分析出用户输入数据的所有输出点的环境，是输入在HTML标签中，还是HTML属性、Script标签、事件、CSS位置中。针对不同的输出位置，制定不同的转义或过滤规则。
• 处理富文本。在文章、论坛等需要用到富文本的地方，需要特别注意富文本与XSS的区分，严格禁止所有的危险标签及事件，原则上应当使用白名单过滤标签、事件及属性。

示例：图片上传由于没有显式设置ObjectMetadata的ContentType，导致图片流里内部js代码也能成功上传，最终结果是渲染图片就会执行js代码。

3.跨站点请求伪造（CSRF）

跨站点请求伪造（Cross Site Request Forgery，简称CSRF）。由于重要操作的所有参数都是可以被攻击者猜到，攻击者即可伪造请求，利用用户身份完成攻击操作，如发布文章、购买商品、转账、修改资料甚至密码等。

CSRF 攻击是黑客借助受害者的 cookie 骗取服务器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的内容。另外，对于服务器返回的结果，由于浏览器同源策略的限制，黑客也无法进行解析。因此，黑客无法从返回的结果中得到任何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。所以，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。比如银行系统中转账的请求会直接改变账户的金额，会遭到 CSRF 攻击，需要保护。而查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果，无需保护。

常见发生位置：所有由用户（包括管理员）发起的操作点。

防御措施：
辅助验证方法：使用验证码。验证码是对抗CSRF攻击最简单有效的方法，但会影响用户的使用体验，并且不是所有的操作都可以添加验证码防护。因此，验证码只能作为辅助验证方法。
通用防护方法：添加足够随机的CSRF_TOKEN并每次更新，以防止参数被猜解。使用CSRF_TOKEN是目前通用的防护方法。
其他防御措施：验证HTTP Referer，拒绝不安全的来源。但服务器并非在任何情况下都能获取到Referer值。

3.1.当前防御 CSRF 的几种策略

3.1.1.验证 HTTP Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆 bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。
这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。
然而，这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。
即便是使用最新的浏览器，黑客无法篡改 Referer 值，这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯到他们自己的隐私权，特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此，用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时，网站会因为请求没有 Referer 值而认为是 CSRF 攻击，拒绝合法用户的访问。

3.1.2.在请求地址中添加 token 并验证

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上 ，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。
该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。

3.1.3.在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

4.SSRF漏洞

SSRF(Server-Side Request Forgery：服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。SSRF 形成的原因大都是由于服务端提供了对外发起请求的功能且没有对目标地址做过滤与限制。SSRF根据是否回显请求内容分为回显型SSRF和非回显型SSRF。如图所示，当服务器A存在SSRF漏洞时，攻击者就可以通过服务器A去访问内网的服务器B，从而向B服务器发起攻击。

在传统环境中，SSRF漏洞的主要作用是帮助攻击者突破网络边界，从而可以使攻击者攻击那些外网无法访问的内部系统。而这些内部系统往往都容易成为企业安全建设的盲区。从而导致企业内网被攻破的概率增加。在传统环境中，SSRF漏洞的危害基本可以分为以下四种：

1. 获取敏感信息：攻击者通过SSRF可以尝试获取一些存在敏感信息的系统文件或者网页。
2. 内网信息探测：攻击者也可以通过SSRF去对内网的主机和端口进行探测，获取内网主机的IP存活和端口开放信息，从而去判断内网都开有哪些服务。
   3)攻击内网应用程序：根据获取到的内网服务的信息，攻击者就可以有针对性的对内网的web应用，或者其他应用程序进行攻击，如weblogic，redis，tomcat等等，从而获取内网机器的权限，为后续的攻击打开突破口。
3. DOS攻击：如果有需要，攻击者也可以利用SSRF企业服务进行DOS攻击。

示例：图片直传方式中授权接口会返回域名hostname，并且在 oss回调应用服务的过程中存在利用 域名 + 图片path 构成的地址访问oss服务商。如果此时 域名 + 图片path 被攻击者修改为其他攻击性的payload，将导致访问oss服务转变成其他危险性的http请求，即SSRF攻击。
解决办法：oss回调应用服务的过程中避免使用授权接口返回的hostname拼接地址，这样即使存在访问oss服务，也不会是攻击者提供的危险地址。

浅谈云上攻防–SSRF漏洞带来的新威胁