DOM型XSS漏洞是什么

“DOM 型 XSS” 中的 “DOM” 是指 “文档对象模型（Document Object Model）”。
在网页中，DOM 定义了访问和操作 HTML 和 XML 文档的标准方法。DOM 把网页文档表示为一个节点树，每个节点代表文档中的一个元素、属性或文本内容。
DOM 型 XSS 之所以叫这个名字，是因为这种类型的跨站脚本攻击是通过利用网页 DOM 的操作和处理机制，在客户端的浏览器中注入和执行恶意脚本，而不是主要依赖于服务器端对数据的处理。它强调了攻击是基于对网页文档的 DOM 结构和相关操作的利用来实现的。

DOM 型 XSS（Document Object Model based Cross-Site Scripting）的特点包括：

1. 攻击代码的执行不依赖于服务器端：与传统的反射型或存储型 XSS 不同，DOM 型 XSS 的攻击 payload 是在客户端（浏览器）的 JavaScript 中执行的，服务器端在返回响应时可能并没有包含恶意代码。

2. 基于页面的 DOM 操作和 JavaScript 逻辑：攻击的触发通常是由于页面的 DOM 结构和 JavaScript 对用户输入的不当处理。例如，直接将用户输入嵌入到页面的 HTML 结构中而没有进行适当的编码或验证。

3. 难以通过服务器端检测和防御：由于攻击是在客户端发生的，服务器端的输入验证和过滤可能无法完全防止 DOM 型 XSS 攻击。

4. 利用浏览器的解析特性：攻击者可以利用浏览器对 HTML 和 JavaScript 的解析方式来构造恶意的输入，从而绕过一些常见的防御机制。

5. 隐蔽性较高：因为攻击不依赖于服务器的直接响应，可能更难被发现和检测，尤其是在复杂的前端应用中。

6. 可利用多种输入源：不仅仅是表单输入，还可以通过 URL 参数、本地存储（如 `localStorage` ）、浏览器历史等多种客户端的数据源来获取用于攻击的输入。

虽然 DOM 型 XSS 攻击不经过服务器直接在客户端执行，但攻击者仍然可以通过以下方式窃取受害者的信息：

1. 使用 JavaScript 操作浏览器的 Cookie：通过 JavaScript 可以读取浏览器中与当前页面同源的 Cookie 信息。攻击者可以将获取到的 Cookie 发送到自己控制的服务器上。

2. 劫持表单提交：攻击者可以修改表单的提交行为，将表单数据发送到攻击者控制的服务器，而不是原本预期的合法服务器。

3. 利用浏览器的历史记录和缓存：获取浏览器的历史记录或读取本地缓存中的敏感信息。

4. 劫持浏览器的通信：例如，通过 JavaScript 拦截 XMLHttpRequest 或 Fetch API 的请求和响应，获取其中的敏感数据。

5. 诱导用户操作：通过弹出对话框等方式诱导用户进行某些操作，例如输入密码或其他敏感信息，然后获取这些输入。

总之，尽管攻击发生在客户端，但利用 JavaScript 的功能和浏览器的特性，攻击者仍然有多种手段来获取受害者的信息。

攻击者设置的恶意 DOM 能够到达受害者电脑上，通常通过以下几种方式：

1. 恶意链接：攻击者构造包含恶意 DOM 操作的链接，通过各种手段（如电子邮件、社交媒体、恶意广告等）诱使受害者点击该链接。当受害者访问该链接时，恶意的 DOM 操作代码随页面加载到受害者的浏览器中。

2. 被入侵的合法网站：攻击者入侵合法的网站，并在其页面中注入恶意的 DOM 操作代码。当用户正常访问这些被入侵的网站时，就会加载到恶意代码。

3. 跨站请求伪造（CSRF）：攻击者利用 CSRF 漏洞，诱导受害者在不知情的情况下访问一个包含恶意 DOM 操作的页面。

4. 恶意广告：在一些广告网络中插入包含恶意 DOM 代码的广告，当受害者访问带有这些恶意广告的网页时，恶意代码被加载。

5. 软件漏洞：受害者使用的浏览器或相关插件存在漏洞，攻击者利用这些漏洞执行恶意的 DOM 操作代码。 总之，攻击者利用各种手段诱使受害者访问包含恶意 DOM 操作的页面，从而将恶意代码加载到受害者的电脑上。

以下是一些常见的 XSS 类型及其可能被利用的场景：

1. **反射型 XSS**： - 搜索引擎结果页面：攻击者构造恶意的搜索关键词，当用户点击搜索结果时触发 XSS 攻击。 - 错误消息页面：通过在输入导致错误的参数中嵌入恶意脚本，在错误页面显示时触发。 - 短链接服务：攻击者创建包含恶意脚本的短链接，用户点击后触发。

2. **DOM 型 XSS**： - 社交网络分享内容：例如分享的文章、图片描述等部分可被注入恶意 DOM 代码。 - 在线调查问卷：问题或选项的输入字段可能被利用。 - 第三方小工具或插件：如嵌入网页的地图、投票组件等。

3. **存储型 XSS**： -评论区，论坛的帖子内容、用户个人资料、博客文章等用户可长期存储数据的地方。 需要注意的是，这些只是一些常见的场景，实际情况中，任何接受用户输入并在页面中显示的地方都可能存在 XSS 漏洞和被攻击的风险。

以下是一个简单的示例，展示了一个 DOM 型 XSS 漏洞以及可能的攻击过程。请注意，这只是为了演示目的，在实际开发中应避免此类漏洞。

首先是一个 Vue 3 的前端页面：

<template>
  <div>
    <input type="text" v-model="userInput" />
    <div>{{ showMessage }}</div>
  </div>
</template>

<script setup lang="ts">
import { ref } from 'vue';

const userInput = ref('');
const showMessage = ref('');

watch(userInput, (newValue) => {
  showMessage.value = `You entered: ${newValue}`;
});
</script>

在上述代码中，如果用户输入的内容是一段恶意的 JavaScript 代码，比如 `<script>alert('XSS attack!')</script>`，那么当 `userInput` 变化时，这段恶意代码会被直接嵌入到 `showMessage` 中并显示，从而导致 XSS 攻击。

接下来是一个使用 Spring Boot 的后端示例，假设这个后端接收前端的请求并返回数据给前端：

@RestController
public class MyController {

    @GetMapping("/getData")
    public String getData(@RequestParam String input) {
        return "You sent: " + input;
    }
}

如果前端将恶意的输入发送到这个后端接口，而后端没有进行适当的输入验证和清理就直接将其返回给前端，并且前端将其直接嵌入到页面中，也可能导致 XSS 攻击。

执行过程解析：

当用户在前端输入恶意的脚本代码时，Vue 3 的 `watch` 函数会将这个输入嵌入到 `showMessage` 中。如果没有对用户输入进行适当的消毒或转义处理，浏览器会将这个嵌入的脚本当作合法的 JavaScript 执行，从而触发恶意行为，如弹出警告框等。

对于后端，如果接收了恶意输入并且没有进行处理就返回给前端，前端在使用这个数据时也可能引发类似的问题。

在实际开发中，应该始终对用户输入进行严格的验证、消毒和转义处理，以防止 XSS 攻击。