翻译：360代码卫士
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
本文会说明并演示如何巧妙地通过一款让人称奇的工具提取浏览器中的敏感信息。这款工具就是智能手机或笔记本电脑的环境光传感器。
（1） 我们提供了关于光传感器API的背景信息和当前的相关讨论情况，将其暴露给更多网站。
（2） 我们说明了用户设备屏幕的颜色如何能够影响到传感器读数，并解释了它会带来严重的安全和隐私后果。我们主要关注从跨域框架中提取浏览历史和窃取数据，它可能会让攻击者发现敏感文档和图像内容（如账户恢复的QR码）。
（3） 我们讨论了浏览器厂商和标准维护者们可缓解该风险的应对措施。
这种攻击在火狐和Chrome的当前版本（实验结果）、在带有光传感器的安卓和桌面设备如MacBook Pro中均起作用。
本文是作者以及@LukOlejnik和@arturjanc的合作成果。
背景：智能手机中的光传感器
如今，所有智能手机和很多现代笔记本电脑都配有一个环境光传感器。这种传感器会放置在设备顶端的位置，通常挨近前端的摄像头位置。智能手机一直都利用环境光读数来调整显示两度以节约用电量，或者进行近感探测。光条件信息可用于设计响应式智能手机应用程序或者配置硬件本身。多少有点毫不让人惊讶的是，光传感器读数可能非常敏感。
环境光传感器返回的数据非常精确。光线强度用照明单位勒克司来标示，输出数据范围是0（黑暗）到好几万（勒克司）传感器的读数频率相对较高，介于100到200毫秒。
为了提高跟原生app的竞争力，网站不久之后或许能够访问环境光读数。一个W3C设备和传感器工作组目前正在讨论是否允许网站在不要求用户许可的情况下读取光传感器。Chrome和火狐浏览器最新版本都有API实现。
传感器隐私
这项研究源于最近W3C关于通用传感器API的讨论，其中一种提案认为读取某些传感器数据不应当要求请求获取用户许可。作为回应，我们决定调查一下环境光传感器（ALS）背后可能存在的恶意意图；此前我已经分析了ALS的安全和隐私问题，它可能会引入数据追踪、分析和泄露的新方法：其中一个示例讨论了“检测两个人同时位于同一房间内”，另外一个例子分析了发现银行PIN码的可能性。
本文将会把这些担忧放在一边，主要考虑传感器读数如何帮助活跃攻击者从用户浏览器中提取隐私数据。
现在，我们来重点讨论真实的攻击。
使用光传感器提取信息
到底如何通过环境光传感器提取私人数据？我们的攻击基于如下两个观察结果：
用户屏幕的颜色能携带有用信息，而网站出于安全原因的考虑无法直接获取。
攻击者能通过光传感器读数区分出不同的屏幕颜色。
我们随后会对第二点进行更详细的解读，但一言以蔽之，来自屏幕的光能对光传感器读数产生巨大影响，网站从而能够判断出用户屏幕的颜色（或者在最简单的情况下，能够区别黑屏和白屏）。
以上提到的第一点可能更让人惊讶；毕竟，所有的网站都能控制自己在用户屏幕上所展示的信息，那么为何这种数据会很有意思呢？在两种情况下网站无法直接获取用户部分屏幕的颜色：
已访问链接的颜色。出于隐私原因的考虑，浏览器会在页面所展示链接的颜色上对开发人员说谎；否则恶意开发人员就能够应用:visited 的多种style并检测到用户历史中出现了哪些网站。
跨域资源。同源策略阻止evil.com直接访问来自victim.com的资源。然而，虽然站点无法检查来自其它来源的框架或图像，他们能够在屏幕上做出展示并更改如何对用户呈现，包括任意缩放比例并更改颜色等。
我们的攻击依赖于将此类资源展示在屏幕上并检测到它们的颜色，每次都泄露一点信息。如下是这种攻击如何在实际中起作用（使用我们早前冗长的展示）：
检测访问过的链接
由于网站能够在已访问和未访问链接中应用不同的style，但无法检测到这些链接是如何展示给用户的，因此，我们使用传感器来识别出它的真实颜色。
（1） 设置链接的style：已访问过的（白色），未访问过的（黑色）。
（2） 校准：展示一个白色背景，然后跟上黑色背景从而识别出用户环境中的光级别；这也有可能实现但更难，如果传感器读数波动幅度大的话。
（3） 循环访问链接清单，一个链接一个链接地访问，然后将它们像一个大长方形那样展示出来，填满整个屏幕。已访问过的链接会显示为白色，未访问的显示为黑色。
（4） 记录光级别作为展示每个链接的响应方式，识别出链接的颜色。由于我们在第二步已经校准了屏幕，因此我们就能知道每个读数所代表的颜色。
最后，攻击者会获取屏幕是白色的链接清单，并且知道用户之前已经访问过给定的页面。
虽然在PoC演示中，我们依靠的是假定光条件不会在提取阶段发生变化，但在处理这些情况中使用这些演示也应该没问题。在第一个演示中，我们想要强调的是光读数会发生变化。然而，在现实中不难克服这个障碍。
窃取跨域资源
更麻烦的事实是攻击者能够提取像素完美的跨域图像和框架：关键的是，发现既定网站或图像如何寻找遭攻击的用户（我们在演示中关注图像是因为它们更容易提取）。在极端案例中，例如那些紧急访问某个账户从而使用账户恢复QR码的站点(https://victim.com/account-code.png )，攻击者就能劫持用户账户。
这种攻击跟《像素完美定时》论文中所使用的技术类似，它起作用的方式如下：
（1） 内嵌一个来自遭攻击域名的图像；一般来讲，这会成为不同验证用户的资源，如登录用户的头像或安全码。
（2） 使用SVG过滤器创建图像的黑白格式（SVG中的过滤器也在跨域资源中起作用）。
（3） 缩放图像，这样每个像素都可填满整个屏幕。
（4） 遍历图像中的所有像素，在用户屏幕上将它们都展示出来，并记录这个像素的光传感器读数。
（5） 从每个像素读数中撰写结果图像。
这样就能从任何允许跨域内嵌框架（没有X-Frame-Options头或者框架前身内容安全策略指令）的文档中提取所有的图像资源和数据。
攻击详情和其它考虑因素
既然我们演示了这些攻击，我们就可以讨论一下实际利用这种技术的考虑因素。
检测速度
由于我们每次都提取一点点信息，利用中的一个主要限制因素就是检测速度。原则上，浏览器传感器能够传输60Hz读取速率。然而，这不意味着我们每秒钟就能提取60位，因为最终的检测限制跟传感器能够检测到的屏幕亮度变化有关。在实验中，我们测试的屏幕亮度读数延迟是200到300毫秒，而对于一个完全可靠的利用来说，假设每500毫秒传输1位更实际。
在这个检测速率下，示例检测次数如下：
8个字符的明文字符串：24秒（假设对于以一个已知字体呈现的字母数字字符串来说，每个字符是6位）
16个字符的明文字符串：48秒
20×20 QR码：3分钟20秒
之前检测1000个流行URL：8分钟20秒
64×64像素图像：34分钟8秒
用户不可能会忍受一个似乎在黑白之间来回切换很长时间以检测即使很短的文本字符串的网站。然而，在某些情况下，当用户不用设备时（比如晚上将设备放到架子上），攻击者就能够提取更多的数据；恶意网站能利用scree.keepAwake API来让它无限制显示。
未来，光传感器有可能能够测量强度或光饱和度（红色、绿色、蓝色），从而让攻击发生得更快。
传感器读数的准确性
虽然光传感器本身提供了准确的读数，但这种技术的一个实际困难之处在于测试过程中不断变化的光条件，以及用户会拿着设备移动的可能性（尤其是移动手机）。
我们发现结果的准确度受多个因素的影响，如屏幕亮度（屏幕越亮越对攻击有利）、传感器上方反射面的距离和角度（放在架子上的手机会从平行表面反射光从而产生好的结果；缺乏反射面会让攻击变得非常难）、以及周围光的数量（环境越暗，噪音越少，检测就越容易）。
浏览器支持
攻击在现代浏览器中起作用：火狐和Chrome浏览器目前会将老旧API作为环境光事件，我们在演示中也用了这一点。在火狐浏览器中不需要权限，但在Chrome中目前还要求启用chrome://flags#enable-experimental-web-platform-features标记。这个老旧的API不久之后会被替代为新的环境光传感器API，这个API目前在Chrome中实现（chrome://flags#enable-generic-sensor），它在功能上跟我们的目的一致。
应对措施
当前提案认为以下的保护措施就足够了：
限制传感器读数频率（低于60Hz）
限制传感器输出精度（量化结果）
以我们所知，这些预防措施是基于研究成果漏洞报告的响应，这说明可使用陀螺仪恢复音频信号。我们的理解是Chrome提案尝试将“陀螺仪误用”的解决方案应用于其它传感器，对于所有实例来说可能不足。尝试生成构建于具体和专门风险之上的威胁模式可能并不正确。
对于光传感器来说，限制频率将不会阻止我们的攻击；即使频率低至1Hz，，也会发生同样的攻击，只不过速度会变缓。
限制输出的精准度可能是更好的解决方案，只要能保证屏幕颜色不会影响传感器的输出级别就可。可能在某些其他情况下攻击也可能实现（亮屏、反射面离屏幕很近），但在实践中的难度更大。
可能最显而易见的解决方案是要求用户给予请求访问传感器的网站权限，就像其他功能如地理位置那样。将安全和隐私考虑放到环境光传感器API规范中来记录如上的攻击风险也是稳妥的办法。
用户建议
在火狐浏览器中，尝试在about:config中禁用传感器——将device.sensors.enabled设置为“false”。在Chrome浏览器中，多数用户当前应该是不会受到这种攻击，除非用户手动启用了此前提及的试验性标记。
网络开发人员建议
为了保护文档被不受信任网站实施内嵌框架，将X-Frame-options设置为拒绝HTTP头。这样做还会阻止其它类型的攻击如点击劫持攻击。
目前尚无缓解针对图像的攻击，因为它们并不受X-Frame-Options的限制。
总结
所展示的攻击表明，看似无恶意的环境光传感器能让恶意网站违反同源策略、窃取跨域数据并提取用户浏览历史信息。
这里的经验就是，从隐私工程角度来设计规范和系统是一个复杂的进程：应该严肃重视在未部署任何保护措施的情况下做出将敏感API暴露到网络的决策。危险之一就是规范作者和浏览器厂商会基于过于宽泛的但不适用于某个具体新功能的原则和研究结果而做出决策（类似于陀螺仪读数保护措施并不足以保护光传感器数据）。
可能更让人兴奋的经验是，技术标准、隐私工程和隐私影响评估充满乐趣，它能让我们发现会给现实生活带来后果的微小问题。如需提供任何关于规范或功能方面的帮助，可随时联系作者。
还没有评论，来说两句吧...