国内外电商平台反爬虫机制报告

2017-06-22 +15 654556人围观 ,发现 10 个不明物体 WEB安全

电商平台的核心引擎大致分为两块,搜索架构和产品布局,应该说各有各的特色。当然今天的主题是反爬虫机制,电商平台如何能保护好自己的数据,又不影响正常用户体验,所谓当今业界一场持久的攻防博弈。

一阶爬虫(技术篇)

应用场景一:静态结果页,无频率限制,无黑名单。

攻:直接采用scrapy爬取

防:nginx层写lua脚本,将爬虫IP加入黑名单,屏蔽一段时间(不提示时间)

应用场景二:静态结果页,无频率限制,有黑名单

攻:使用代理(http proxy、VPN),随机user-agent

防:加大频率周期,每小时或每天超过一定次数屏蔽IP一段时间(不提示时间)

应用场景三:静态结果页,有频率限制,有黑名单

攻:使用代理,随机1-3秒爬取,爬10秒休息10秒,甚至范围时间爬取,增加机器

防:当5分钟内请求超过60次,弹出验证码页面,通过验证增加5分钟无限制时间,不通过验证码则屏蔽增加一小时 (时间自拟)

应用场景四(Amazon):静态结果页,有频率限制,有黑名单,有验证码

攻:python+tesseract验证码识别库模拟训练,或基于tor、crawlera(收费)的中间件(广度遍历IP)

防:前端异步加载js,动态加密token

应用场景五(Aliexpress):动态结果页,有频率限制,有黑名单,有验证码

攻:python+Selenium,利用chrome内核加载动态结果页,更推荐用node+hex+ie内核做一个爬取客户端。java程序可以参考《简单破解Java浏览器组件jxbrowser》

防:见二阶爬虫

一阶爬虫属于单纯的技术性博弈,下面开始真正的人机交互博弈

二阶爬虫(进阶篇)

应用场景六(PC天猫搜索页):https,动态结果页,有频率限制,无黑名单,有验证码

防:基于个性化为主导,提倡用户主动登陆来获取更优质的用户体验。根据购买习惯为用户推荐一些正常促销的商品,如9.9洗发露、沐浴露、茶叶等(威露士经常做),以及一些优质的钻展商品。不但能区别人机,还能搜集用户访问喜好,针对性优化个性化大数据,还可以抵御ddos,可谓一举三得

攻:搜集刷单账号,用分布式任务

应用场景七(生意参谋):https,React单页面应用,有验证码,LocalStorage,机器学习中间件

防:生意参谋本身是收费类的官方服务,从内测http过渡到https,而且近期加大对采集行为的打击,直接采取封号警告策略。以增加用户采集成本为限制,约束攻击方收敛性为。

单页面应用访问是遵循一定正常轨迹的。例如请求:

1. 用户信息获取

2. 数据列表1

3. 数据列表2

4. 数据详情1

针对数据可视化应用,大部分数据是经计算分析得到,并不会经常改变(甚至不变)。那么,数据结果存储入LocalStroage中,不但节省了网络请求加快页面速度(相当于缓存),还能区分用户行为轨迹

详细的来说,通过程序编程得到的爬虫,无论是基于url request,还是基于解压webkit(如:jxbrower)。所生成的爬虫对象都是临时对象,那么不会存储LocalStroage数据,因此导致,访问数据页的请求轨迹每次都会是

1. 用户信息获取

2. 数据列表1(实际应被存储到LocalStroage)

3. 数据列表2(实际应被存储到LocalStroage)

4. 数据详情1

而正常用户行为(一直通过浏览器访问重复页面)

1. 用户信息获取

2. 数据详情1

… 总之,不会请求LocalStorage里有的

选区_085.png

加解密的JS代码


setItem: function(e, t) {

                    return void 0 === t ? this.removeItem(e) : (localStorage.setItem(e, this._serialize(t)),

                    t)

                },

                getItem: function(e) {

                    return this.deserialize(localStorage.getItem(e))

                },

另外,单页面应用是异步加载数据,一个页面种有ABC三类,只有A类需要验证码时用dialog占屏,BC类数据正常显示,爬虫开发时必然考虑不到这些情况,验证码并非强制要求输入(刷新后照常访问)

还可以分析每天用户请求数,访问习惯等等

分析用户行为轨迹的方式大致有3种:nginx流量中间件,web controller层拦截器,日志收集(flume + hadoop + sperk)* 。可能基于贝叶斯或决策树分析【实际怎么算只有开发者知道】

曾经被封过一次, 不是实时性的第二天才被封, 所以应该时 日志离线计算 得出的结果

选区_087.png

攻:chrome插件(可获取https流量),另外把页面中的跳转链接记录到数据库中. 因为一些链接只需要修改日期或ID等参数就可以复用. 链接中的一些铆点可能就是计算用于轨迹的因素. PS:这也是生意参谋一直警告的方式, 所有行为由读者自行负责, 与本文作者无关

选区_086.png

三阶爬虫(反攻篇)

讲道理攻击方为何需要去爬取电商平台的数据,就为一个目的,逆演算出平台的权重计算,推导出各类合理范围内的指标(配合刷单,刷流量)。从技术层面上,永远是一个相互博弈的过程,如果有人下血本采用半人工,堆机器的方式暴力抓取,也是难以防控的。而且众所周知,电商技术的转化含金量非常高,机器和人工的成本就是九牛一毛,如果你的模型与业务模型擦边,辅助上一些内部渠道,无论是作为商家还是服务商都极快的变现

因此,反爬虫的最终核心点是要让攻击者不知道自己已经被判定为爬虫了。那么,攻击者只会悠哉的爬取数据,并兴高采烈的开始演算。而从平台方我们的最终目的是为了保护我们的数据和模型,那么关键点就来了。需要是让攻击方获取得数据不具有代表性,模型不可行即可。配合上流量木桶,定位到攻击者,我们将原始数据进行一些离散加工,加入一些噪音,让攻击方往错误的方向上推导模型。最终攻击方讲无法区分哪些数据是可用,那些又是噪音。

这时候,你会说,如果系统误杀正常用户,给出个一些展示数据错的离谱怎么办。这个度其实很好把握,我们只需要在排名*、成交单数、点击率等此类动态变化的维度加入噪音,不去加工价格、运费、产品详情,即使被程序判定为攻击者,并不影响正常用户的体验

*本文作者:leopard7777777,转载请注明FreeBuf.COM

这些评论亮了

  • idapro (3级) > _ 回复
    发现爬虫不要阻断嘛,投毒就行了。
    )17( 亮了
  • 阻断的都是比较低级的玩法,高级的就是返回虚假数据
    )9( 亮了
  • leng_que (3级) 系统错误,请稍后再试…… 回复
    某爬虫:你在数据里下毒!!(痛苦的倒在地上捂着肚子)
    )9( 亮了
发表评论

已有 10 条评论

取消
Loading...
css.php