标签：注册 解决 lazy http请求 开头 水平 用户组 总计 邮件
与指定用户共享文件是各类常用网站（如Facebook、Twitter、Google和Dropbox）提供的一项常见的服务。确保共享文件只能由特定用户访问的一种常见方法是在请求文件时对用户进行身份验证。本文展示了一种滥用共享图像文件进行有针对性的隐私攻击的新颖方法。在我们称之为“漏洞图像”的这种攻击之中，与特定用户共享的图像可以暴露该用户是否正在访问特定的网站。该类型攻击的基本思想很简单且有效：由攻击者控制的网站请求一个私人共享图像，该图像仅对目标用户有效，并且该用户通过浏览器已登录到共享该图像的网站。除了针对单个用户的针对性隐私攻击之外，本文还将讨论攻击的各种变体，攻击者可以利用这些变体来跟踪一组用户，并在不同网站之间关联用户身份。漏洞图像既不需要JavaScript也不需要CSS，甚至会使具有隐私意识的用户（如在浏览器中禁用了JavaScript脚本的用户）也容易受到攻击。对目前最受欢迎的网站进行的研究表明，隐私泄漏会影响允许用户之间共享图像的30个最受欢迎的网站中的至少8个，其中包括所有网站中的三个最受欢迎的网站。我们已向受影响的网站反馈了该问题，并且大多数站点都在响应我们的报告来修复隐私泄露问题。尤其是，受影响最大的两个网站Facebook和Twitter，已经解决了“漏洞图像”问题。为避免“漏洞图像”攻击，我们在浏览器和图像共享网站这一层面讨论了解决该问题的潜在缓解技术。
很多流行的网站允许用户彼此之间共享图像。例如，各类邮箱服务允许添加图像附件，大多数社交网络支持照片共享，而即时通信软件允许将图像作为对话的一部分发送。我们称允许用户彼此之间共享图像的服务为共享图像服务。
本文提出了一种针对性的隐私攻击，该攻击滥用了一种在流行的图像共享服务中常见的漏洞。基本的思想很简单且有效：攻击者可以通过检查浏览器是否可以访问与此人共享的图像来确定指定用户是否正在访问由攻击者控制的网站。我们称此攻击为漏洞图像，因为共享图像会泄漏有关受害者身份的个人隐私，否则攻击者将无法使用这些信息。为了发起漏洞图像攻击，攻击者通过图像共享服务与受害者私下共享图像，在该服务中，攻击者和受害者都是已注册用户。然后，攻击者将对图像的请求包含在网站中，攻击者想确定受害者是否正在访问该图像。 由于仅允许受害者而不允许其他用户成功请求图像，因此攻击者可以100%地确定受害者是否访问了该网站。
除了漏洞图像的基本描述之外，我们还描述了三种更进一步的攻击方法。首先，我们描述了对用户组的针对性攻击，该攻击解决了单受害者攻击的可伸缩性问题。其次，我们展示了一个假名链接攻击，该攻击利用通过不同图像共享服务共享的漏洞图像来确定这些服务中的哪些用户帐户属于同一个人。最后，我们提供了一种无脚本的攻击，该攻击仅使用HTML，因此即使对于在浏览器中禁用JavaScript脚本的用户也可以使用。
在各种对隐私敏感的场景下，漏洞图像可被用于针对性攻击。例如，执法部门可以利用攻击来收集犯罪嫌疑人正在访问特定网站的证据。同样，政府机构可能会利用攻击找出政治异议人士的真实信息，这样做也许并不高尚。以攻击某个团体为例，攻击的目的是使会议成员实名化。在这种情况下，攻击者将收集所有会议成员的邮件地址，然后通过提供图像共享服务的各类网站将漏洞图像传播给每一位会议成员。接下来，攻击者会将指向外部网站的链接嵌入正在审核的文件中，例如，指向包含其他内容的网站链接。当已登录某个图像共享服务页面的审阅人访问该页面时，漏洞图像将向正在审阅文件的攻击者展示。所有这些攻击的先决条件是，受害者在易受攻击的图像共享服务上拥有一个帐户，并且允许攻击者与受害者共享图像。我们发现至少三个非常流行的服务（Google，Microsoft Live和Dropbox）可以与任何注册用户共享图像，从而可以轻松实现上述攻击。
之所以可能产生该漏洞攻击，是因为图像免于遵循同源策略，并且图像共享服务通过cookie对用户进行身份验证。当浏览器发出第三方图像请求时，它将附加图像共享网站的用户cookie。如果是否授权图像请求的决定取决于cookie，则攻击者可以通过观察图像请求的成功来推断用户的身份。相关文献讨论了将JavaScript排除在同源策略之外的危险性，但据我们所知，目前没有研究观察跨域请求对私有共享图像隐私含义的相关文献。
漏洞图像与目前已知的威胁不同，它可以使任意网站供应商都能准确识别受害者（见Table 1）。一种相关的技术是像素追踪，它使跟踪服务能够确定不同站点的两个访问者是否是同一用户。大多数第三方追踪是由一些主要参与者完成的，从而可以调节这些追踪器处理敏感数据的方式。相反，我们的攻击使任意攻击者和小型网站都可以进行有针对性的隐私攻击。另一相关技术是社交媒体指纹识别，攻击者可在其中了解用户当前是否登录到特定网站。与之相反，漏洞图像攻击不仅能判断用户是否登录，而且能精确地判断是哪个用户进行了登录。漏洞图像攻击类似于跨站请求伪造（CSRF），其中恶意网站代表用户对目标站点执行请求。CSRF攻击通常会对服务器造成副作用，而我们的攻击只是获取图像。我们将在第5节中讨论在何种情况下针对CSRF提出的防御措施以及其他缓解技术可以减少由于漏洞图像造成的隐私泄漏风险。
为了了解漏洞图像问题的普遍程度，我们在250个最受欢迎的网站中研究了30个。我们在这些网站上创建了多个帐户，并检查一个用户是否可以与另一个用户共享漏洞图像。如果可以通过共享图像的所有用户都知道的链接访问共享图像，并且仅对某些用户授予对该图像的访问权限，则可能会造成攻击。我们发现，在研究的30个站点中，至少有8个受到漏洞图像隐私泄露的影响，其中包括一些最受欢迎的站点，例如Facebook，Google，Twitter和Dropbox。我们仔细记录了创建漏洞图像的步骤，并将其作为侵犯隐私行为报告给易受攻击的网站的安全团队。我们总计向八个网站通报了该问题，到目前为止，已经确认了六份报告，其中三份已获得漏洞赏金。大部分受影响的网站都在解决漏洞图像的问题，其中一些网站（例如Facebook和Twitter）已经部署了修复程序。
总而言之，本文做出了以下贡献：
在许多流行的网站，如Dropbox，Google Drive，Twitter和Facebook等，用户可以上传图像并与同一站点的一组明确定义的其他用户共享这些图像。一般来说，一张图像若属于某个用户，则其他用户无法轻易获取该图像。但是，图像所有者可以共享该图像给其他用户。
私密URL：为了控制哪些用户可以访问图像，有几种实现策略。一种策略是为每个共享图像创建一个秘密URL，并将此URL仅提供给允许下载该图像的用户。在这种情况下，任何人只要知道这个地址就可以下载该图片。为了把图像共享给更多用户，有两种不同的实现方法。第一种办法，每个用户有仅属于自己的私人URL，通过此地址可以下载特定的图像，而别的用户无法通过此地址下载图像。另一种办法，所有用户共享同一个私密地址。秘密URL的变体是在给定的时间或给定的使用次数后过期的URL。我们称这些URL为会话URL。
身份验证：控制访问图像的另一种策略是对用户进行身份验证。在图像共享服务中实现身份验证的最常见方法是cookie。用户登录到图像共享服务的网站后，该网站将cookie存储在用户的浏览器中。当浏览器请求图像时，cookie随请求一起发送到图像共享服务，从而使网站的服务器端可以识别用户。
共享图像实例：在不同的真实业务中，图像共享服务实现了不同的策略来控制谁可以访问哪个图像。例如，Facebook主要使用私密URL，由于显然缺乏访问控制策略，最初在用户之间造成了混乱。Gmail依靠私密URL和身份验证的组合来访问附加在电子邮件中的图像。决定如何实现图像共享是在多个设计目标（包括安全性，可用性和性能）之间的权衡。仅使用私密URL的主要优点是第三方内容传送网络可以传送图像，而无需任何跨域访问控制检查。私密URL的一个缺点是，不应在非秘密协议（如HTTP）上使用它们，因为其无法保护所请求URL的保密性。身份验证的主要优点是不需要链接是秘密的，从而可以通过不安全的通道发送链接。不利的一面是，基于身份验证的访问控制使使用第三方内容交付网络更加困难，因为基于cookie的授权无法跨域使用。
同源策略：同源策略控制网站的客户端脚本在何种程度上可以访问网站的文档对象模型（DOM）。作为默认策略，不允许从一个来源加载的任何脚本访问从另一个来源加载的DOM的一部分。这里“来源”是指URI方案（例如http），主机名（例如facebook.com）和端口号（例如80）。例如，默认策略意味着嵌入了来自facebook.com的iframe的网站evil.com无法访问从facebook.com加载的DOM部分。上述默认策略有一些例外。其中之一是对第三方图像的加载，这对于漏洞图像攻击至关重要。与其他DOM元素相比，从一个来源加载的脚本可以访问从另一个来源加载的图像，包括该图像是否已全部加载。 对于上面的示例而言，evil.com被允许检查从facebook.com请求的图像是否已成功下载。
本节介绍了可以使用漏洞图像进行的一系列攻击。首先，我们描述了可能发生攻击的条件（第3.1节）。然后，我们提出针对个人用户的基本攻击（第3.2节），针对用户组的攻击（第3.3节）以及链接在不同网站上注册的个人身份的攻击（第3.4节）。 接下来，我们证明该攻击既不依赖JavaScript也不依赖CSS，可以由纯基于HTML的网站执行（第3.5节）。最后，我们讨论了漏洞图像与以前与隐私相关的问题（例如Web跟踪）的比较（第3.6节）。
我们的攻击模型是攻击者想要确定特定受害者是否正在访问由攻击者控制的网站。从隐私的角度来看，此信息很重要，并且网站管理者通常难以获取。网站管理者可能能够获取有关访问该网站的客户端的一些信息，例如客户端的IP和浏览器版本。然而，例如由于多个客户端共享相同的IP或使用相同的浏览器版本，所以该信息是有限的，并且通常不足以高置信度来识别特定用户。而且，有隐私意识的用户可以通过使用Tor浏览器来进一步模糊其上网痕迹，该浏览器隐藏了关于客户端的IP和其他细节。流行的跟踪服务（例如Google Analytics）还可以有限地了解哪些用户正在访问哪些网站。但是，此信息的使用受到法律管制，仅对少数跟踪服务可用，并且仅以匿名形式与网站管理者共享。相比之下，此处考虑的攻击使网站的任意管理者可以确定特定人员是否正在访问该网站。
只要同时满足以下四个条件，就可能发生漏洞图像攻击。首先，我们假设攻击者和受害者都是同一图像共享服务的用户。由于许多图像共享服务提供了超出其本身的其他流行服务，例如电子邮件或社交网络，因此它们的用户群通常覆盖了Web用户的很大一部分。例如，Facebook宣布拥有超过20亿的注册用户，而Google则报告每月拥有超过10亿的活跃Gmail用户。此外，针对特定受害者的攻击者只需在受害者所在的图像共享服务处注册即可。其次，我们假设攻击者可以与受害者共享图像。对于许多图像共享服务，此步骤只涉及了解受害者的电子邮件地址或用户名，正如我们在第4节中将进一步讨论的那样。第三，我们假设受害者在访问受攻击者控制的网站的同时访问了受攻击者控制的网站。受害者的浏览器已登录到图像共享服务。考虑到某些图像共享服务的受欢迎程度以及始终可以登录的便利性，我们相信许多用户至少可以使用一项图像共享服务满足此条件。特别是在Google Chrome浏览器和Android操作系统中，用户在安装后立即使用其Google帐户登录并始终保持登录状态。
漏洞图像攻击的第四个也是最后一个条件是：图像共享服务确定是否来自应该查看该图像的用户的请求。表2根据第2节中对秘密URL的描述和基于身份验证的访问控制显示了可能的实施策略的二维矩阵。上表第一列表示网站可以依赖或不依赖身份验证。第二列表示网站可以通过公共URL，允许访问该图像的用户之间共享的秘密URL或每个用户的秘密URL使图像可被访问。上表中的六种情形，有五个与本文相关。第六种是通过公共URL共享图像而不进行任何身份验证，会使该图像可供所有Web用户使用，因此不在本文讨论范围之内。漏洞图像攻击在上表中五个可能情况中的两种情况下有效（情况（1）和（2））。具体来说，漏洞图像攻击适用于以下网站：这些网站通过身份验证保护共享的图像，每个共享图像使用一个秘密URL或者根本不使用秘密URL。第4节表明这些情况实际上是在发生的，它们影响了当今一些最受欢迎的网站。
在介绍了漏洞图像攻击的先决条件之后，我们现在基于上述内容描述几种隐私攻击。我们从攻击的基本版本开始，该版本针对单个受害者用户，并确定受害者是否正在访问由攻击者控制的网站。为此，攻击者将图像i上传至图像共享服务，于是攻击者成为图像i的所有者。接下来，攻击者利用图像共享服务将图像i共享给受害者victim。最终，攻击者和victim同时可访问图像i。然后，攻击者将对i的请求嵌入到网站s中，攻击者希望针对该网站确定受害者是否正在访问该网站。由于图像免于遵循同源策略（第2节），因此s的受攻击者控制的部分可以确定图像是否成功加载，并将此信息报告给攻击者。一旦受害者访问网站s，图像就会被请求成功，攻击者就知道了受害者访问了网站s。如果其他用户访问了s，图像就无法被请求成功，因为s无法认证其他用户。我们假设攻击者不访问s，因为这可能导致攻击者误以为受害者访问了s。
因为图像共享服务的身份验证机制确保只有攻击者和受害者才能访问图像，所以漏洞图像攻击可以100％确定目标受害者是否已访问该网站。同时，受害者可能不会注意到他已被跟踪，因为可以将图像加载到网页后台。
例如，上图展现了带有嵌入式JavaScript的简单HTML代码。该代码请求漏洞图像，检查该图像是否已成功加载，然后通过另一个HTTP请求将此信息发送回攻击者控制的Web服务器。我们假设httpReq是一种使用标准浏览器功能（例如XMLHttpRequest或innerHTML）执行此类请求的方法，用于将第二个参数的值发送到作为第一个参数传递的域。 除了使用onload来检测图像是否已加载外，还有其他几种变化，例如，检查加载的图像的宽度或高度。 如下所示（第3.5节），在完全基于HTML的网站（即没有JavaScript）中也可以进行攻击。
攻击之所以有效，是因为同源策略不适用于图像。也就是说，攻击者可以通过跨源请求将漏洞图像包括到网站中，并观察该图像是否可访问。相反，请求HTML文档不会导致类似的隐私泄漏，因为浏览器会严格区分来自不同来源的HTML。攻击成功的第二个原因是当今的浏览器会在第三方图像请求中自动包含受害者的cookie。最终，该请求通过了图像共享服务的身份验证，从而暴露了该请求来自受害者浏览器。
下面描述了针对一组用户而不是单个用户的漏洞图像攻击的一种变体。在这种情况下，攻击者考虑了包含了n个受害者的用户组，并希望确定其中哪些受害者正在访问特定网站。
例如，考虑针对公司员工的中等规模钓鱼活动。在准备了实际的钓鱼有效负载（例如，个性化电子邮件或克隆的网站）之后，攻击者可能会使用一组漏洞图像，以更好地了解哪些受害者与有效负载进行交互以及以哪种方式进行交互。在这种情况下，漏洞图像会成为攻击者的一种分析工具。
例如要追踪10,000个用户，则需要10,000个共享图像和10,000个图像请求。换句话说，攻击的时间复杂度为O(n)。对于这个例子，由于网络钓鱼的性能下降和网络请求数量的增加，这种不成熟的攻击方式可能会引起怀疑。
为了有效地攻击一组用户，攻击者可以利用图像共享服务允许与多个用户共享单个图像这特点。基本思想是使用位向量对每个受害者进行编码，并将每个位与一个共享图像相关联。通过请求与每个比特相关的图像，网站可以计算用户的比特向量，并确定用户是否在受害者中，如果是，则确定是哪个受害者。这种方法启用了对用户组的二叉搜索，如上图所示，针对七个用户。该网站包括请求图像i1，i2和i3，然后根据图像的可用性确定目标受害者中哪个用户访问了该网站的代码。如果没有图像可用，则用户不在目标受害者之列。对比之前的攻击方法，这种攻击复杂度为O(log(n))。
实际上，对一组用户发起漏洞图像攻击需要与目标用户的不同子集共享一组图像。可以通过图像共享服务提供的API或通过UI级别的Web自动化脚本来自动执行此过程。但是，此过程很可能是特定于指定网站的，这使得一次攻击多个网站的代价很高。
第三种基于漏洞图像的攻击旨在将单个人在不同图像共享服务上拥有的多个身份关联起来。假设siteA和siteB是两个图像共享服务，userA和userB是两个分别在这两个图像共享服务处注册的用户。攻击者想确定userA和userB是否是同一个人。例如，执法机构可能执行此攻击，以检查参与犯罪活动的用户帐户是否与已知属于犯罪嫌疑人的另一个用户帐户匹配。
为了链接两个用户身份，攻击者实质上并行执行两次漏洞图像攻击。具体来说，攻击者通过一个图像共享服务与userA共享一个图像iA，并通过另一图像共享服务与userB共享一个图像iB。攻击者控制的网站同时请求iA和iB。一旦目标个人访问该站点，两个请求将成功，并确定用户userA和userB对应于同一个人。对于该网站的任何其他访问者，至少一个请求将失败，因为只有在浏览器同时登录到用户帐户userA和userB时，两个请求才会成功。
链接用户身份的基本思想通常适用于两个以上的图像共享服务以及单个以上的用户帐户。例如，通过并行对用户组执行两次攻击（如3.3节所述），攻击者可以在两组用户之间建立成对关系。
漏洞图像攻击原理是客户端网站请求图像并向攻击者控制的服务器端报告请求是否成功。一种实现方法是使用客户端JavaScript代码。但是，具有隐私意识的用户可能会完全禁用JavaScript或使用一种安全机制，以防止JavaScript代码读取有关从不同域加载的图像的详细信息。
我们提出了仅使用HTML代码（即不使用任何JavaScript或CSS）实现的漏洞图像攻击的一种变体。其原理是使用object HTML标签，该标签允许网站在加载某些先前指定的内容时出错时指定要加载的后备内容。当嵌套这样的对象元素时，浏览器首先请求外部元素中指定的资源，如果失败，它将向内部元素执行请求。本质上，此行为与纯HTML中的逻辑if-not指令相对应，攻击者可能会使用该指令来实施漏洞图像攻击。
下图显示了此攻击变体的示例。我们假设目标组中有三个用户u1，u2和u3，并且攻击者可以与每个用户共享来自dropy-domain.com的漏洞图像。开头的注释描述了确切的共享配置。我们需要log(n)个图像来跟踪n个用户，就像针对一组用户的基于JavaScript的攻击一样（第3.3节）。我们假设服务器端在接收到请求后就生成了攻击代码，并且所生成的代码包含一个会话ID，这是指向evil.com链接的一部分。在该示例中，会话参数ID为2342。其目的是使服务器端代码能够链接来自同一客户端的多个请求。
此攻击变体的主要原理是将请求发送到攻击者的域，作为漏洞图像请求的后备。例如，如果对第4行的漏洞图像i1的请求失败，则会向evil.com请求第5行的替代资源。此请求就会暴露当前用户无法访问图像i1，即info = not_i1。通过对所有漏洞图像执行类似的请求，攻击者会获得足够多的信息以精确识别单个用户。例如，如果在给定的会话中，evil.com收到not_i1，但没有收到not_i2，则攻击者可以得出用户为u2的结论。因为服务器端会根据用户的请求来推断用户，所以在得出任何结论之前确保当前的跟踪会话成功完成非常重要。具体来说，我们必须确保在渲染所有嵌套object标签之前，用户或浏览器没有停止页面加载。确保此属性的一种方法是，在第11到13行中向不存在的图像添加足够数量的嵌套请求，然后在第14行中向攻击者发出通知，告知其跟踪已完成。服务器将丢弃不包含最后一条消息的会话。
作为概念证明，我们在最新的Firefox和Chrome浏览器中测试了示例攻击及其几种变体，并发现纯HTML攻击可以按预期工作。
漏洞图像攻击与广泛使用的跟踪像素（也称为网络信标）有关，但是两者在谁了解用户身份方面有所不同。跟踪像素是网站从跟踪网站STrack加载的小图像。图片请求包含用户的cookie，从而使跟踪器能够识别不同页面访问中的用户。 最终，跟踪服务可以分析s个用户的哪些页面访问并将此信息以汇总形式显示给s的提供者。如果跟踪器还在用户注册的地方运行服务，则它可以了解哪个用户访问了哪个站点。相反，漏洞图像使站点的管理者可以了解目标用户是否正在访问，无需依赖跟踪器来共享此信息，而是通过滥用图像共享服务来实现。至于跟踪像素，攻击者可以使用1x1像素大小的图像来部署漏洞图像攻击，以减少其对页面加载时间的影响。
Web指纹技术使用Web浏览器的高熵属性（例如，已安装的字体集或浏览器窗口的大小）来启发式地识别用户。像指纹识别一样，漏洞图像旨在破坏用户的隐私。与指纹识别不同，此处提出的攻击使攻击者可以确定特定的用户帐户，而无需认识到一个访客可能与另一访客相同。此外，漏洞图像可以100％地确定访问者的身份，而指纹识别则依赖于浏览器属性的熵。
漏洞图像非常适合有针对性的攻击，但不适用于大规模跟踪数百万个用户。 原因之一是漏洞图像要求攻击者与每个受害者共享一个图像，这不可能扩展到数百个用户。另一个原因是，网站需要执行的图像请求数量与目标用户的数量呈对数增长，如第3.3节所述。因此，相比跟踪像素或Web指纹识别技术，漏洞图像更适合于目标（一组）个体。据报道，这种有针对性的攻击越来越普遍，尤其是在与高价值受害者打交道时。
上一节中介绍的攻击有几个假设。尤其是，漏洞图像取决于现实世界中的图像共享服务如何实现对共享图像的访问控制。为了了解本文讨论的热门网站以何种程度上受到隐私问题的影响，我们系统地研究了漏洞图像的普遍性。以下内容介绍了我们的方法论（第4.1节），我们的主要研究结论（第4.2节），并讨论了我们为以负责任的方式披露发现的问题所做的持续努力（第4.3节）。
为了选择流行的图像共享服务进行研究，我们根据“Top Moz 500”榜单检查了前500个最受欢迎的网站。我们专注于使用户能够彼此共享数据的网站。我们排除不提供英语界面的网站和不提供创建用户帐户可能性的网站。这次选择产生了30个网站的列表，我们将对其进行详细研究。上表列出了所研究的网站及其受欢迎程度。该列表包含六个最受欢迎的网站，以及十个最受欢迎的网站中的九个。分析的许多站点都是社交媒体平台，用于共享某种数据的服务以及通信平台。
我们攻击的一个条件是攻击者可以与受害者共享图像。我们仔细分析了上表中的30个站点，检查该站点是否提供图像共享服务。为此，我们在每个站点上创建多个帐户，并尝试使用不同的渠道（例如，聊天窗口或社交媒体共享）在这些帐户之间共享图片。在两个帐户之间共享图像后，我们将检查两个帐户是否确实有权访问该图像。如果满足此要求，我们将检查第三个帐户是否无法访问该图像。
对于充当图像共享服务的网站，我们检查共享图像的访问控制是否以导致漏洞图像的方式实现，如前文表2所示。具体地说，我们检查对共享图像的访问是否受到保护。通过身份验证以及两个用户是否都通过公共链接（即攻击者已知的链接）访问图像。同时满足此条件的站点会使其用户遭受漏洞图像攻击。
在我们研究的30个网站中，总共确定了八个包含漏洞图像的网站。如上表所示，受影响的站点包括三个最受欢迎的站点，即Facebook，Twitter和Google，它们代表了我们研究的所有站点的25％以上。下面详细讨论每个易受攻击的站点，并说明攻击者如何与目标用户建立漏洞图像。下表以简洁的方式进行了总结。
Facebook：一般而言，托管在Facebook上的图片是由内容发布网络提供的，这些内容发布网络不是托管在facebook.com，而是托管在fbcdn.net。因此，facebook.com上的cookie不会与对共享图像的请求一起发送，从而使得漏洞图像攻击无效。但是，我们发现了此规则的例外，例如，可以在https://m.facebook.com/photo/view_full_size/?fbid=xxx处放置漏洞图像。其中，参数fbid是与Facebook上的每张图片相关联的唯一标识符，并且很容易从图像页面的地址栏中获取此标识符。攻击者必须收集此标识符，并将其与上面提供的漏洞图像URL连接起来。通过调整图片的隐私设置，攻击者可以控制有权访问图片的朋友子集，从而为个人和团体攻击打开大门。在Facebook上创建漏洞图像的先决条件是受害者是攻击者的“朋友”。
Twitter：在Twitter上的私人聊天中发送的每个图像都是漏洞图像。如果受害者和攻击者之一在其设置中选中了“接收来自任何人的直接消息”，或者其中一个是另一个的关注者，则受害者和攻击者可以在私人聊天中交换消息，从而发送图像。根据两个参与者的登录状态，只能由两个参与者访问通过私人聊天发送的图像，即，这些图像是漏洞图像。攻击者可以轻松地从会话中检索漏洞图像URL，并将其包含在另一个页面中。通过Twitter进行攻击的局限性在于，我们目前不知道一种与多个用户同时共享图像的方式。
Google：我们在Google中发现了两个漏洞图像攻击方式：一个在Google云端硬盘文档的缩略图中，一个在Google Hangouts对话中。要与受害者共享文档，攻击者仅需要受害者的电子邮件地址，而要发送Google Hangouts消息，受害者需要接受来自攻击者的聊天邀请。基于缩略图的攻击功能更强大，因为它可以轻松地向有权访问图像的用户组中添加和删除用户。此外，通过在共享时不选择“通知人”选项，受害用户甚至不知道此操作。不过，Google Hangouts的一个优势是，与聊天室相比，受害者在聊天中收到图片后，就无法撤消其对漏洞图片的权利，而在云盘中，受害者可以从中删除共享文档。
Wordpress：为了通过Wordpress创建漏洞图像，攻击者需要说服受害者成为其博客的读者，或者反之。建立此连接后，共享私人博客上发布的每个图像都是两个用户之间的漏洞图像。要满足这一强大的先决条件，可能需要不平凡的社会工程。
GitHub：GitHub上的私有代码库可以存放漏洞图像。 一旦受害者和攻击者共享了这样的代码库，就可以通过Web接口中的链接访问每个提交的图像，例如https://github.com/johndoe/my-awesome-project/raw/master/car.jpg。只有已登录GitHub且被授予对存储库my-awesome-project的访问权限的用户才能访问该图像。为了控制有权访问图像的用户数量，攻击者可以删除项目或向项目添加参与者。
Dropbox：通过将HTTP参数dl = 1附加到共享图像URL，可以通过漏洞图像端点访问Dropbox上传的每个图像。 Dropbox允许攻击者与任意电子邮件地址共享此类图像，并通过随时包括和排除用户来微调访问图像的权限。共享图像后，就可以成功部署我们的攻击，而无需受害者接受共享图像。但是，受害人可以通过从其帐户的“共享”部分中删除图像来撤销其访问图像的权利。
第一个也许也是最重要的发现是，许多最受欢迎的网站都允许攻击者创建漏洞图像。从攻击者的角度来看，一张漏洞图像足以跟踪用户。如果受害者使用至少一种受影响的图像共享服务注册为用户，则攻击者可以在该服务上创建用户帐户，并与受害者共享漏洞图像。
几种受影响的图像共享服务使攻击者可以与特定用户共享图像，而无需通知用户。例如，如果攻击者在她的Facebook个人资料上发布了图像，并调整了隐私设置，以便只有受害者可以访问它，那么就不会以任何方式通知受害者。另一个示例是Google云盘，它可以与任意电子邮件地址共享文件，同时指示网站不要发送通知其他用户的电子邮件。
对于某些服务，受害者会以某种方式得知已经建立了与攻击者的连接。例如，要在Twitter上设置漏洞图像，攻击者需要向受害者发送私人消息，这可能会使受害者感到可疑。但是，即使受害者知道共享的图像，对于大多数网站，用户也无法撤消其访问图像的权利。具体来说，假设受害者从Google联系人那里收到了一张可爱的猫图片。现在让我们假设受害者知道漏洞图像攻击，并且怀疑图像的发送者跟踪了她。我们不知道受害者可以以任何方式撤消访问所接收图像的权利。
秘密URL和按用户身份验证的URL是广泛实施的技术，可防止我们受到攻击。但是，许多网站使用多种此类策略，因此，只要API端点之一使用漏洞图像就足够了。识别此端点通常是一项艰巨的任务：例如，对于Facebook，大多数网站都严格实现了秘密URL，但是属于移动子域的一个API端点暴露了漏洞图像。 确定此端点后，我们意识到也可以从桌面浏览器毫无问题地访问它，从而启用了我们在第3节中描述的所有攻击。
在可以共享漏洞图像之前，某些图像共享服务需要攻击者和受害者之间的信任关系。例如，攻击者必须先在Facebook上与受害者成为朋友，然后再与受害者共享图像，而Dropbox或Google Drive上没有这样的要求。但是，考虑到大多数用户在社交网络上有数百个朋友，因此很有可能在攻击开始之前就建立了信任通道。就Wordpress而言，“受害者是攻击者的私人博客的查看者”的先决条件似乎很难满足，并且可能需要高级的社会工程学但是，我们认为，此类漏洞图像在某些针对性攻击中仍然可能有用。
由于我们对漏洞图像发生率的研究大部分是手动的，因此我们不能保证无法为我们创建漏洞图像的22个站点不受此问题的影响。不过，对于某些网站，我们相信它们不会受到影响，因为这些网站不允许用户上传图片。更详细的分析将需要深入研究所研究站点的实现，并且理想情况下还需要访问服务器端源代码。 我们希望我们的结果能刺激将来进行更多自动分析以识别漏洞图像的工作。
在确定出现漏洞图像共享服务后，我们与相关的安全团队联系，以负责任的方式反馈了该问题。在2018年3月26日至3月29日之间，我们发送了以下一般问题的详细说明：如何滥用特定网站来创建漏洞图像，以及它如何影响网站用户的隐私。我们联系的大多数安全团队非常有责任心，并渴望在解决问题时进行合作。
表3的最后三列总结了被联系公司的安全团队对我们报告的反馈。对于大多数网站，安全团队确认，所报告的漏洞值得修复，并且至少有六个站点已解决此问题或已决定修复该问题。特别是，排名前三的网站都确认了所报告的问题，并且都在着手进行修复。考虑到这些站点的庞大用户群以及漏洞图像对其用户的隐私影响，这种反应可能并不令人惊讶。作为对我们报告的赞赏的另一个标志是，作者从八个受影响的站点中的三个（到目前为止）收到了赏金。
我们的两个报告被标记为误报。相应网站的安全团队回答说，漏洞图像是“期望的行为”，或者对用户隐私的影响是有限的。将表3与表4进行比较，可以发现，与其他站点相比，创建报告泄漏的先决条件更难实现的站点是其他网站：在GitHub上创建漏洞图像需要攻击者和受害者共享一个私人代码库，而Wordpress要求受害者是攻击者私人博客的查看者。尽管我们同意这两个站点的攻击面相对较小，但是漏洞图像仍可能导致令人惊讶的隐私泄漏。例如，如果员工的公司使用私有GitHub代码库，则员工可能会跟踪其同事甚至老板。
为了说明图像共享服务如何解决漏洞图像问题，我们描述Facebook如何根据我们的报告解决该问题。如前所述，Facebook主要使用秘密URL，并使用内容分发网络来服务图像。但是，我们能够确定使用漏洞图像的移动API端点，并将用户重定向到相应的内容交付网络链接。该端点在移动用户界面中用于使用户能够下载图像的全分辨率版本。重新执行是在HTTP级别执行的，因此当使用<a>HTML标签将其插入第三方网站时，会导致成功的图像请求。Facebook部署的修复程序是在JavaScript级别执行重定向，即加载包含HTML片段的中间HTML，该JavaScript片段重写了document.location.href。此修复程序使良性用户仍可以通过浏览器请求成功下载全分辨率图像，但禁用第三方图像。但是，我们认为这样的修补程序不能泛化，也不能部署到其他已确定的漏洞。因此，在第5节中，我们描述了防止漏洞图像攻击的替代方法。
总体而言，我们从公开漏洞图像的经验得出的结论是，流行的网站认为这是一个严重的隐私问题，并且他们有兴趣检测和避免漏洞图像。
在本节中，我们描述了几种防御漏洞图像攻击的技术。缓解措施包括网站可以部署的服务器端修补程序，可以使用户控制与他们共享的内容的改进的隐私设置，以及基于浏览器的缓解措施。
抵御本文提出的攻击的最简单方法是，修改图像共享服务的服务器端实现，这样就无法创建漏洞图像。解决此问题有多种方法。
首先，该问题的一个有争议的解决方案是完全禁用经过身份验证的图像请求。图像共享服务可以不依赖于cookie来控制谁可以访问图像，而可以仅将秘密链接传递给那些应该访问图像的用户。用户知道链接后，无论是否登录到图像共享服务，都可以通过链接自由获取图像。此策略对应于表2中的情况5。我们在表3中报告的多个网站都采用了这种图像共享策略。最著名的例子是Facebook，该公司在其网站的大部分地方都采用了这种技术，而Dropbox将该技术作为其链接共享功能的一部分来实现。此修复程序的缺点是，在图像共享服务无法控制的范围内，链接的保密性可能会以多种方式受到损害：通过使用不安全的通道（例如HTTP），浏览器中的旁道攻击（例如缓存攻击），或者只是因为用户不了解保密要求，而让用户以不安全的方式处理链接。
其次，一种解决方法是在服务器端实施更严格的基于cookie的访问控制。在这种情况下，图像共享服务会强制每个用户通过秘密的特定于用户的链接访问共享图像，该链接不会在用户之间共享。其结果是，攻击者不知道受害者可以使用哪个链接来访问共享图像，因此攻击者无法在任何网站中嵌入这样的链接。 该实现策略对应于表2中的情况3。不利之处在于，由于需要额外保证用户和URL之间的映射，尤其是在涉及内容传递网络时，实现此防御可能会带来挑战。此外，由于添加了访问控制机制，它可能会导致每个图像请求的速度下降。
第三，可以针对CSRF（跨站请求伪造）攻击部署缓解措施。其中之一是使用原始HTTP头来确保给定图像只能嵌入在特定网站上。浏览器会在每次请求时自动发送原始HTTP标头，它可以精确标识请求资源的页面。服务器端可以检查请求的来源，并拒绝通过身份验证的图像响应未知的第三方请求。例如，facebook.com可能拒绝以有效图像响应原始设置为evil.com的HTTP请求。但是，这种缓解措施无法抵御注入到受信任域中的跟踪代码。例如，直到最近Facebook才允许用户在其个人资料页面上发布自定义HTML代码。如果用户决定在配置文件页面上插入基于漏洞图像的跟踪代码，并在目标用户访问配置文件页面时得到通知，则针对CSRF的缓解措施将无法阻止攻击。原因是请求的来源将设置为facebook.com，因此服务器端代码将信任该页面并提供图片。
同样，服务器端可以在经过身份验证的图像请求上设置Cross-Origin-Resource-Policy （跨源资源策略）响应标头，从而限制哪些网站可以包含特定图像。浏览器将仅渲染请求来源与嵌入网站的来源匹配的图像，或者它们对应于同一网站的图像。该解决方案比前面讨论的原始检查更粗糙，因为它不允许对经过身份验证的图像进行跨源集成，但是由于只需要一个标头集而不是标头检查，因此部署起来更容易。提出From-Origin标头是为了允许使用更细粒度的集成策略，但是到目前为止，浏览器供应商方面都没有兴趣实现这种功能。
另一个适用的CSRF缓解措施是SameSite cookie属性。如果将Cookie设置为“严格”，则该属性会阻止浏览器将Cookie与跨站点请求一起发送，从而有效防止漏洞图像。但是，“严格”设置对于大多数图像共享服务而言可能过于严格，因为它会影响到服务网站的所有链接。例如，公司电子邮件中指向私有GitHub项目或私有Google Doc的链接将不再起作用，因为单击链接时，会话cookie不会随请求一起发送。SameSite属性的不太宽松的“松散”设置不会受到这些问题的影响，但是由于它不会影响GET请求，因此也不能防止漏洞图像攻击。
所有上述服务器端防御的挑战在于，它们首先需要开发人员意识到漏洞。根据我们的经验，复杂的网站可能允许以几种方式共享图像，可能跨越图像共享服务所支持的不同UI级别的用户交互和不同的API端点。由于严格检查共享图像的所有可能方式并非易事，因此我们认为需要在以后的工作中自动识别漏洞图像。我们建议的方法至少可以通过有限的努力实现自动化。要检查图像请求是否需要身份验证，可以在用户登录的一个浏览器中执行该请求，然后在浏览器的另一实例中以“私有”或“隐身”模式尝试相同的请求，即无需比较这两个请求是否成功，可以发现图像请求是否依赖于任何形式的身份验证，例如cookie。自动化其余方法需要图像共享服务的一些支持。特别是，要自动检查漏洞图像仅由一部分网站用户访问，就需要API处理用户帐户并在用户之间共享图像。
尽管在识别漏洞图像方面存在挑战，但我们认为，至少在短期内，服务器端缓解措施是最直接的解决方案。从长远来看，将需要更完整的解决方案，例如以下所述。
当前的HTTP标准没有为第三方cookie指定策略，但是它鼓励浏览器供应商尝试不同的此类策略。更准确地说，当前标准允许浏览器决定是否自动将用户的Cookie附加到第三方请求。大多数浏览器都决定附加第三方cookie，但是有某些反例，例如Tor浏览器。在Tor中，cookie仅发送到用户在地址栏中键入的地址。
考虑到漏洞图像和其他先前报道的跟踪技术可能带来的隐私隐患，一种可能的缓解措施是浏览器将默认行为指定为不发送带有第三方（图像）请求的cookie。 如果此行为被覆盖（可能使用特殊的HTTP标头或标记），则应通过透明机制通知用户。而且，应该为用户提供防止网站覆盖默认行为的可能性。我们认为，这项措施将符合新近通过的欧盟《通用数据保护条例》的精神，该条例要求通过设计和默认方式来保护数据。但是，这种极端的举动可能会影响网络生态系统中的某些参与者，例如广告生态系统。为了解决此问题，广告商可以决定采用更安全的分发机制，例如Brave浏览器流行的分发机制。
前面讨论的策略的替代方法是允许经过身份验证的图像请求，但仅在浏览器确信经过身份验证的请求与未经过身份验证的请求之间没有可观察到的差异时才呈现它们。为此，浏览器可以执行两个图像请求：一个带有第三方cookie的请求和一个不带第三方cookie的请求。如果浏览器收到两个对等的响应，则可以安全地呈现内容，因为不会泄露有关已认证用户的敏感信息。该解决方案仍将允许大多数第三方cookie的使用，例如跟踪像素，但可以防止此处所述的漏洞图像攻击。可能的不利因素可能是由于表2中的策略（3）造成的误报，但我们假设对此类图像的请求很少出现在一般的第三方图像请求中。该解决方案的第二个可能的缺点可能是Web流量的增加和潜在的性能损失。未来的工作应该测试这种防御的好处以及附加图像请求所带来的成本。
为了减少附加图像请求带来的成本，默认情况下，混合机制可以禁用经过身份验证的图像请求，并仅允许它们用于CSP指令指定的资源。对于允许的已认证图像，浏览器将部署先前描述的双重图像请求机制。我们主张将此作为我们首选的浏览器级防御，因为它还可以防御其他隐私攻击，例如通过旁道读取第三方图像像素，同时仍允许良性使用。
与ShareMeNot类似，也可以实现一种浏览器机制，其中所有第三方图像请求都被阻止，除非用户通过提供明确同意来授权它们。为了减轻用户的负担，可以部署一种混合机制，其中网站仅对用户需要提供同意的图像子集要求经过身份验证的请求。
当允许第三方cookie时，另一种解决方案是让浏览器实现某种形式的信息流控制，以确保不能将第三方请求是否成功加载的事实发送到浏览器之外。在受污染的画布中部署了类似的方法，该方法禁止在画布上绘制第三方图像后读取像素。但是，在实践中为第三方图像实现这种信息流控制可能会遇到挑战，因为可以通过多个侧面通道（例如，div包含的object标签或通过读取图像的大小）来检索图像是否已成功加载的事实。
本节中描述的机制在部署它们所需的实施工作方面以及它们对Web现有状态的可能影响（即与现有网站不兼容）方面都有所不同。因此，为了帮助浏览器供应商做出明智的决定，未来的工作应该以Calzavara等人的研究结果为主，兼容性和部署成本方面对所有这些防御措施进行深入分析，并可能提出其他解决方案。
我们发现，用户对图像共享过程几乎没有控制权。例如，对于某些图像共享服务，用户没有任何选择来限制其他用户可以私下与其共享图像。在其他情况下，用户无法撤消其访问特定图像的权利。而且，在我们分析的大多数网站中，甚至很难获得与当前帐户私下共享的图像的完整列表。例如，想要获得此列表的用户必须检查消息传递平台中的所有对话或社交网络上所有朋友的所有图像。
我们认为，图像共享服务应该为用户提供对图像共享策略的更多控制，以使具有隐私意识的用户能够保护其隐私。具体来说，应该允许用户决定谁有权与其共享图像，并且应该授予用户撤销对特定图像的访问权限。理想情况下，网站还将为用户提供与其共享的所有图像的列表，以及一个透明的通知机制，当对该列表进行某些更改时，该机制会通知用户。利用这些工具为用户提供帮助，可以通过吸引用户注意可疑图像共享，从而允许用户撤消对漏洞图像的访问权限，从而减轻某些漏洞图像的攻击。
本节介绍的针对Web用户的隐私控制将主要对高级用户有用，而大多数用户不太可能利用这种细粒度的控制。因此，我们认为针对漏洞图像的最有效缓解措施是应用在服务器端或浏览器端的缓解技术。
本文介绍了漏洞图像攻击，这是一种有针对性的匿名攻击，它利用了流行网站中使用的特定访问控制漏洞。该攻击的主要原理简单而有效：可以利用免于同一来源策略的私人共享资源来揭示特定用户是否正在访问由攻击者控制的网站。我们描述了这种攻击的几种形式：针对单个用户的攻击，针对一组用户的攻击，跨站身份链接和仅基于HTML的攻击。
本文展示了某些最受欢迎的网站存在的漏洞图像问题，并且该问题通常会影响这些网站的所有注册用户。作者将所有已确定的漏洞报告给了受影响网站的安全团队。他们中的大多数都承认这些反馈问题，并且有些团队已经开始着手进行解决。这些反馈表明作者发现的漏洞图像问题对相关从业者很重要。本篇论文有助于提高开发人员和研究人员的安全意识，以避免将来出现此隐私泄漏问题。
学习总结：从初春到盛夏，这学期总算告一段落。网络攻防实践这门课与本学期其他课程有所不同，基本上涉及的所有知识全部都需要自己深入学习并加以实践，对于部分章节，由于自己水平有限，加上时间仓促，精力不足等因素，实践的过程可谓及其艰难。我承认大部分的实践内容都参考了其他同学的博客，在此对他们表示深深的感谢。在完成所有实践后，最大的感受就是网络攻防真的是一件很艰难的事情，它涉及到的知识面广而宽，内容精而细，每一步操作都需要深思熟虑并且掌握其原理，否则只会举步维艰，很难继续进行下去。同时，由于教材书中的内容时至今日已经显得有些过时了，大部分内容都产生了不小的变化，以至于大部分实践过程都需要自己去探索与尝试，在这个过程中不断地试错，不断地遇到困难，不断地去解决，这一过程虽然烦琐且耗费时间，但这毫无疑问是值得的。学完这门课，我深知这仅仅是一个开始，未来还有很长的路要走，很多未知的困难要面对，加油！
课堂建议：部分章节的内容比较多，希望考虑能多留一些时间去总结与实践，因为同时要学习很多门课程，如果时间仓促精力有限，就会不得不压缩时间去完成，于是学习效果势必大打折扣。其次，建议老师根据每次实践的重点内容稍作讲解，如原理介绍和攻击流程等，以加深学习印象。
Leaky Images: Targeted Privacy Attacks in the Web
标签：注册 解决 lazy http请求 开头 水平 用户组 总计 邮件
原文地址：https://www.cnblogs.com/kidling/p/13207406.html
