waf开发之民主模式 – 作者:chenjc-安全小百科

一、前言

灵感来自于近期一次面试,面的是业务安全相关的岗位，之前对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，但是属于正常用户防护的情况，也可以人为调整为白名单，即可以人为对”大选”结果进行干预。相对来说，在管理页面生审核“大选”结果，怎么也比训练调整机器学习模型轻松。