大部分人对DOM XSS理解其实有问题的，很多人！网上随便一搜相关资料的讲解都是location.hash.substr(x)。其实这个和业务场景还是有点远，虽然也能表达这个意思，但是避免很无法解释很多问题。

我推荐大家看owasp解决这个问题的方案和《白帽子讲web安全》里的解决方案，美团的最新一本《WEB漏洞防护》书中对这个漏洞的修复也是模棱两可，仅解释了owasp的encoder组件的使用

最近遇到一个有趣的漏洞，首先这是一个DOM XSS，产生的原因是js代码动态拼接了一个类似这样的代码

$("head").append("<meta>"+text+"</meta>")

给你10分钟，你能讲述这段代码的产生原因吗？

OK，这个代码是一个类似jquery的语法，我在这里编写了一个poc来说明下DOM XSS

可以看到代码是被html过的，但是最后的结果还是会弹窗

原因在于innerHTML输入进去的代码是不会被执行的。比如你按我注释的代码来动态插入一个DOM节点，你会发现那个标签不会被执行，但是jquery之类的框架会在插入的时候把节点的标签eval 下，使得它可以执行，因为这个append()方法本身就是要让插入的元素执行，有这个需求的。

大部分人(问了周围5个人5个人都答错了)错误理解DOM XSS 主要原因是编码的问题。

我们来谈谈这个漏洞如何正确的修复

对于这个漏洞的话一般的大公司的架构可能是这样的

然而这样的情况会和我刚才编写的POC一样触发DOM XSS 产生漏洞。

标准的修复方案是对返回的内容先经过html编码再经过javascript编码，但是大部分开发都不会去和前端业务沟通，毕竟我返回什么还能和你前端使用DOM操作有关系？导致了这个问题的发生。

而且一旦出现问题，修复起来很麻烦，因为早期大家约定了，现在要从html编码改成html+javascript编码 前端也得跟着改，好几个业务一起搞。。哭了。。

那么一般来说

1. 要么开发html+js编码 给前端 然后前端反着来一下再append。

2. 要么js框架统一解决这个问题 就和react的dangerouslySetInnerHTML和vue那样，先判断元素是不是危险的，是的话就用textContent来代替。

怎么发现这些漏洞呢？

数据流扫下js文件吧

本文始发于微信公众号（xsser的博客）：深入了解DOM XSS