一、前言
在本文中，我会向大家介绍并演示一种非常巧妙的方法，可以通过用户智能手机或笔记本电脑的光传感器来窃取浏览器中的敏感信息。
简而言之，本文包括以下内容：
1、我们介绍了光传感器API的背景知识，现在人们正在讨论是否拓展这种API的应用范围，将其应用于网站上。
2、我们演示了用户设备的屏幕颜色如何影响光传感器，也解释了这种现象会带来安全性及隐私性方面的风险。我们着重介绍了如何利用这种原理提取浏览器记录以及窃取不同源页面中的数据，这样一来，攻击者可以读取用户敏感文档及图片的内容（比如，攻击者可以窃取用于用户账户恢复的二维码）。
3、我们讨论了浏览器厂商以及标准规范组织可以采取哪些对策以降低此类安全风险。
我们的攻击方法适用于当前版本的Firefox以及（启用实验性功能的）Chrome浏览器，针对带有光传感器的Android以及桌面设备（如MacBook Pro）。
这篇文章由我（@LukOlejnik）以及@arturjanc共同完成，后者编写了一些非常棒的PoC代码。
二、背景：智能手机上的光传感器
现如今，所有的智能手机以及一些现代笔记本电脑都已经搭载了周围环境光传感器（ambient light sensor）。这种传感器位于设备的顶部区域，通常与前置摄像头靠在一起。智能手机一直利用光传感器来调节屏幕亮度，以节省电源消耗，或者用来检测接近动作。周围光线信息可以用于开发响应式手机应用，也可以用来调整硬件配置。因此，光传感器数据也属于敏感信息，我在之前的一篇文章中已提到过这一点。
光传感器返回的数据非常精确。传感器测量的光强度以勒克斯（lux）为计量单位，输出结果范围介于0（黑暗状态）以及数万lux之间。传感器所测得的频率相对较高，支持100-200毫秒粒度的测量间隔。
为了在与原生应用的竞争中占据一席之地，在不久的未来，网站可能具备读取光传感器数据的功能。目前，W3C设备以及传感器工作组正在讨论是否允许网站在不经过用户许可的情况下读取光传感器数据。目前，最新版本的Chrome以及Firefox浏览器都已实现了相关API。
三、 传感器隐私
本文的灵感源自于最近关于通用传感器API的W3C讨论，其中排在前头的一个提案认为访问某些传感器数据时无需经过用户的许可。为了回应这个提案，我们决定调研环境光传感器（ambient light sensor，ALS）是否可以用于恶意场景，这里我想顺便提一下我之前关于ALS安全性以及隐私性方面做的一些研究，我认为ALS可能会导致用户被追踪、用户账户以及数据被泄露：我通过一个例子演示了如何“检测两个人是否在同一时间位于同一个房间”，也分析了ALS应用于检测银行PIN码方面的可能性。
在本文中，我们会把这些例子放在一边，重点介绍攻击者如何利用传感器数据从用户浏览器中提取隐私数据。
接下来，让我们来看一下真实的攻击场景。
四、 通过光传感器窃取信息
攻击者如何通过光传感器数据准确提取隐私数据？我们的攻击方法基于以下两个观测结果：
1、用户屏幕的颜色可以携带信息，处于安全方面考虑，网站无法直接获取这些信息。
2、攻击者可以根据光传感器数据区分不同的屏幕颜色。
我们稍后会详细介绍第二个结论，但简而言之，屏幕发出的光线可以影响光传感器测量结果，因此网站可以确定用户屏幕的颜色（或者在最简单的情况下，网站可以区分黑色的屏幕以及白色的屏幕）。
第一点结论可能更令人惊讶，毕竟所有的网站都可以控制它们在用户屏幕上的显示内容，既然如此，为什么这种数据会携带有用信息？至少在两种情况下，网站无法直接获取用户屏幕的部分颜色信息：
1、已访问链接的颜色。出于隐私原因，浏览器不会告诉开发者某个网页上显示的链接的真实颜色，否则恶意开发者可以使用:visited样式，检测用户历史记录中出现过哪些网址。
2、跨源（cross-origin）资源。同源策略（same-origin policy）会阻止evil.com直接访问victim.com上的资源。然而，虽然网站无法查看其他源的框架（frame）或者图片，但它们可以将这些资源显示在屏幕上，并且修改这些资源向用户呈现的具体方式，比如任意缩放以及改变这些资源的颜色。
我们的攻击方法依赖于这些资源在用户屏幕上的显示效果，通过探测这些资源的颜色，每次能够获取1比特信息。以下是这种攻击方法的操作过程（我们使用了早期实验用的演示场景，以提供详细的参考信息）。
4.1 探测已访问链接
网站可以针对已访问链接以及未访问链接应用不同的样式，然而无法检测这些链接如何呈现给终端用户，我们可以使用传感器来探测这些链接的真实颜色：
1、设置链接样式：已访问链接为白色，未访问链接为黑色。
2、校准：先显示一个白色背景，然后显示一个黑色背景，以识别用户环境中的光线水平。如果传感器读数出现明显波动，也可以据此来校准，不过这种方法更加困难。
3、逐一迭代列表中的链接，依次以填满整个屏幕的大矩形来显示每个链接。已访问的的链接会显示为白色，未访问的链接会显示为黑色。
4、记录下每个链接所对应的光线水平，以识别链接的颜色。由于我们已经在第二步校准了屏幕，因此我们可以识别读取到的是什么颜色。
最后，攻击者可以得到一个包含链接的列表，这些链接在屏幕上显示为白色，因此攻击者就能知道用户之前曾访问过哪些页面。
虽然在我们的演示场景中，我们假设操作过程中周围环境的光线条件没有发生改变，然而如果想要进一步修改PoC以适应动态环境应该也不是个问题。在第一个演示场景中，我们想强调的是，光线度数可能会发生变化，然而，在实际环境中想要克服这个障碍并不困难。
4.2 检测跨源资源
还有更加麻烦的一种情况，那就是攻击者有可能会借此在像素尺度上重现跨源图像以及框架，换句话说，攻击者可以知道给定的某个网站或图像如何呈现给受害者（在我们的演示场景中，我们重点关注的是图像资源，因为这类资源更容易提取）。在极端情况下，如果某个网站将二维码作为紧急状况下的账户恢复手段（https://victim.com/account-code.png），此时攻击者就可以劫持受害者的账户。
这种攻击技术与之前一篇论文的思想类似，具体步骤如下：
1、嵌入被攻击域的一张图像。通常情况下，通过身份认证的不同用户会使用不同的图像（比如已登录用户的头像或者安全码）。
2、使用SVG过滤器创建图像对应的单色版本（SVG过滤器可以应用于跨源资源）。
3、缩放图像，扩展其中的每个像素，使其填满整个屏幕。
4、迭代图像中的所有像素，在用户屏幕上显示每个像素，记录下光传感器对该像素的读数。
5、根据单个像素的读数生成结果图像。
利用这种方法，如果某个文档支持跨域iframe方式，那么攻击者就可以提取这个文档中的所有图像资源以及数据（比如头部中没包含X-Frame-Options字段或者父节点没使用内容安全策略（Content Security Policy））。
五、攻击细节及其他方面考虑
前面我们已经演示了攻击过程，接下来我们讨论一下在实际环境中利用这种技术的一些细节上的考虑。
5.1 检测速度
由于我们每次只能提取一个像素信息，因此这种利用方法的主要限制因素是检测速度。从原理上讲，浏览器传感器可以支持60Hz频率的读取率。然而，这并不意味着实际环境中我们的速度可以达到每秒提取60个比特，因为我们能达到的检测上限与传感器能够检测到的屏幕亮度变化速率有关。在实验中，我们测量发现屏幕亮度数值读取有大约200-300ms的延迟，为了实现可靠的利用过程，我们可以假设读取1比特需要500ms，这样更加现实一些。
在这个速率下，读取各类资源所需要的时间如下所示：
包含8个字符的纯文本字符串：24秒（假设以已知字体显示时，字母及数字字符串中每个字符包含6比特）。
包含16个字符的纯文本字符串：48秒。
20x20大小的二维码：3分20秒。
检测历史纪录中1000个常用URL地址：8分20秒。
64x64像素的图像：34分8秒。
如果某个网站将屏幕颜色在黑白之间随意切换足够长的时间，以便检测长度非常短的文本字符串，通常情况下用户不大可能能忍受这种场景。然而，在某些情况下，如果用户长时间离开目标设备（比如，晚上将设备放在某个支架上），攻击者就可以获取到更多的数据。为了完成这个任务，恶意网站需要使用screen.keepAwake这个API保持屏幕常亮。
在未来，光传感器可能会具备测量光强度或特定颜色饱和度（红色、绿色、蓝色）的功能，这样一来，攻击速度就会大大提高。
5.2 传感器数据精度
虽然传感器本身提供的数据非常准确，实际演示过程中我们会碰到一些困难，比如整个测试期间环境照明条件会发生变化，用户可能会携带设备（尤其是移动电话）四处移动。
我们发现攻击结果的准确性受到一些因素的影响，比如屏幕亮度（亮度较高的屏幕有利于实施攻击）、传感器上方反射面的距离以及角度（手机固定在支架上，接收平面反射的光线时效果较好，缺乏反射面会导致攻击过程更加困难）以及光源数量等（较暗的环境噪音较少，检测过程也更加容易）。
5.3 浏览器支持情况
这种攻击方法适用于两种浏览器：Firefox以及Chrome目前正在使用老式API（ambient light events），这也是我们演示场景中所使用的API。Firefox不需要用户许可就能使用这种方法，对于Chrome浏览器，我们需要通过chrome://flags#enable-experimental-web-platform-features标志启用实验性功能。老式API很快就会被新的API替代（Ambient Light Sensors），Chrome通过chrome://flags#enable-generic-sensor标志实现了新的API，对我们而言，这个API也能达到相同的功能。
我们已经提交了Firefox以及Chrome的安全性/隐私性报告。
六、应对措施
目前有人认为，只需要采取以下保护错误就足以应付这类攻击：
1、限制传感器的读取速率（远小于60Hz）。
2、限制传感器输出数据的精度（以量化输出结果）。
据我们所知，有研究成果表明攻击者可以通过陀螺仪来恢复音频信号，人们根据类似原理提出了这种应对措施。我们认为，Chrome尝试将修复陀螺仪漏洞的方法应用于其他传感器上，然而这种方法可能并不适用于所有情况。基于特定风险构造的威胁模型可能是错误的，并不能面面俱到。
对于光传感器而言，限制采集速率并不能阻止我们的攻击，即使频率低到1Hz也会受到同类攻击影响，只不过速率会有所下降。
只要屏幕的颜色不能影响传感器的输出结果，那么限制输出的精度可能是更好的一种办法。此时可能有些因素能够满足攻击条件（比如屏幕亮度、反射面与屏幕非常接近等），但实际中想成功实施攻击会变得更加困难。
可能最直观的一种解决方案是，浏览器在访问传感器之前需要经过用户的许可，这种限制已经应用于许多功能上（如定位功能）。在Ambient Light Sensor API规范中也需要拓展有关安全性以及隐私性方面的注意事项，以提醒存在这类攻击的安全风险。
6.1 给用户的建议
在Firefox中，关闭传感器，具体方法是转到“about:config”，然后将device.sensors.enabled设为“false”。目前在Chrome中，除非用户手动启用了前面提到的实验功能标志，否则大多数用户应该都是安全的。
6.2 给开发者的建议
为了避免不可信站点将文档资源以iframe方式嵌入，开发者需要在HTTP头部中设置“X-Frame-Options: Deny”字段，这样也能顺便阻止其他类型的攻击（如点击劫持攻击）。
目前我们无法阻止攻击者对图像资源的攻击，因为图像不受X-Frame-Options限制。
七、总结
在本文的攻击场景中，我们演示了恶意网站如何利用表面上人畜无害的光传感器破坏同源策略，窃取跨域数据，提取用户浏览历史记录等敏感信息。
我们还需要认识到一点，从隐私设计角度出来，想要设计正确的规范以及系统是一个非常复杂的过程：未经任何保护的情况下，将敏感API接口提供给Web使用需要谨慎考虑。存在的一个安全风险在于，规范撰写者以及浏览器厂商会根据通用的原则以及研究结果做出决策，而这些决策往往不适用于新的功能特性（比如，基于陀螺仪读数的保护机制对光传感器数据而言可能并不足够）。
最扣人心弦的结论是，技术标准、隐私设计以及隐私影响评估这三方面非常有趣，我们可以从这三方面出发，发现现实世界中存在的一些微妙的问题。如果你在这方面需要帮助，欢迎随时跟我联系。
本文由 安全客 翻译，作者：興趣使然的小胃