UDN-企业互联网技术人气社区

板块导航

浏览  : 1361
回复  : 0

[干货] Google是如何处理机器风险的?

[复制链接]
开花包的头像 楼主
发表于 2017-1-3 16:12:32 | 显示全部楼层 |阅读模式
  前言

  在前两篇文章中,我们已经分析过了多种应对机器风险的方案,其中比较广为人知且行之有效的就是验证码了。上文中也提到,传统的图形验证码对抗已经进入了安全和用户体验难两全的恶性循环,而基于用户行为的无答案性防御方式正在兴起,以Google的recaptcha为代表,将传统的考验机器回答问题能力,改为考验机器是否具备正常用户行为能力,似乎是目前较为行之有效的方案。

  recaptcha 是什么

  Protect your website from spam and abuse while letting real people pass through with ease

  这是recapthca官网的原文,从目标上似乎和各式各样的验证码并没什么什么区别。不过在 'real people' 的体验上却要好很多。其推崇的是隐形的验证码,用户只需要在指定位置点一下鼠标,即可通过验证。

a.webp.jpg

  recaptcha 运行原理

  recapthca的实现原理其实说起来很简单,大致为:

  通过前端脚本收集用户行为信息。

  上传用户行为信息。

  通过用户的历史行为以及当次用户行为进行判断,是否为机器。

  没错,原理就是这么简单,似乎简单地可怕。然而现实和理想直接永远有巨大的差距,如果黑客们有这么好对付,也不需要Google工程师们这么长时间的对抗了。一个稍微有攻击经验的人都会提出以下疑问:

  前端脚本是明文加载的,所有的采集逻辑都暴露在外,只需要自己拼凑一份采集数据模拟正常用户行为即可。

  大量的js执行环境存在,比如phantom、webdriver等等,还有按键精灵之类的存在,我只需要模拟动动鼠标,一切就可以搞定。

  想要浏览器存住历史行为并不容易(我们已经在之前的文章分析过),黑客们才不会傻到让你有一系列的行为可以分析。

  正常用户行为各异,如何保证不误伤。只要你不敢保证百分百拦截疑似行为,黑客们就会混迹于这些疑似行为之中。

  我们看下recapthca是如何应对上述问题的:

  recapthca 实现

  加载


  recapthca并不像传统的ui组件显示在页面之上,它是一个独立的iframe,作为一个独立的页面引入你的应用,这样设计,很明显是为了进行频繁的更新。

b.webp.jpg

  毫无疑问,黑客们面对的将是一个频繁更新的匣子。

  前端加密

  我们简单看下recapthca页面加载了哪些js,首先会加载一个名为

  https://www.gstatic.com/recaptch ... recaptcha__zh_cn.js

  的js文件,其主要功能是一些通用代码,以及UI层面的代码,js本身并未进行高度混淆,可以理解为验证码本身的业务代码主要汇集于此。

  于此,html内部会内嵌两段 script 标签

  第一段script标签:

c.webp.jpg

  我经过分析之后,发现此段script标签的大致行为是:

  遍历所有的html原生标签,分别在页面中的某个隐藏部位插入,然后遍历这些原生标签的属性,收集起来。对此,目的应该很明显,就是为了深度检测当前执行环境是否为一个真实的浏览器。恐怕应该没有人比chrome的工程师自己知道应该存在哪些属性吧,哈哈。

  第二段内嵌脚本:

d.webp.jpg

  第二段脚本从命名来看显然是一个主逻辑入口,然而其参数是经过加密再base64之后的结果,看起来甚为壮观!我曾经尝试解开这一大段字符串的原文,发现其为base64加密的二进制流,显然这种设计,说明这段字符串为某些会动态变化的下发指令藏身处,我继续跟进方法,该方法指向了另一个最为关键的js脚本:

  https://www.google.com/js/bg/u09 ... h3MbmZv49j_FU3OI.js

  从js名字就能看出来,这个js应该是经过保护的,即使做好了心理准备,结果还是超过我想象 - -。

  首先是一段富有情怀的注释233:

  1.   /* Anti-spam. Want to say hello? Contact (base64) Ym90Z3VhcmQtY29udGFjdEBnb29nbGUuY29t */
复制代码

  看来Google似乎想在这一步告诉你,如果你够geek,应该主动联系他们,说不定能给你提供个职位啥的,而不是在这里搞破坏。

  接着就是一大段eval函数:

e.webp.jpg

  实不相瞒,在多次尝试之后,我实在只能对此脚本略有了解,脚本本身是经过高度混淆加密的,不仅所有的变量名都变成不可读,甚至连对象的属性名都进行了混淆,而且是还将变量分布在不同的对象深度中,大部分的属性或方法调用能看到的不过是:a.b.c.d()。从我的视角能看到的是这段js中实现了一个自定义的完整的二进制转指令的算法,但是我还不能完全理解这个算法。

  有一个外国友人提到:

  It turned out this new ReCaptcha system is heavily obfuscated, as Google implemented a whole VM in JavaScript with a specific bytecode language.

  即Google用js实现了一个完整的 虚拟机, 后台动态输出不同的指令,让逻辑隐藏在自己设计的指令之中。不管是不是虚拟机,总之,对于该脚本传输的密文似乎并不能轻易的破解,也就是说,你可能无法直接伪造一份采集数据的密文发送给Google的服务器。

  采集数据

  除了上面提到过了的浏览器标签属性,recapthca大概还采了下面的这些内容:

  插件列表

  useragent

  浏览器分辨率

  执行时间

  click、touch、keyboard事件

  canvas帆布指纹

  cookie

  等等,这些特性除了能够检测你的当前执行环境以外,还可以一定程度上将你的上次行为找出来,也就是传说中的“设备指纹”。将浏览器可采集到的数据做历史分析,你的下一次数据和其中一份数据分毫不差的对应上了,就可以把你的历史行径全部找出来,从而辅助分析你是否为一个“老实”的用户。

  模型

  对于真实用户行为的模型建立并不是一件特别容易的事情,不过对于以算法著称的Google来说,或许没那么困难,由于这部分完全属于黑盒了,暂时无法对其背后的模型进行分析。

  兜底方案

  上面还有的疑问,Google如何保证不误伤用户?我们可以用隐身模式打开Google的recapthca页面,然后极快的点击人机验证区域,发现了如下反应:
f.webp.jpg

  在他们无法很好的分析出你是否为正常用户的时候,会回退到图形验证码步骤,不过并不是基本的图形验证码,而是分类验证码,不过其图片清晰程度和问题对比国内的某些分类验证码,体验也好了一个档次。

  总结

  recapthca 通过前端加密来保证数据传输的安全性,不会被直接伪造脏数据

  recapthca 通过分析浏览器特征,判断是否为phantom等非真实浏览器环境

  recapthca 通过行为模型,分析采集的数据是否具有机器风险

  recapthca 对应有机器风险的用户,会出图形分类验证码进行二次验证,而没有风险的用户,会直接通过

  recapthca 的用户体验远远高于普通的验证码

  recapthca 的安全性可能会高于传统的验证码方案

原文作者: leon 来源:开发者头条

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部