xss - XSS 是否总是需要服务器端漏洞才能工作？

Question

如果这是一个愚蠢的问题，我深表歉意......这是在一个理想化的、无法实现的假设的背景下帮助我理解 XSS 攻击的核心：

如果一个普通的、无所事事的非恶意但不安全的 HTML/CSS/JS 脚本客户端正在与完全防弹的PHP/交换 JSON 数据（不涉及文件/文件系统） / MySQL脚本服务器端，XSS可能吗？

还是所有XSS 攻击总是基于访问/更改/存储服务器端的能力？

我只是想弄清楚“边缘”在哪里。在过去的几天里，我已经阅读了几十篇关于 XSS 的文章/帖子，但如果答案在其中任何一篇，我都没有理解。:(

提前致谢。

标签： xss

Answer 1

简而言之，XSS 是关于能够在用户的上下文中运行 javascript，通过应用程序输入提供。这意味着通过说开发人员控制台进行操作不算数，用户必须主动打开控制台并做他通常不会做的事情——在大多数情况下，这不是一个有效的攻击向量。但是，所有应用程序输入（UI 上的输入、url 栏、请求标头等）都是注入 javascript 的潜在方式。

在反射或存储 xss 的情况下，请求被发送到服务器，响应包含来自请求的 javascript，其方式是在客户端上运行。所以那些需要一个服务器。

然而，在 DOM xss 的情况下，它都可以在客户端，在易受攻击的 javascript 代码中。

考虑一个 UI 具有输入字段的示例，当用户单击按钮（“发送”）时，他输入的任何内容都会通过客户端上的 javascript 添加到某种日志（例如“聊天窗口”）中. 如果用户输入<script>alert(1)</script>，它可能会作为 html 附加到日志区域，从而作为 javascript 执行，而不会被发送到服务器。这将是 DOM xss 的示例，修复显然是将其附加为文本节点，而不是 html。

这通常被评为较低风险，因为在许多情况下，远程攻击者实际上利用此漏洞攻击毫无戒心的用户的机会有限。但这仍然是一个漏洞（例如，攻击者可能会让用户将某些内容复制粘贴到字段中等等）。

还有一个典型的可利用案例是，当 javascript 读取 DOM 并将 URL 的一部分添加到 DOM 时，这实际上可以由远程攻击者提供（以发送给受害者用户的链接的形式）。