网站安全:使用Cookie预防小规模CC攻击

也是这两天写个人项目的时候想到的一点东西,做了一个留言提交和查看功能并且使用ajax交互,出于用户体验因素,拉取留言的时候带上验证码的话总归是不太方便的,但是没了验证码这类东西的屏障的话很容易被人一套带走,写个脚本不停拉取你这块东西的话对你服务器(尤其是数据库)的压力会比较大,所以就要想个办法如何避免这种情况。(你跟我说缓存?缓存是可以但是这种情况显然不是讨论缓存解决吧(滑稽))

一般来说CC攻击都是用各种手法使得你不停地去请求数据库,导致服务器的IO飙升,最后由于IO负载达到上限而无法提供正常的服务。这种CC攻击一般的实现手段都是不停地发出僵尸请求,也就是说不会对你的回复进行处理,甚至发出请求后立刻断开连接。利用这个特性,我们可以使用一些方法来进行对抗。

那么上面这两段废话说完,CC攻击的请求和正常请求到底有哪些区别?

首先:正常的浏览器请求会解析你发送过来的脚本内容,而CC攻击很多时候就收到回复甚至于不接收就直接结束了

其次:正常浏览器请求建立会话会体现在Cookie字段(session id是通过Cookie的某个字段体现的),并且随着session结束/重开而变化。而CC攻击时可能就是固定的一个或多个session id,甚至于没有任何session(因为cookie字段固定)

(考虑到HEADER部分都是可以伪造的,因此很少考虑其他Header,比如User-Agent带来的影响)

因此我们可以考虑通过Cookie下手来简单应付下这种CC攻击。也就是通过在Cookie添加某种标记来表明用户合法性并作出验证。

比如在我目前这个个人项目里面,留言模块是只从首页载入的,那么我只要在首页加载的时候给上标记,然后对于留言模块的后端接口,我检查这个标记的合法性就可以了。

为什么呢?

首先,一个正常的浏览器访问到首页的时候,我首页给出了一个标记,这个标记对每一个会话唯一,放在Cookie当中。

然后,当点击“留言板”的时候,由于脚本默认自动触发ajax加载,而这个加载会带上我之前放在Cookie里面的标记,一起发送给我的留言模块后端

此时,后端收到请求,检查标记是否存在,如果标记存在,并且和session对应一致(也就是session里面存了这个标记),则认为标记合法,进行正常流程查询数据库返回。由于session – flag唯一匹配,因此可以在一定程度上阻挡非法攻击。

那么对于一个CC攻击者来说,他不停CC我留言模块的时候是没有这个标记的,我可以选择直接返回错误信息,甚至直接return 404都可以。

你也许会说:我CC前也去index获取你的标记,然后带标记请求不就好了吗

那么问题来了:我前面也说过,后端收到请求是要检查标记存在并且和session对应一致的,但是我没有说这个标记存了什么呀

我是不是可以标记里面放上一次请求时间?

我是不是标记里面放上请求频率?或者其他统计信息?

如此一来,如果我的标记里面存放的数据达到某一个阈值,比如说上一次请求时间与当前时间处在最低请求时间间隔,或者请求频率达到了每秒多少次,那么我就认为你请求太快了,歇歇吧等会儿再请求,我也就不查数据库了,降低数据库压力,是不是也就达到了一个简单的防止作用?

(手动滑稽

当然,防CC的手段不止Cookie后台标记这一种,你也可以返回内容包含一段javaScript,正常浏览器接收到数据后会进行脚本解析,你在脚本里面进行跳转啊之类的都是有效的手段,毕竟你返回脚本等于返回静态资源,从脚本跳转到真正的主页也是切实可行的,而很多时候CC攻击目标并不会去理会这些脚本,也就减轻了服务器压力。

然而呢,上面说到的方法也只能在一定程度上进行减轻,毕竟这年头没有一劳永逸的解决办法,你会防CC,人家做CC的也就会想方设法绕过。只能说安全这一块是没有止境的。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注