WEB API如何防御CC攻击

我只是把问题写在这儿,而不是写答案。最近一段时间我观察到CC攻击有一些变化,从攻击动态页面变成攻击WEB API。理由应该是很简单的。

首先是WEB API的大规模使用。不管是微博,还是网盘、图库、云存储,不开放一些WEB API出来给开发者调用,都不好意思跟别人打招呼。更何况比较大的互联网企业如腾讯、百度、阿里,都想学苹果做平台,天天说开放,想把开发者捆在自己身上加重自己的份量。一般来说开发者都比较容易激动,现实中可能沉闷但是在网上尤其活跃,出一点问题就会微博上四处转播宣扬,所以攻击WEB API惹到他们无疑是一个很好的想法。

其次在技术层面,对WEB API的CC攻击防御困难得多。在前WEB API时代,攻击目标只能是动态页面。由于攻击者是使用普通的攻击程序而正常使用者使用浏览器访问页面,一个不解析JS一个解析JS,一个不follow跳转一个follow跳转,正常用户和攻击者的区别是非常明显的,因此各地设备厂商都不约而同使用类似的方案,返回JS做客户端跳转啦,验证码啦,302重定向啦之类方式做人机识别。但是现在,问题来了。正常用户可能也是通过程序调用WEB API的方式来访问业务,攻击者和正常用户都是使用程序而不是浏览器访问,以前那些人机识别的方案已经行不通了,强上只能是大量的误报。

如何解决?嘿嘿。

此条目发表在技术分类目录。将固定链接加入收藏夹。

WEB API如何防御CC攻击》有 12 条评论

  1. sbilly说:

    没太好的办法,我先提后面向导其他的再补充。如果没有具体 case 估计只能这样提了:
    1. 缓存;
    2. 调 API 步骤,验证来源合法性(可以有很多个层面)

  2. 云舒说:

    调API的步骤,这个只能保护后端业务哦,未必保护得了前端WEB。以前的传统厂商设备在网络入口就可以基于跳转滤掉攻击,web几乎不受影响。

  3. sbilly说:

    你是说界面上 js 取数据的这个 api 的 ddos 防护?

  4. r.4ntix说:

    结合sbilly 所说的:
    1,缓存
    2, 调 API 步骤,验证来源合法性(可以有很多个层面)
    // 做好业务后端的保护之后
    3,对开发者账户(API KEY)进行调用限制(每个API KEY/IP 每小时最多多少GET/POST调用等等)
    4,对API 调用进行特征过滤,比如遇到攻击时是否是(时间段内GET/POST 是否为相同参数)

    感觉最主要的问题,还是怎么识别和确认攻击吧…

  5. 云舒说:

    不行的,WEB服务器承受不住大量的TCP连接。

  6. litingting说:

    嗯,这些流量一旦给webserver,压力灰常大。粗暴点,限制用户调用的次数吧,超过限制的,先毙掉再说。不让压力转嫁给webserver。

  7. huangchong说:

    验证模块与业务模块分开,由政府或非盈利组织提供登录服务与授权服务,一次登录,全网域有效

  8. sbilly说:

    最近贴代码太多啊!

  9. 云舒说:

    没事就贴点老代码。。。。

  10. yundun说:

    主要思路还是人鸡识别,目前我们针对这样的攻击通用办法1:控制到后端的请求数先保护后端不挂;2:限制ip单位时间请求频率、ip单位时间请求同一url频率。3:再分析攻击特征收集ip拉黑。4:有开发能力的api配合做人机识别(具体识别办法不透露了~)

  11. Pingback引用通告: OAuth 2.0安全案例回顾 | Panni_007 Security

发表评论

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