不一致性：HTTP头部及其对桌面/移动网站的影响

Phakong∗2470揭示HTTP头部不一致性及其对桌面/移动网站的影响0Abner Mendoza德克萨斯农工大学abmendoza@tamu.edu0德克萨斯农工大学cpx0rpc@tamu.edu0Guofei Gu德克萨斯农工大学guofei@cse.tamu.edu0摘要0移动优先经济的范式转变导致了移动优化网站的急剧增加，这些网站在许多情况下是从其桌面版本派生出来的。移动网站设计通常侧重于性能优化而不是安全性，并且可能由不同的开发团队开发。这导致了一些微妙但关键的安全保证在Web平台上的不一致性，例如针对常见Web攻击的保护机制。在这项工作中，我们首次进行了对排名前70,000个网站中移动和桌面HTTP安全响应配置之间的不一致性的系统测量研究。我们表明，同一网站的移动和桌面版本之间的HTTP安全配置不一致可能导致漏洞。我们的研究比较了一年间收集的数据快照，以获取关于移动与桌面不一致性在网站中的纵向趋势的见解。为了补充我们的测量研究，我们提出了一种威胁分析，探索了一些可能利用实际网站上发现的不一致性的攻击场景。我们系统地分析了网站的移动和桌面版本之间不一致实现的安全影响，并展示了它如何导致现实世界的利用。我们提供了几个流行网站的案例研究，以展示这些不一致性如何被利用来危及Web用户的安全和隐私。我们的结果显示，在我们的数据集中几乎没有改进，这凸显了即使是一些知名网站也受到微妙不一致性的普遍影响。0CCS概念0• 网络 → Web协议安全；0关键词0移动Web安全，HTTP头部，不一致性0ACM参考格式：Abner Mendoza，Phakpoom Chinprutthiwong和GuofeiGu。2018。揭示HTTP头部不一致性及其对桌面/移动网站的影响。在WWW2018：2018年Web会议上，2018年4月23日至27日，法国里昂。ACM，纽约，美国，10页。https://doi.org/10.1145/3178876.31860910� 共同第一作者0本文根据知识共享署名4.0国际（CC BY4.0）许可发布。作者保留在其个人和公司网站上传播作品的权利，并附上适当的归属。WWW 2018，2018年4月23日至27日，法国里昂©2018IW3C2（国际万维网会议委员会），根据知识共享CC BY 4.0许可发布。ACM ISBN978-1-4503-5639-8/18/04。https://doi.org/10.1145/3178876.318609101 引言0智能移动设备的普及和强大使得移动优化网站的数量激增，这些网站与现有的桌面优化网站相辅相成。当检测到移动客户端时，许多流行的Web应用程序会提供其网站的移动优化版本。移动网站通常以可用性和性能为重点，通常是其桌面版本的简化版本，其通常由不同的开发团队开发和维护。虽然移动设备变得越来越强大，但其资源（RAM，CPU，磁盘等）仍然有限，与桌面计算机和笔记本电脑相比。这增加了为移动设备提供优化的Web应用程序的需求，通常以缩减的用户界面和功能的形式提供。在移动空间中，服务器和客户端之间传输的每个字节都带有成本，无论是金钱还是设备上所需的资源[23]。因此，开发人员特别注意将从服务器发送的所有数据最小化，并找到每个机会从其Web应用程序中获得额外的性能。虽然许多先前的研究人员已经探索了Web平台上的问题，但没有人评估移动一致性对Web上的安全性和隐私的影响程度。在这项工作中，我们探索了桌面和移动网站之间HTTP安全头部微妙不一致性的普遍性和影响。为此，我们探索和比较了移动和桌面网站构件之间的不一致性，以确定它们是否可能导致安全漏洞。虽然许多在线服务可能有相应的本机移动应用程序，但最近的一项研究显示，许多用户仍然通过移动Web浏览器访问这些服务，尤其是在购物，参考，新闻和教育领域[11]。此外，许多本机应用程序只是围绕嵌入式Web浏览器组件的包装器，仅加载移动优化的网站。Web浏览器本身经过多年的发展，已成为一个真正的应用程序平台，现在必须支持几个相互不信任的主体之间的交互[28]，这些主体可能在Web应用程序中执行关键功能。通过这种演变，出现了几种旨在加强浏览器平台安全性的安全机制，以防范常见攻击[31]。其中大多数机制都是使用HTTP头部实现的，它们作为来自托管Web服务器的指令，指示客户端浏览器执行某些策略[9，16，17，31，32]。我们将这些头部称为安全头部。Web应用程序通常使用分层方法进行设计和部署，将数据，业务逻辑和用户界面组件分开。在追求无缝用户体验和最佳性能的过程中，Web开发人员使用不同的技术根据检测到的浏览器为用户提供内容。0主题：Web上的安全与隐私WWW 2018年4月23日至27日，法国里昂2480许多Web服务器和Web应用程序使用简单的浏览器指纹技术，通过检查HTTPUser-Agent标头或JavaScript的navigator.userAgent对象来推断用户的形式因素，并决定是提供移动优化还是完整桌面版本的网站。这些应用程序可以部署在多种场景中，其中移动和桌面版本共享一个或多个层。这提高了可扩展性，并方便地允许移动和桌面优化的Web应用程序共享相同的底层服务器资源。不幸的是，这种设计和部署灵活性可能导致关键工件（如会话cookie和HTTP安全标头）的不一致性。例如，假设托管www.example.com的服务器强制执行严格的HTTPS，但托管m.example.com的服务器允许不安全的HTTP连接。假设使用domain属性[28]设置的共享后端服务器基础设施和cookie，这种微小的不一致性可以使攻击者通过中间人场景迫使受害者访问m.example.com来检索由www.example.com保存的身份验证cookie。无论是向桌面浏览器还是移动设备提供网站，我们都假设共享某些内容和资源。这在虚拟主机环境中很常见，其中一个服务器用于托管Web应用程序，而浏览器指纹组件将请求路由到移动优化或桌面优化的虚拟主机上的同一个网站。共享的底层服务器的存在使得移动和桌面网站可以方便地共享共同的资源。例如，虽然许多移动用户被重定向到'm.'子域，但cookie是使用二级域（SLD）路径设置的。这允许应用程序状态在移动和桌面站点之间共享。这种做法会导致一些细微的不一致性，无论是由于虚拟主机配置的差异，还是由于在共享服务器上的每个虚拟主机之间不一致地应用性能优化。在这种情况下，我们将源定义为顶级域。例如，网站www.example.com和m.example.com被视为example.com。简而言之，我们的主要贡献如下：0（1）我们进行了第一次纵向、大规模、系统的测量研究，对桌面和移动Web浏览器请求的（前70,000个）Web服务器响应的安全头不一致性进行了分析。我们展示了这种安全不一致性在现实世界中是一个普遍存在的问题。（2）我们系统地分析了这些不一致性的安全影响，并展示了它们如何导致Web应用程序变得更加容易受到攻击，从而产生严重后果。我们展示了一些真实世界的顶级网站的例子，如netflix.com和disneystore.com。我们还与其中一些网站合作，帮助修复了这些不一致性。02 背景0网络基础设施继续受到攻击者的利用，对社会的各个方面产生广泛的影响。多年来，研究人员和行业都以同样的方式回应，通过开发浏览器机制来减轻流行的网站攻击，如跨站脚本、点击劫持等。浏览器0已成为主要的战场，许多最近的提案试图通过利用和扩展现有功能来加强浏览器。特别是，HTTP标头已成为实施防御机制的流行渠道[9,17,25,31]。通过在HTTP标头中使用声明性安全性，有效的网站安全防御机制已经出现，这些机制提供明确的安全参数，指示浏览器对常见的Web漏洞实施特定的安全功能。这需要浏览器和服务器之间的密切协调。0表1：分析的安全HTTP头列表0头部示例攻击减轻0设置Cookie会话劫持，Cookie窃取。0X-Frame-Options点击劫持0访问控制允许来源跨站点访问0X-XSS-Protection跨站点脚本0严格传输安全中间人攻击0X-Content-Type-Options MIME嗅探。0内容安全策略XSS，CSRF02.1 HTTP安全头部0两个通信方之间的每个HTTP请求和响应都包含一个或多个HTTP头[13]。这些头部是HTTP协议的重要组成部分，携带有关每个请求或响应的附加信息，由客户端或服务器用于处理请求或响应。HTTP头部采用键值对的格式，键表示头部的名称，值表示头部的特定配置。HTTP安全头部是响应的Web服务器发出的声明，指示客户端浏览器强制执行某些内置的安全机制，以减轻常见的Web攻击，如跨站点脚本过滤、防止跨站点请求伪造等[4]。表1列出了我们在这项工作中关注的特定HTTP安全头部的列表。HTTP头部可以作为网站向浏览器声明要强制执行的安全原则的有效且廉价的手段。然而，这些头部的存在并不能保证在客户端上强制执行。除了指定头部外，Web服务器还必须正确配置头部的值和参数，这些值和参数作为输入传递给浏览器，告诉它采取哪些行动来减轻特定的攻击向量。如果安全头部配置不正确或含糊不清，它们将没有效果或产生意想不到的后果[12]。例如，Web服务器必须发送头部“X-Frame-Options:DENY”来禁止将网站加载到iframe中。如果，例如，值被错误地指定为“Denied”，那么浏览器将无法理解该指令，网站可能会容易受到点击劫持攻击的威胁。02.1.1深度防御。以前的几项研究提出了基于HTTP头的防御措施，以减轻常见的Web攻击[5,9, 10, 14, 15, 18, 19, 22, 25, 28,31]。大多数主要浏览器上部署的防御措施都是深度防御策略，而不是完全预防Web攻击。它们并不能消除任何目标攻击，但可以增加攻击者利用它们的难度。我们仅关注我们在对前70,000个网站的分析中观察到的HTTP头部特定的防御措施。这些头部在表1中列出，我们在本文中统称为“安全头部”。我们展示了移动和桌面渲染实现之间的不一致性降低了这些安全头部防御措施的有效性。0Track: Security and Privacy on the Web WWW 2018，2018年4月23日至27日，法国里昂2490所针对的攻击，但使攻击者更难利用它们。我们仅关注我们在对前70,000个网站的分析中观察到的HTTP头部特定的防御措施。这些头部在表1中列出，我们在本文中统称为“安全头部”。我们展示了移动和桌面渲染实现之间的不一致性降低了这些安全头部防御措施的有效性。02.1.2 Cookies.虽然cookie本身就是HTTP头，但我们对待它们的方式不同，因为cookie除了用于安全策略执行之外，还有更多不同的用途。cookie被用作维护状态的机制，以弥补HTTP的无状态性质。cookie已经发展成为促进Web应用程序授权和身份验证的重要工具。此外，虽然cookie也是HTTP头（Set-Cookie），但它们与传统的HTTP头不同，因为浏览器必须为保存和操作存储的值在客户端分配存储空间。Set-Cookie也是请求或响应中可能出现多次的少数HTTP头之一。cookie也可以使用JavaScript设置，但我们在本文中重点讨论它作为HTTP头的用法。02.1.3重定向。在本文的范围内，我们关注的是由Web服务器执行的重定向，将通信通道从HTTP升级到HTTPS，通常是通过附带3xx返回状态码的Location头来完成的。此外，我们还考虑由于Strict-Transport-Security（HSTS）或其他服务器配置而进行的重定向，这些配置要求使用安全的连接通道。我们将这些统称为重定向指令。然而，与其他安全头不同，重定向指令头的目的不是主要为了安全，因此我们不在表1中列出它们。03 利用不一致0在本节中，我们首先介绍我们的威胁模型，讨论不一致配置对网站安全的影响，然后展示包含移动和桌面网站之间不一致的真实世界示例。03.1 威胁模型0我们的威胁模型假设攻击者可以充当用户并向远程服务器发出请求并检查响应。攻击者可以收集、比较和聚合Web请求和响应的工件，以了解如何构造攻击，利用找到的每个网站替代视图的弱点。我们还考虑一个能够检查和修改浏览器与服务器之间未加密的网络流量的主动网络攻击者。然而，除了自己的流量外，攻击者无法解密或修改HTTPS上的流量。03.2 不一致的情景0我们从四个广泛的角度探讨了不一致性的安全影响，我们认为这些是启用使用不一致性进行常见Web攻击的先决条件，例如中间人攻击、cookie窃取或重放等。这些不一致性会通过最小化攻击的努力（例如避免需要SSL剥离）或增加攻击的可能性来促进攻击。0攻击面（例如XSS保护头的配置错误）。1.存在不一致。在这种情况下，一个关键的安全头在一个用户代理中存在，但在另一个用户代理中缺失。攻击者可以利用这个知识，在选择的用户代理攻击中，通过将用户重定向到一个基于不存在的安全头的网站的替代视图来进行攻击。例如，攻击者可以强制将受害者重定向到一个不包含点击劫持保护的替代视图，然后将该视图嵌入到一个隐藏的iframe中，以执行类似于[7]中所示的攻击。如图2所示，攻击者可以充当MITM，重写请求的User-Agent头，以强制响应，其中已知缺少特定的安全头，而不是包含该头的响应。或者，攻击者可以使用社会工程攻击，使受害者通过一个较弱的渠道访问不一致的网站。2.配置不一致。在这种情况下，攻击者观察并比较两个用户代理之间的特定安全头的配置。例如，如果CSP在一个用户代理中配置为允许从源站点的子域中加载脚本（script-src），而在另一个用户代理中不允许，攻击者可以利用这种不一致来获取优势。考虑到域名在共享托管环境中使用的情况。然后，如果攻击者控制该共享托管环境中的一个子域，他可以在自己的子域中部署恶意主机，并将受害者用户重定向到不一致的受害者网站UI，然后在其中利用XSS、MITM或其他攻击从他控制的子域中注入代码，因为其不一致的CSP配置允许从子域加载脚本。尽管攻击者可能受到子域作为不同源的限制，但潜在的攻击并不是微不足道的。3.HTTPS重定向不一致。在这种情况下，攻击者利用一个响应，根据用户代理的不同，总是重定向到HTTPS，而另一个响应则不会重定向到HTTPS。如果攻击者可以强制用户访问一个站点，其中他的请求的用户代理设置为不会重定向到HTTPS的版本，那么攻击者可以保持连接未加密，并利用MITM攻击，如图2所示。我们发现，在某些情况下，一个响应配置了HSTS，而另一个响应没有HSTS。在这种情况下，连接的状态是不一致的，攻击者可以利用它。4.Cookie标志不一致。在另一种情况下，两个用户代理之间特定cookie的标志配置不一致，这使得攻击者能够窃取使用安全的HTTPS通道写入的仅限HTTP的cookie。在这个示例场景中，当由桌面用户代理发出请求后，一个cookie的Secure标志被设置为false。需要注意的是，在MITM攻击者的场景中，攻击者可以发起一个完整的SSLStrip攻击，而不仅仅是重写用户代理，将受害者引导到一个较弱的通信渠道。这些不一致不一定会导致新的漏洞或更强的攻击，但它们给攻击者提供了更多的选项，以基于不同的情景和实践环境发动攻击。0Track：2018年4月23日至27日，法国里昂的Web安全和隐私WWW 201825003.3现实世界的例子0在这里，我们讨论了一些真实世界的网站，我们发现它们在安全头部、HTTPS重定向指令和cookie方面存在不一致性。在所有这些案例研究中，重要的是要注意，我们所说明的不一定是新的攻击技术，而是通过利用可能促进有针对性攻击的不一致性来执行已知攻击的新方法。我们向相关网站报告了这些问题，并与其中一些网站密切合作，以了解和解决这些问题。在所有情况下，这些网站的不一致性问题都已经得到了修复。0图1：跨平台信息泄漏聚合攻击。03.3.1Disneystore.com。这个例子利用了cookie标志的不一致性，通过聚合来自两个渠道（即桌面和移动）的信息，发起了一个cookie重放攻击。据我们所知，以前的文献中还没有讨论过使用移动和桌面泄漏的信息来收集必要的cookie，否则这些cookie将无法通过单个用户代理披露。我们假设一个主动的网络攻击者控制着一个恶意的网络接入点，如恶意双胞胎攻击者[27]，但不一定使用SSL剥离。目标是窃取用户的cookie并发起cookie重放攻击。这种情况考虑了经典的咖啡店场景，受害者用户访问免费的WiFi连接。我们的分析框架（在下一节中讨论）报告了cookie的不一致性。用于J2EEWeb应用程序中的会话管理的cookie'JSESSIONID'，当移动用户代理浏览时，其Secure标志设置为false。此外，另一个cookie'access_token'，可以与JSESSIONID组合以复制用户的会话，在桌面用户代理浏览时，其Secure标志设置为false。这种情况在图1中有所说明。通过聚合从受害者的桌面泄漏的'access_token'cookie和从受害者的移动设备泄漏的'JSESSIONID'cookie，我们能够获取并重放这些cookie，以完全访问测试受害者账户。在真实的账户上，这将包含受害者的私人信息，如邮寄地址、电子邮件、手机号码、购买历史和部分信用卡号码。为了使这种情况可行，受害者用户必须在移动设备和桌面设备上都使用持久身份验证登录网站，这并不罕见。由于未设置Secure标志，这些cookie将通过不安全的通道发送，使它们暴露给中间人攻击者。这种情况是可行的，因为人们通常随身携带他们的移动设备。0并且从不同的位置使用他们的个人计算机。ComScore在2013年至2015年之间进行的一项调查显示，57%至84%的消费者经常在移动和桌面平台之间进行互换浏览。0图2：将客户端重定向到不太安全的用户界面03.3.2Bet365.com。这个例子利用了重定向不一致性和cookie标志不一致性，通过强制用户浏览较弱的通信渠道来进行攻击。攻击者可以通过改变初始HTTP连接上的用户代理字段（强制）或社会工程攻击（胁迫）将受害者引导到一个安全性较低的通道，基于攻击者所知道的不一致性。这种攻击结果类似于SSL剥离攻击，但比SSL剥离攻击更加隐蔽。目标是将用户重定向到满足攻击前提条件的视图，例如具有未加密通道或缺少XSS保护头的视图。在移动代理上，bet365.com的服务器将HTTP请求重定向到HTTPS，并设置一个名为'pstk'的会话cookie，其Secure标志设置为true。然而，在桌面代理上，bet365.com的服务器既不会将HTTP重定向到HTTPS，也不会将'pstk'的Secure标志设置为true。0图3：cookie标志不一致导致攻击0攻击者可以利用这个洞察力通过社会工程或替换初始HTTP连接上的用户代理来迫使受害者进入一个不安全的通道，然后完全访问他与bet365.com的网络通信，可能泄漏高度敏感的信息，包括财务信息。这种情况如图3所示。现在假设bet365.com无论用户代理设置如何都会将HTTP重定向到HTTPS。如果“pstk”cookie标志仍然不一致，仍然可以发生类似的攻击。在这种情况下，bet365.com的服务器将重定向用户到HTTPS通道，但不会将“pstk”Secure标志设置为true。用户通过初始HTTP请求的任何后续请求都会将“pstk”cookie暴露给中间人攻击者。后续请求可以是用户自愿发送的，也可以是强制性地使用CSRF或XSS等方式发送的。在0Track：2018年WWW上的安全与隐私，2018年4月23日至27日，法国里昂2@old_mobile_agent = " Mozilla / 5 . 0( Linux ;Android4 . 0 . 4 ;GalaxyNexusBuild / IMM76B )AppleWebKit / 5 3 5 . 1 9(KHTML,l i k eGecko )Chrome / 1 8 . 0 . 1 0 2 5 . 1 3 3MobileS a f a r i / 5 3 5 . 1 9 "3@new_pc_agent = " Mozilla / 5 . 0( X11 ;Linuxx86_64 )AppleWebKit/ 5 3 7 . 3 6(KHTML,l i k eGecko ) Chrome / 6 0 . 0 . 3 1 1 2 . 9 0S a f a r i/ 5 3 7 . 3 6 "4@new_mobile_agent = " Mozilla / 5 . 0( Linux ;Android8 . 0 ;Nexus 6PBuild / OPP3 . 1 7 0 5 1 8 . 0 0 6 )AppleWebKit / 5 3 7 . 3 6(KHTML,l i k eGecko ) Chrome / 5 8 . 0 . 3 0 2 9 . 1 2 1MobileS a f a r i / 5 3 7 . 3 6 "We further annotated the site list to include the site categoriesas defined by Fortinet [3], a web filtering service. The categoriesallows us to perform further analysis on our results based on trendsaccording to category grouping.We collected one snapshot in 2016, and one snapshot in 2017. Oneach occasion, we collected two separate data sets, correspondingto site responses to mobile browsers and site responses to desktopbrowsers.2510在相同的场景下，攻击者可以部署一个恶意的WiFi接入点，并在一个“接受条款和条件”的按钮上放置一个不可见的iframe，将受害者重定向到bet365.com的HTTP页面，从而导致他的会话cookie泄漏。03.3.3Netflix.com。这种攻击利用了cookie标志不一致性，并假设网站上存在XSS漏洞。该网站包含一个敏感的cookie，SecureNetflixID，用于维护用户会话。该cookie在桌面用户代理上将其HTTPOnly标志设置为true，但在移动用户代理上将其设置为false。在某些情况下，还会发送第二个cookie，NetflixID，其中“HttpOnly”和“Secure”标志都设置为false。因此，这些敏感的cookie对于在网站上运行的任何脚本都是可见的。因此，这些cookie可能会暴露给利用网站上任何XSS漏洞的恶意脚本。我们将这个潜在的数据暴露漏洞作为Netflix负责任的披露计划的一部分向Netflix报告。他们迅速回应，并与他们合作了几个星期，他们的团队分析了这个问题。他们确定在移动网站上部署的cookie配置中的不一致性构成了一个漏洞。他们已经在所有的生产服务器上修复了这个问题。他们还向我们表示，他们的Web应用程序根据所使用的平台或客户端使用不同的API端点。这符合我们的观点，即Web应用程序使用共享资源根据需求符合移动和其他形式因素。04 数据收集与分析0为了了解安全头部不一致性在现实世界中的普遍性和趋势，我们在两个不同的时间段（2016年至2017年）进行了一项大规模的测量研究，使用了Alexa[1]根据2016年排名的前70000个网站。在这里，我们描述了我们的数据收集框架和分析方法。04.1 数据收集0我们开发了一个自定义的网络爬虫，自动访问每个网站并保存响应的完整内容以供离线分析。我们的爬虫模拟了一个桌面浏览器，使用如清单1所示的用户代理字符串。这些字符串是根据NetMarketShare.com测量的当前浏览器流行趋势选择的。它们代表了桌面网站的GoogleChrome浏览器和移动网站的Chrome移动浏览器。此外，我们使用了两组不同的用户代理字符串（在清单1中标记为“old”和“new”），以比较用户代理字符串本身是否对服务器响应与安全头部不一致性有影响。此外，我们的爬虫会跟随所有重定向，包括那些到安全的HTTPS网站的重定向，并仅收集最终着陆页面的数据。0Listing 1: 浏览器用户代理字符串0我们进一步注释了站点列表，包括Fortinet[3]定义的站点类别，这是一个网络过滤服务。这些类别使我们能够根据类别分组的趋势对我们的结果进行进一步分析。我们在2016年和2017年各收集了一个快照。每次，我们收集了两个独立的数据集，对应于对移动浏览器和桌面浏览器的站点响应。04.1.1数据集。为了比较不一致性的纵向趋势以及用户代理字符串的浏览器和平台版本的影响，我们将数据进一步分为三个数据集。旧数据集：这个数据集代表2016年期间使用Listing1中的old_pc_agent和old_mobile_agent爬取的HTTP响应数据。新数据集：这个数据集代表2017年期间使用Listing1中的old_pc_agent和old_mobile_agent爬取的HTTP响应数据。新+数据集：这个数据集代表2017年期间使用Listing1中的new_pc_agent和new_mobile_agent爬取的HTTP响应数据。通过比较旧数据集和新数据集，我们分析不一致性情况是否随时间改善。新数据集和新+数据集之间的比较将表明平台和浏览器版本对HTTP头部响应的影响程度。04.2 分析方法0我们从“存在”和“配置”两个广泛的角度分析了移动和桌面用户代理上的安全头部遗留物。首先，我们比较了移动和Web之间每个安全头部的存在情况，以确定用户代理之间的存在不一致。类似地，我们比较了用户代理之间相同安全头部的配置情况，以揭示不一致性。我们发现了一些配置存在缺陷或与其他设置冲突的情况，这可能会削弱浏览器中HTTP头部防御所提供的保护。我们还分析了HTTP到HTTPS重定向的不一致性。最后，我们还注意到了“安全”和“HttpOnly”cookie标志的微妙但重要的不一致性。为了进行系统分析，我们建立了以下准则，用于分析同一来源的网站的移动和桌面版本之间的不一致性。0（1）如果一个安全头部对于一个用户代理存在，则对于所有用户代理都必须存在。（2）每个安全头部必须以相同的有效配置设置一致地传递，不论用户代理如何。（3）如果移动和桌面之间共享cookie，则必须以相同的设置一致地传递，不论用户代理如何。0跟踪：2018年4月23日至27日，法国里昂举办的Web安全与隐私WWW 2018会议2520（4）如果一个网站重定向到HTTPS，则必须对所有用户代理都这样做。（5）不同遗留物内部和之间的存在和配置设置不应导致冲突的策略。例如，网站上的CSP不应允许和拒绝相同的域名[12]。04.2.1揭示不一致性。使用一组前70,000个网站，我们使用模拟的桌面和移动浏览器收集数据。对于同一顶级域名的着陆页的每一对响应，我们检查是否违反了我们规定的准则以揭示不一致性。对于每个网站的每一对响应（移动 vs.桌面），我们使用我们的方法指南来找到违反我们关于安全头部应如何传递的断言的实例。存在不一致性。最简单的衡量不一致性的方法是在两个用户代理之间检查同一网站的头部是否存在。尽管这些细微的不一致性是微不足道的，但它们可能成为对网站进行严重攻击的入口。例如，如果桌面代理中存在X-Frame-Options头部，但移动代理中缺少该头部，那么移动版本就可以在点击劫持攻击中使用。为了衡量这些不一致性，我们仅仅分析每个网站的每一对响应，并对于每个安全头部，我们记录当头部在一个响应中存在而在另一个响应中缺失时的情况。配置不一致性。为了评估每个安全头部的配置，我们采用了“强”和“弱”配置的概念。这些概念基于表2中定义的一组启发式方法。这种方法受到了[33]中使用的方法的启发。我们分析了每个头部可用的配置选项，并分析了每个观察到的头部是否以无效的设置部署。例如，如果X-XSS-Protection头部设置为除了“1”之外的任何值，那么对于该网站来说它是无效的，我们将该配置分类为“弱”。另一方面，如果它配置为值“1”，那么我们将该设置分类为“强”。请注意，大多数流行的浏览器（例如Chrome）倾向于默认安全地设置缺失的安全头部。例如，X-XSS-Protection被设置为1，并且没有明确域的set-cookie头部将被设置为当前域。因此，不一致地设置安全头部可能比不设置它们更糟糕。为了分析内容安全策略配置的有效性，我们还采用了[33]中使用的方法。因此，我们的评估基于CSP的主要目标，即通过脚本和对象标签来防御内容注入。HTTPS重定向不一致性。我们通过我们的爬虫框架测量重定向不一致性，通过使用HTTP发起所有连接，并确保跟随所有重定向，并标记每个连接，其中最终响应使用了HTTPS连接。许多Web攻击，包括中间人攻击，可以通过用户代理使用安全连接来减轻。目前推荐的减轻HTTPS降级攻击的方法是使用HSTS [17]。然而，只有少数网站部署了HSTS[20]。网站还可以使用诸如JavaScript的document.location函数或HTMLMeta标签来启用重定向。现实情况是，许多网站不使用HTTPS，很少升级到HTTPS，即使在存在HTTPS重定向的情况下，我们发现同一网站在不同用户代理中对严格重定向的实现存在许多不一致性。这种不一致性可以被网络攻击者利用，通过强制用户始终使用不安全的连接，从而方便地发起中间人攻击。Cookie标志不一致性。对于在两个响应中存在相同名称的cookie，我们假设该cookie在移动和桌面用户代理之间共享。然后，我们比较为这些cookie设置的“安全”和“HTTPOnly”标志，以找到标志设置不一致的情况。我们检查每个标志在一个用户代理实例中为true而在另一个用户代理实例中为false的违规情况。0对于在两个响应中存在相同名称的cookie，我们假设该cookie在移动和桌面用户代理之间共享。然后，我们比较为这些cookie设置的“安全”和“HTTPOnly”标志，以找到标志设置不一致的情况。我们检查每个标志在一个用户代理实例中为true而在另一个用户代理实例中为false的违规情况。05测量不一致性0根据第4.2节中提出的指导原则，我们评估了前70,000个网站。表3显示了我们的实证评估结果，我们在移动和桌面用户代理之间测量和评估了不一致性。在每个单元格中，我们报告了在第4.1.1节中讨论的三个数据集中的不同结果（例如，旧/新/新+）。对于每个相关的安全头部，我们根据存在和配置的角度显示了不一致性问题的普遍性。总体而言，超过2,000个网站响应了我们的爬虫，显示了一个或多个安全头部在一个或多个不一致性方面违反了我们的分析原则。不一致性问题在前70,000个网站的整个范围内都存在，甚至像Netflix和Google这样的高排名和热门的网络服务提供商也存在不一致性。0图4：桌面和移动网站之间具有不一致的HTTP安全头部的百分比0总体存在不一致性结果。表3中的桌面列显示了仅在使用桌面用户代理时存在该安全头部的网站数量。类似地，移动列显示了仅在使用移动用户代理时存在该安全头部的网站数量。桌面和移动列的总和表示该安全头部被不一致地传递的总实例数。图4比较了我们的新+数据集中每个相关头部的存在不一致性的百分比。我们比较了桌面和移动用户代理之间的百分比0跟踪：2018年Web上的安全与隐私WWW 2018年4月23日至27日，法国里昂2530表2：评估安全头部配置的启发式方法。0头部规则0X-XSS-Protection（XSS）设置为1，附加参数是可选的0X-Frame-Options（Xframe）在allow-from中不使用通配符（*）0X-Content-Type-Options（Xcontent）设置为nosniff0访问控制允许来源（CORS）不使用通配符（*）0Strict-Transport-Security（HSTS）的max-age大于999，附加参数是可选的0内容安全策略（CSP）0script-src和object-src必须同时存在或者在它们的缺失情况下使用default-src。在script-src、object-src或default-src白名单中不使用通配符（*）。在白名单中不包含不安全的来源[16]。0表3：前70,000个网站的安全头部不一致性分析（旧/新/新+）0存在强配置0头部桌面移动一致的桌面移动一致的0X-XSS-Protection（XSS）77/103/91 84/113/100 4,322/6,721/6,717 67/94/82 85/115/100 4,208/6,542/6,5410X-Frame-Options（Xframe）270/285/268 183/185/161 8,600/12,068/12,089 266/279/264 176/179/154 8,425/11,848/11,8690X-Content-Type-Options（Xcontent）107/132/118 98/99/87 5,462/8,356/8,346 106/132/118 99/99/87 5,444/8,334/8,3240访问控制允许来源（CORS）183/175/163 133/151/138 3,053/3,694/3,726 63/54/51 33/43/47 538/668/6710Strict-Transport-Security（HSTS）70/99/75 55/86/85 2,957/6,268/6,275 60/93/67 50/77/76 2,566/5,383/5,3920内容安全策略（CSP）53/96/58 18/20/27 726/1,618/1,654 0/0/0 0/0/0 2/3/30移动和桌面用户代理之间的百分比。桌面百分比表示使用桌面用户代理时存在安全头部的网站数量，但在移动用户代理上被排除。类似地，移动百分比表示移动用户代理上包含的在同一网站上桌面上被排除的头部的百分比。0图5：桌面和移动网站之间具有不一致强配置的HTTP安全头的百分比0总体配置不一致结果。图5还显示了我们根据第4.2.1节中提出的强和弱配置概念对每个安全头的配置进行评估的结果。对于每个头部，桌面百分比指定了该安全头在桌面用户代理中配置为强的网站部分，而在移动用户代理中配置为弱的网站部分。类似地，移动百分比指定了该安全头仅在移动用户代理中配置为“强”，而在桌面用户代理中不配置的网站部分。这也在表3中显示，同时还显示了一致列，该列还指示了网站的数量0安全头的配置在两个用户代理的响应中始终被配置为强。Weichselbaum等人[33]发现99.34%的CSP主机使用的策略对抗XSS没有任何好处。事实上，在两个快照中，只有两个网站（hackerone.com和github.com）在移动设备和桌面设备之间始终具有强大的CSP配置。我们还必须注意，我们不包括在两个用户代理中标记为“弱”或没有任何安全头的网站，因为这些网站可能根本不知道HTTP安全头。0图6：桌面和移动网站中前8个网站类别的HTTPS重定向不一致性百分比0通过将存在与强弱标注进行比较，我们可以看到一个显著的观察结果，即Access-Control-Allow-Origin（CORS）头在存在和强数字之间存在最大差距，如表3所示。虽然CORS头在桌面和移动设备上分别不一致地存在于163个和138个网站中0跟踪：Web上的安全与隐私WWW 2018年4月23日至27日，法国里昂254