在前面的文章中，我们讲了持久型XSS和反射型XSS, 我个人觉得这些命名真的很贴切，反应了概念的本质。
无论是持久型XSS还是反射型XSS, 恶意的js脚本内容都需要由服务端返回给用户，今天我们要说的Dom型XSS却例外，一起来看看。
Dom就是文档对象模型，如下：
Dom型XSS攻击思路如下：
我们来具体看一下攻击流程， 仍以localhost来作为微博服务器域名。
步骤1： 坏人C给好人A发了一个链接, 如下：
http://localhost:8080/static?a=test
步骤2：好人A根据链接访问微博服务器，微博服务器的后台代码如下(其中的str是纯静态的不变值，里面的html/js代码本身存在漏洞，它们属于前端代码)：
package main
import (
"io"
"log"
"net/http"
)
func staticFile(w http.ResponseWriter, r *http.Request) {
str := `
<html>
<head>
</head>
<body>
<script>
var a = document.URL
document.write(a.substring(a.indexOf("a=")+2, a.lenght))
</script>
</body>
</html>`
io.WriteString(w, str)
}
func main() {
http.HandleFunc("/static", staticFile)
err := http.ListenAndServe("localhost:8080", nil)
if err != nil {
log.Println(err)
}
}
步骤3：我们来抓包，确认微博后台返回给好人A的信息中，只有静态html/js, 没有跟参数a相关的任何信息：
步骤4： 好人A的浏览器执行改变Dom的操作，最开始链接中的参数a的值显示出来了：
步骤5：坏人C完全可以改变a的值，直接植入恶意js，于是乎，好人A的浏览器就会执行恶意js，比如把A的隐私信息发送给坏人C的服务器，进而进行破坏活动。
可以看到，自始至终，微博服务器没有给好人A返回过恶意js代码，这就是Dom型XSS和之前介绍的XSS的主要区别。至于Dom型XSS的防御，还是依赖于参数校验、过滤等方法，开发人员还是应该慎重。
好了，到此为止，三种典型的XSS都介绍完了，各有特点，关键在于理解其原理。