一、前言

灵感来自于近期一次面试,面的是业务安全相关的岗位，之前对jxwaf的定位是中小企业基础安全防护，倒也没过多考虑大公司业务安全防护的情况，趁此机会好好思考一波，有些不错的想法，特此分享。

我将这种新的防护方式称之为民主模式，算是之前自学习模式到进阶版本。优点看下文，缺点在于只适用于大公司，用户量不够的话玩不起。

二、业务安全防护应用

先来设定一个业务安全防护场景

用户异常行为轨迹识别

假设现在网站有个秒杀活动，我们需要识别用户进行秒杀时，之前在网站内的行为轨迹是否异常，如果是异常的，比如自动程序，那么需要进行相应的处理。

我们先考虑用机器学习来进行识别，首先需要把机器学习平台搭起来，然后找业务部门在关键接口上埋点，之后人工标识一些异常数据，最后训练出模型，业务部门通过api调用进行异常用户识别。

这是之前了解到的通常做法，主要问题在于业务部门有新业务上线，都需要重新进行埋点或者植入检测功能，与业务部门耦合度过高，占用业务部门的排期，后续的维护和更新也不够灵活。

接下来考虑民主模式，民主模式不涉及机器学习，部署的话就是参照一般waf部署即可，因为本身就是jxwaf的一个功能。部署完后需要进行一些配置，如下:

{"democracy":"true"}

开启民主模式

{
"rule_key" : {"rule_var": "Cookie","rule_specifc":["session"]},   //指定网站session字段
"rule_user" : {"rule_var": "ARGS_POST","rule_specifc":["username"]} //指定网站用户名字段
"rule_matchs": [
            {
                "rule_vars": [
                    {
                        "rule_var": "URI"
                    }
                ],
                "rule_transform": ["none"],
                "rule_operator": "rx",
                "rule_pattern": "login.php$",
                "rule_negated": false
            }，
                "rule_vars": [
                    {
                        "rule_var": "RESP_HEADERS"
    "rule_specific":"Location"
                    }
                ],
                "rule_transform": ["none"],
                "rule_operator": "rx",
                "rule_pattern": "login.php$",
                "rule_negated": false
            }
     //判断用户是否登陆成功
        ]
}

登陆识别设置，用于绑定用户名与session/token

上述是基础配置，设置好后即是jxwaf的基础参数，后续诸如逻辑防护，CC防护功能都能使用

下面设置防护点，假设有两个点需要防护，支付接口 /pay 和 秒杀接口 /miaosha

 {"check_point":[“ /pay”,“ /miaosha”]}

如果有新的检查点，依次添加即可

配置结束，下来讲件防护逻辑

核心还是识别维度的变化，以前waf的识别维度一般是只是单纯的流量，所以无法进行业务安全方面的操作，民主模式的核心在于将识别维度从流量升级为用户，即绑定用户和流量，识别的是用户，而不是流量。

第二个变化则是识别模式由主动变为被动，机器学习的识别模式一般是获取流量/用户特征，之后进行模型训练，训练的依据一般是安全人员的经验，或者通过调参进行适配，也就是需要人主动介入，通过不断的"拍脑袋"来提高模型识别率。而且民主模式则将是采取被动模式，最终识别规则取决于用户"投票"结果，防护的依据在于正常情况下，90%以上的流量是正常流量，90%以上的用户是正常用户，那么用户"公投"的结果就是可信的，能做作为最终识别规则/模型生成的依据，甚至我们定好"公投获胜率"后，即可直接生成防护规则/模型。而且相比于机器学习模型，另外的优点在防绕过方面比机器学习好，不怕数据污染，因为要污染数据，需要大量的用户，这点跟区块链类似，除非攻击者掌握了超过半数的用户账号，不然是无法影响防护规则/模型生成结果的，这也是前面说的只适用于大公司的原因，小公司用户用户量不够的话，少数攻击者的操作会影响到防护规则/模型的生成。

接下来想假设用户的访问路径，假设有1W个用户，运行一段时间后为以下结果

1、client -> login.php -> a.php -> b.php -> c.php -> miaosha 正常 8000

2、client -> login.php -> a.php -> b.php ->d.php -> c.php -> miaosha 正常 3000

3、client -> login.php -> e.php -> c.php -> miaosha 正常 400

4、client -> login.php -> miaosha 异常 5

如果我们将"公投"的投票数设置为1000用户以上生成的行为轨迹为可信的话，那么1，2的行为轨迹直接就是白名单，之后在设置100以下为异常，那么4直接就是黑名单，至于处于100到1000的，默认情况会当用户访问miaosha接口时进行二次验证，比如弹出验证码等，进行人机识别，即处在该区间的，属于灰色状态。也可以根据占比来进行识别，具体细节可根据业务情况进行定制，相对来说根据占比能更好适应动态更新的情况。以上是默认情况下的处理方法，如果发现有投票数低于100，但是属于正常用户防护的情况，也可以人为调整为白名单，即可以人为对"大选"结果进行干预。相对来说，在管理页面生审核“大选”结果，怎么也比训练调整机器学习模型轻松。

三、基础安全防护应用

以上为业务安全防护的例子，下面讲在基础安全防护方面的应用

基础安全防护主要是对自学习中的词法分析进行优化，将词法分析的识别维度从流量提升为用户识别，进而取消词法分析特征的数量限制，降低配置难度的同时提高检测效果。

同样假设有1W个客户对接口 /pay 进行访问，关键参数为conut，表示金额，运行一段时间后的词法分析结果如下:

1、 n 正常 6000 // 100 200 300 .等

2、 ncn 正常 5000 // 1.0 2.0 100.0 等

3、 nacncnc 异常 1 // 1' select user() SQL注入攻击

同样，我们可以将 "公投"的投票数设置为1000，少于10即为攻击，处于10至1000的特征则只报警，需要人工审计才能应用，而且很明显的，审计类似的特征只需要看一眼就能分辨出结果。

类似应用方式还有很多，例如通过接口间访问的时间间隔来判别异常用户等。想了一圈，这个模式其实主要解决了数据清洗和数据挖掘的工作量，让用户通过投票来帮助我们分辨"善恶"，在依据投票结果进行处理。当然也可以用这种方式来挖掘机器学习特征或者反过来验证模型的效果。

四、总结

民主模式核心就是两点:

1、识别维度由流量变为用户

2、防护模式由主动变为被动，能实现实时更新实时防护

QQ群:730947092

欢迎交流，一起学习。