相对路径覆盖的大规模样式注入分析

that script injection is not a necessary precondition for effectiveattacks. By injecting Cascading Style Sheet (CSS) directives, forinstance, attackers can carry out so-called scriptless attacks [14]and exfiltrate secrets from a site.The aforementioned injection attacks typically arise due to thelack of separation between code and data [11], and more specifically,insufficient sanitization of untrusted inputs in web applications.While script injection attacks are more powerful than those basedon style injection, they are also more well-known as a threat, andweb developers are comparatively more likely to take steps to makethem more difficult. From an attacker’s point of view, style injectionattacks may be an option in scenarios where script injection is notpossible.There are many existing techniques of how style directives couldbe injected into a site [14, 18]. A relatively recent class of attacksis Relative Path Overwrite (RPO), first proposed in a blog postby Gareth Heyes [17] in 2014. These attacks exploit the semanticdisconnect between web browsers and web servers in interpretingrelative paths (path confusion). More concretely, in certain settingsan attacker can manipulate a page’s URL in such a way that theweb server still returns the same content as for the benign URL.However, using the manipulated URL as the base, the web browserincorrectly expands relative paths of included resources, which canlead to resources being loaded despite not being intended to beincluded by the developer. Depending on the implementation ofthe site, different variations of RPO attacks may be feasible. Forexample, an attacker could manipulate the URL to make the pageinclude user-generated content hosted on the same domain [48].When an injection vulnerability is present in a page, an attackercould manipulate the URL such that the web page references itselfas the stylesheet, which turns a simple text injection vulnerabilityinto a style sink [17]. Among these attack instantiations, the lattervariant has preconditions that are comparatively frequently met bysites. Our work focuses on this variant of RPO.To date, little is known about how widespread RPO vulnerabili-ties are on the Web. Especially since the attack is more recent andless well-known than traditional XSS, we believe it is importantto characterize the extent of the threat and quantify its enablingfactors. In this paper, we present the first in-depth study of styleinjection vulnerability using RPO. We extract pages using relative-path stylesheets from the Common Crawl dataset [9], automaticallytest if style directives can be injected using RPO, and determinewhether they are interpreted by the browser. Out of 31 millionpages from 222 thousand Alexa Top 1 M sites [3] in the Common2370相对路径覆盖的大规模样式注入分析0Sajjad Arshad 东北大学arshad@ccs.neu.edu0Seyed Ali Mirheidari特伦托大学seyedali.mirheidari@unitn.it0Tobias Lauinger 东北大学p672@tobias.lauinger.name0Bruno Crispo特伦托大学bruno.crispo@unitn.it0Engin Kirda 东北大学ek@ccs.neu.edu0William Robertson东北大学wkr@ccs.neu.edu0摘要0相对路径覆盖（RPO）是一种最近的技术，即使没有样式接收器或标记注入漏洞，也可以将样式指令注入到网站中。它利用浏览器和Web服务器解释相对路径（即路径混淆）的差异，使HTML页面将自身引用为样式表；简单的文本注入漏洞以及浏览器在解析CSS资源时的宽容性导致攻击者能够注入将由浏览器解释的样式指令。尽管样式注入可能看起来比脚本注入威胁小，但已经证明它可以实现一系列攻击，包括秘密泄露。在本文中，我们首次对Web进行了大规模研究，以测量使用RPO的样式注入的普遍性和重要性。我们的研究表明，Alexa前10000名网站中约有9％的网站至少包含一个易受攻击的页面，其中超过三分之一可以被利用。我们详细分析了成功利用的各种障碍，并提出了改进建议。与脚本注入相比，存在相对简单的对策来减轻样式注入。然而，根据我们发现的一系列流行内容管理系统（CMS），似乎对这种攻击向量的认识很少。0关键词0相对路径覆盖；无脚本攻击；样式注入0ACM参考格式：Sajjad Arshad，Seyed Ali Mirheidari，TobiasLauinger，Bruno Crispo，Engin Kirda和WilliamRobertson。2018年。相对路径覆盖的大规模样式注入分析。在WWW2018：2018年网络会议上，2018年4月23日至27日，法国里昂。ACM，美国纽约，纽约，10页。https://doi.org/10.1145/3178876.318609001 引言0本文发表在知识共享署名4.0国际许可证（CC BY4.0）下。作者保留在个人和公司网站上传播作品的权利，并附上适当的归属。WWW2018，2018年4月23日至27日，法国里昂，© 2018IW3C2（国际万维网会议委员会），根据知识共享CC BY 4.0许可证发布。ACM ISBN978-1-4503-5639-8/18/04。https://doi.org/10.1145/3178876.31860900跟踪：Web上的安全与隐私WWW 2018年4月23日至27日，法国里昂2380使用相对路径样式表进行爬行，我们发现377k个页面（12k个站点）存在漏洞；在Chrome中，1k个站点上的11k个页面可以被利用，而在InternetExplorer中，超过3k个站点上的近55k个页面可以被利用。我们分析了许多阻止漏洞被利用的因素，并讨论了如何利用这些因素来减轻这些漏洞。本文的贡献总结如下：0•我们首次对野外环境中相对路径覆盖漏洞的普遍性和重要性进行了自动化和大规模的研究。 •我们讨论了多种因素，阻止漏洞被利用，并发现存在简单的对策来减轻相对路径覆盖漏洞。 •我们将许多可利用的页面与内容管理系统（CMS）的安装相关联，并通知了供应商。02 背景和相关工作0相对路径覆盖（Relative PathOverwrite，RPO）的一般威胁模型类似于跨站脚本攻击（XSS）。通常，攻击者的目标是从第三方网站窃取敏感信息或在该网站上进行未经授权的交易，例如获取机密的财务信息或从受害者账户中转移资金。攻击者通过受权用户作为受害者间接对网站进行攻击。攻击者可以诱使受害者点击一个精心制作的链接，例如当受害者访问攻击者控制的域名时，页面会自动打开被操纵的链接，或者通过搜索引擎操纵、欺骗性缩短链接或社交工程手段。02.1 跨站脚本攻击0许多网站存在漏洞，允许攻击者注入恶意脚本。动态网站经常接受可以被攻击者控制的外部输入，例如URL、Cookie或表单中的数据。虽然网站开发人员的目标是将输入渲染为文本，但缺乏适当的净化可能导致输入被执行为脚本[40]。未经净化的输入可能发生在服务器端或客户端，并以持久存储或反射性的方式出现[37]。对于受害者的Web浏览器来说，代码看起来是来自第一方网站，因此它可以完全访问受害者浏览器中的会话数据。因此，攻击者绕过了同源策略的保护。02.2 无脚本攻击0跨站脚本攻击（Cross-SiteScripting，XSS）可能是最为人熟知的基于Web的攻击之一，许多网站通过过滤用户输入来防御此类攻击。客户端安全机制，如基于浏览器的XSS过滤器[5]和内容安全策略[45,50]，也使攻击者更难利用注入漏洞进行XSS攻击。这导致攻击者（和研究人员）开始研究潜在的替代方案，如无脚本攻击。这些攻击允许嗅探用户的浏览历史[19,29]，窃取任意内容[23]，读取HTML属性[16,24]，并绕过点击劫持防御[16]。接下来，我们将重点介绍两种无脚本攻击的类型。0文献中提出的攻击。两者都假设攻击者无法向网站注入或执行脚本。相反，攻击者滥用与层叠样式表（CSS）相关的特性。Heiderich等人[14]考虑了攻击者可以将CSS注入到第三方页面上下文中的情况，以便在显示页面时受害者的浏览器解释样式指令。也就是说，注入点要么位于样式上下文中，要么攻击者可以注入标记来创建包围恶意CSS指令的样式上下文。虽然CSS标准旨在用于样式和布局，例如定义大小、颜色或背景图像，因此不包含任何传统的脚本功能，但它提供了一些上下文敏感的特性，这些特性结合起来可以被滥用以提取和窃取数据。如果要提取的秘密不可见，例如在隐藏的表单字段或链接URL中的令牌，攻击者可以使用CSS属性访问器和内容属性来提取秘密并将其显示为文本，以便可以应用样式指令。自定义的攻击者提供的字体可以根据其值更改秘密文本的大小。动画特性可以用于循环使用多种字体以测试不同的组合。媒体查询或滚动条的出现可以用于实现条件样式，并通过从攻击者的服务器为每个条件加载不同的URL来进行数据泄漏。综上所述，Heiderich等人证明了这些技术使攻击者能够窃取信用卡号码或CSRF令牌[39]而无需执行脚本。Huang等人[18]则不同，他们展示了如何滥用CSS的语法宽松解析来使浏览器将HTML页面解释为“样式表”。该攻击假设页面中包含两个注入点，一个位于秘密在源代码中的位置之前，一个位于之后。攻击者注入两个CSS片段，例如{}*{background:url(’//attacker.com/?和’);}，当解释指令时，这些片段使秘密成为将从攻击者服务器加载的URL的一部分。假设攻击者无法注入标记，因此在传统浏览器中打开网站时，注入的指令不会被解释为样式。然而，CSS标准要求浏览器在解析CSS时非常宽容，跳过它们不理解的部分[49]。实际上，这意味着攻击者可以设置一个将易受攻击的第三方网站作为样式表加载的站点。当受害者在登录状态下访问攻击者的站点时，受害者的浏览器加载第三方网站并解释样式指令，导致秘密被发送给攻击者。为了防止这种攻击，现代浏览器在非CSS内容类型和语法错误的文档来自与包含页面不同域的情况下不加载为样式表。然而，当包含页面和被包含页面都从同一域加载时，基于宽容的CSS解析的攻击仍然可行。相对路径覆盖攻击可以滥用这种情况[55]。02.3 相对路径覆盖0跟踪：Web上的安全与隐私WWW 2018年4月23日至27日，法国里昂example, assume that a web browser has loaded an HTML documentfrom http://example.com/rpo/test.php which references a remotestylesheet with the relative path dist/styles.css. Web browsers treatURLs as file system-like paths, that is, test.php would be assumedto be a file within the parent directory rpo/, which would be usedas the starting point for relative paths, resulting in the absoluteURL http://example.com/rpo/dist/styles.css.However, the browser’s interpretation of the URL may be verydifferent from how the web server resolves the URL to determinewhich resource should be returned to the browser. The URL maynot correspond to an actual server-side file system structure atall, or the web server may internally rewrite parts of the URL. Forinstance, when a web server receives a request for http://example.com/rpo/test.php/ with an added trailing slash, it may still returnthe same HTML document corresponding to the test.php resource.Yet, to the browser this URL would appear to designate a directory(without a file name component), thus the browser would requestthe stylesheet from http://example.com/rpo/test.php/dist/styles.css.Depending on the server configuration, this may either result inan error since no such file exists, or the server may interpret dist/styles.css as a parameter to the script test.php and return the HTMLdocument. In the latter case, the HTML document includes itself asa stylesheet. Provided that the document contains a (text) injectionvulnerability, attackers can carry out the scriptless attacks; since thestylesheet inclusion is same-origin, the document load is permitted.The first account of RPO is attributed to a blog post by GarethHeyes [17], introducing self-referencing a PHP script with server-side URL rewriting. Furthermore, the post notes that certain ver-sions of Internet Explorer allow JavaScript execution from within aCSS context in the Compatibility View mode [34], escalating styleinjection to XSS [54]. Another blog post by Dalili [10] extends thetechnique to IIS and ASP.Net applications, and shows how URL-encoded slashes are decoded by the server but not the browser,allowing not only self-reference but also the inclusion of differ-ent resources. Kettle [22] coins the term Path Relative StyleSheetImport (PRSSI) for a specific subset of RPO attacks, introduces aPRSSI vulnerability scanner for Burp Suite [7], and proposes coun-termeasures. Terada [48] provides more exploitation techniques forvarious browsers or certain web applications, and [55] discusses anexample chaining several vulnerabilities to result in a combinationof RPO and a double style injection attack. Gil shows how attackerscan deceive web cache servers by using RPO [12, 13]. Some of theattacks discussed in the various blog posts are custom-tailored tospecific sites or applications, whereas others are more generic andapply to certain web server configurations or frameworks.23902.4 RPO风格攻击的前提条件0为了本文的目的，我们专注于一种通用类型的RPO攻击，因为它的前提条件不太具体，可能适用于更多的站点。更正式地说，如果页面满足以下条件，则定义为易受攻击：0• 页面包含至少一个使用相对路径的样式表。•服务器设置为即使通过附加字符来操纵URL，也会提供相同的页面，这些字符被浏览器解释为路径分隔符。0•页面反映了注入到URL或cookie中的样式指令。请注意，反射可以发生在页面的任意位置，不需要标记或脚本注入。•页面在相对路径之前不包含 HTML标签，该标签可以让浏览器知道如何正确扩展它们。0这种攻击是通过将自身作为样式表引用的页面进行样式注入（PRSSI）。由于“样式表”自引用实际上是一个HTML文档，Web服务器通常会以text/html的内容类型返回它。符合标准的模式下的浏览器不会尝试解析内容类型为CSS以外的文档，即使它被引用为样式表，导致攻击失败。然而，Web浏览器还支持怪异模式，以与非标准兼容的站点保持向后兼容性[44]；在这种模式下，浏览器忽略内容类型，仅根据包含上下文解析文档。我们将易受攻击的页面定义为可利用的，如果浏览器解释了注入的样式，即攻击者可以强制浏览器在怪异模式下渲染页面。这可以通过两种方式实现：0•易受攻击的HTML页面指定了一个文档类型，导致浏览器使用怪异模式而不是标准模式。文档类型指示页面使用的HTML版本和方言；第4.3.1节详细介绍了我们在研究中遇到的主要Web浏览器如何解释文档类型。•即使页面指定了通常会导致使用标准模式的文档类型，InternetExplorer中通常也可以强制使用怪异模式[22]。框架文档继承父文档的解析模式，因此攻击者可以创建一个具有较旧文档类型的攻击页面，并将易受攻击的页面加载到框架中。然而，这个技巧只适用于InternetExplorer，并且如果易受攻击的页面使用任何防框架技术，或者如果它为X-UA-CompatibleHTTP头（或等效头）指定了显式值，则可能失败。0我们在第3节中的测量方法测试了这些前提在野外的频率，以量化页面在RPO攻击方面的漏洞和可利用性。02.5 相关工作0在前面的章节中，我们调查了科学文献中的一些基于样式的攻击，以及几篇讨论RPO特殊情况的博客文章。我们不知道有关RPO的任何学术研究，也没有关于Web上RPO漏洞普遍存在的任何研究。据我们所知，Burp Suite[7]是第一个也是唯一一个能够基于RPO检测PRSSI漏洞的工具。然而，与我们的工作相比，它不能确定漏洞是否可以被利用。此外，我们是第一个全面调查野外RPO样式漏洞和可利用性有多广泛的研究者。0Track: Security and Privacy on the Web WWW 2018, April 23-27, 2018, Lyon, France2400对基于脚本的攻击进行了广泛研究，例如对XSS消毒框架的系统分析[53]，检测富互联网应用程序中的XSS漏洞[2]，大规模检测基于DOM的XSS[27，30]，以及通过脚本小工具绕过XSS缓解措施[25，26]。提出了一系列XSS预防机制，例如XSS Filter [41]，XSS-Guard[6]，SOMA [36]，BluePrint [31]，Document Structure Integrity[35]，XSS Auditor [5]，NoScript [32]，Context-SensitiveAuto-Sanitization (CSAS)[43]，基于运行时污点跟踪的基于DOM的XSS过滤[46]，通过软件设计防止脚本注入[20]，Strict CSP [52]和DOMPurify[15]。然而，这些关于脚本注入的漏洞测量和提出的对策不适用于基于RPO的样式注入。03 方法论0我们的方法包括三个主要阶段。我们使用CommonCrawl存档中的页面来种子我们的系统，以提取包含至少一个使用相对路径的样式表的候选页面。为了确定这些候选页面是否容易受到攻击，我们尝试通过请求每个页面URL的变体来注入样式指令，以引起路径混淆，并测试生成的响应是否反映了注入的样式指令。最后，我们通过检查反映的样式指令是否被解析并用于在Web浏览器中渲染来测试易受攻击的页面能够被利用的频率。03.1 候选页面识别0为了找到具有相对路径样式表的初始种子候选页面集，我们利用了2016年8月的CommonCrawl，其中包含超过16亿个页面。通过使用现有数据集，我们可以快速识别候选页面，而无需创建任何网络爬行流量。我们使用JavaHTML解析器过滤掉只包含内联CSS或由绝对URL引用的样式表的页面，剩下近6,000,000个站点上的超过2.03亿个页面。出于可扩展性的考虑，我们通过两个步骤进一步减少候选页面集的数量：0（1）我们仅保留Alexa百万大全排名中列出的站点的页面，将候选页面数量减少到223,000个站点上的141,000,000个页面。通过这样做，我们的结果会偏向受欢迎的站点，即那些由于访问者数量较多而可能受到更大影响的站点。（2）我们观察到许多站点使用通过查询字符串或路径参数定制的模板。我们预期这些模板会导致其实例化的相似漏洞和可利用性行为，因此我们可以通过使用相同模板的URL进行分组，并仅测试每个组的一个随机代表性来加快检测速度。为了对页面进行分组，我们将查询参数的所有值替换为常量，并将路径中的任何数字标识符替换为常量。我们将具有相同抽象URL以及CommonCrawl数据集中相同文档类型的页面进行分组。例如，我们将example.com/?lang=en和example.com/?lang=fr分组。0由于我们的方法包含一步主动测试漏洞是否可利用，我们从候选集中删除托管在.gov，.mil，.army，.navy和.airforce域名下的所有页面。最终的候选集包括222,000个站点上的137,000,000个页面（31,000,000个页面组）。03.2 漏洞分析0为了确定候选页面是否存在漏洞，我们使用基于PythonRequests模块的轻量级爬虫。在高层次上，爬虫模拟浏览器如何扩展相对路径，并测试是否可以通过路径混淆将样式指令注入到加载为样式表的资源中。对于候选集中的每个页面组，爬虫随机选择一个代表性URL，并根据下面解释的多种技术对其进行变异。这些技术的每一种都旨在引起路径混淆，并使用包含长唯一随机字符串的样式指令来污染页面输入。爬虫从服务器请求变异后的URL并解析响应文档，忽略在框架中加载的资源。如果响应包含标签，则爬虫认为页面不易受攻击，因为如果正确使用，标签可以避免路径混淆。否则，爬虫从响应中提取所有相对样式表路径，并使用主页面的变异URL作为基准进行扩展，模拟浏览器处理相对路径的方式（参见第2.3节）。然后，爬虫请求每个唯一的样式表URL，直到找到一个反映响应中注入样式的样式表。我们注入用于测试反射漏洞的样式指令在图1的图例中显示。有效载荷以编码的换行符开头，因为我们观察到换行符的存在会增加注入成功的概率。我们最初使用%0A作为换行符，但在注入不成功的情况下也测试%0C和%0D。有效载荷的其余部分模拟了简单CSS指令的语法，主要由用于在服务器响应的正文中定位有效载荷的随机生成字符串组成。如果爬虫找到注入的唯一字符串的匹配，它认为页面易受攻击。接下来，我们描述了我们用于注入样式指令的各种URL变异技术。所有技术还使用RPO，以便浏览器加载与原始样式表文件不同的资源，这些资源更有可能包含注入漏洞。从概念上讲，我们使用的RPO方法假设服务器内部解析经过精心设计的URL与“干净”URL相同的脚本，如第2.3节所述。也就是说，当在Web浏览器中加载时，由于RPO引起的路径混淆会导致页面将自身引用为样式表。然而，这种假设只是概念性的，对于攻击成功并不是必需的。对于不会内部重写URL的服务器，我们的变异URL可能会导致错误响应，因为这些URL与这些服务器上实际文件的位置不对应。错误响应通常是HTML文档，可能包含注入漏洞，例如当它们显示无法找到的文件的URL时。因此，服务器生成的错误响应可以像常规页面一样用于攻击。0Track: Security and Privacy on the Web WWW 2018, April 23-27, 2018, Lyon, France2410/page.asp /page.asp / PAYLOAD  ///page.asp / PAYLOAD / style.css0（a）路径参数（简单）0/page.php/param1/param2 /page.php/ PAYLOAD  param1/PAYLOAD  param2  // /page.php/ PAYLOAD  param1/ PAYLOADparam2 / style.css0（b）路径参数（PHP或ASP）0/page.jsp;param1;param2 /page.jsp; PAYLOAD  param1; PAYLOADparam2  // /page.jsp; PAYLOAD  param1; PAYLOAD  param2 /style.css0（c）路径参数（JSP）0/dir/page.aspx / PAYLOAD  /..%2F dir/ PAYLOAD  /..%2F page.aspx // /PAYLOAD  /..%2F dir/ PAYLOAD  /..%2F page.aspx / style.css0（d）编码路径0/page.html?k1=v1&k2=v2 /page.html %3F k1= PAYLOAD  v1&k2=PAYLOAD  v2 // /page.html %3F k1= PAYLOAD  v1&k2= PAYLOADv2 / style.css0（e）编码查询0/page.php?key=value/page.php // ?key=value/page.php / style.css0原始Cookie：k1=v1; k2=v2 制作的Cookie：k1= PAYLOAD  v1;k2= PAYLOAD  v20（f）Cookie0图1：路径混淆和样式注入的各种技术。在每个示例中，第一个URL对应于常规页面，第二个URL对应于攻击者制作的页面URL。假设每个HTML页面都引用了一个位于../style.css的样式表，从而导致浏览器展开样式表路径，如第三个URL所示。 PAY-LOAD对应于%0A{}body{background:NONCE}（简化），其中NONCE是一个随机生成的字符串。0我们的URL变异技术在尝试通过覆盖一系列Web应用程序平台使用的不同URL约定来引起路径混淆和注入样式指令方面有所不同。0路径参数。许多Web框架（如PHP、ASP或JSP）可以配置为使用将脚本输入参数编码为URL中脚本名称后面的类似目录的字符串的URL方案。图1a显示了一个通用示例，其中URL中没有参数。由于爬虫不知道有效参数的名称，它只是将负载作为子目录附加到URL的末尾。在这种情况下，如果页面将页面URL或引用反映到响应中，则可以发生内容注入。请注意，在示例中，我们附加了两个斜杠，以便当展开样式表引用到父目录（../style.css）时，浏览器不会从URL中删除负载。在实际爬行中，我们始终附加了二十个斜杠，以避免考虑不同数量的父目录。我们没有观察到相对路径0使用大量../引用样式表的路径，因此我们确信二十个斜杠足以满足我们的需求。不同的Web框架对路径参数的处理略有不同，这就是我们区分几种附加情况的原因。如果URL中存在参数，我们可以根据我们生成的一些正则表达式来区分这些情况。例如，参数可以通过斜杠分隔（图1b，PHP或ASP）或分号分隔（图1c，JSP）。当爬虫检测到这些已知的方案之一时，它会将负载注入到每个参数中。因此，除了URL和引用反射之外，当页面中任何参数都反映在页面中时，注入也可能成功。0编码路径。该技术针对解码URL中的编码斜杠以进行目录遍历的IIS等Web服务器，而Web浏览器则不会解码。具体而言，我们使用%2F，即‘/’的编码版本，以以使规范化的URL等于原始页面URL（参见图1d）。使用此技术进行注入成功，如果页面将页面URL或引用反映到其输出中。0编码查询。与上述技术类似，我们将URL查询分隔符'?'替换为其编码版本'%3F'，以使Web浏览器不将其解释为查询。此外，我们将负载注入到查询字符串的每个值中，如图1e所示。如果页面在HTML响应中反映了URL、引荐者或任何查询值，就会发生CSS注入。0Cookie。由于相对路径引用的样式表位于引用页面的同一源中，因此在请求样式表时会发送其cookie。如果攻击者能够创建新的cookie或篡改现有的cookie（与其他技术相比，这是一个强假设），并且页面在响应中反映了cookie的值，那么就可能发生CSS注入。如图1f所示，URL只是通过添加斜杠来修改，以引起路径混淆。负载被注入到每个cookie值中，并由爬虫作为HTTP头发送。03.3 可利用性分析0一旦发现某个页面对使用RPO进行样式注入是脆弱的，最后一步是验证响应中反映的CSS是否由真实的浏览器评估。为此，我们构建了一个基于GoogleChrome的爬虫，并使用远程调试协议[1]来驱动浏览器并记录HTTP请求和响应。此外，我们开发了一个Chrome扩展程序，用于在CSS样式表请求中填充cookie头部与我们的负载。为了检测可利用的页面，我们爬取了前一节中至少有一个反射的所有页面。具体而言，对于每个页面，我们检查了图1中哪些技术导致了反射，并使用CSS负载构建了主URL。用于验证可利用性的CSS负载与用于测试反射的简单负载不同。具体而言，样式指令前缀使用一长串'}'和']'字符，以关闭源代码中可能位于前面的任何打开的大括号或方括号，因为它们可能会阻止注入的样式指令被正确解析。样式指令使用一个随机生成的URL来为HTMLbody加载背景图像。我们通过检查浏览器的网络流量是否有一个用于图像的出站HTTP请求来确定注入的样式是否被评估。0Track: Security and Privacy on the Web WWW 2018, April 23-27, 2018, Lyon, France2420通过检查浏览器的网络流量是否有一个用于图像的出站HTTP请求来确定注入的样式是否被评估。0覆盖文档类型。反射的CSS并不总是被浏览器解释。一个可能的解释是页面中使用了现代文档类型，这不会导致浏览器以怪异模式渲染页面。在某些情况下，InternetExplorer允许父页面强制将一个框架页面的解析模式设置为怪异模式[22]。为