从一个DOM XSS中学到的

本文适合懂点javascript，而又不是很懂XSS的

前言

前段日子挖到了的一个DOM XSS。

这个XSS有点不一样的地方就是数据来自json，在DOM XSS中渲染的点不一样 意味着过滤方式不一样，错误的编码会产生XSS。

我以前看到过的一般都是渲染到一些标签的text里。

漏洞分析

大概的先看了下这个页面是用react写的，然后在js代码里看到了一些安全方面的内容，比如encodeHTML等等。这是用来解决DOM XSS ，即对一些属性做二次的编码来渲染，而不是直接操作。DOM XSS解决还是要在JavaScript这里做这个事情，别想用Java后端就可以解决DOM XSS。

然后我用调试器简单的定位了下地址，我首先搜了下alert 然后查看到疑似的地方，然后定位到了这个react的render，看到这里的t.needEncode

然后对这个地方下断点调试了下，发现这里的n最后被赋值了t.desc，为什么？当然是因为t.needEncode不存在，是undefined，至于原因。。我也不知道的程序员在想啥，可能忘记了吧，也可能是项目太多了。

总之这里如果程序员对这个属性赋值任何一个值都会导致这个DOM XSS不存在！

然后看代码继续往下跑，在下面有一个id :'js_desc_component_text'这里的dangerousSetInnerHTML，这是一个react的DOM方法，类似jquery的$(x).html()方法，可以对节点插入DOM元素。react本来用这样的方式是用来提醒程序员 这里插入的内容要过滤，要过滤，要过滤！结果！！！！

然后就触发XSS了，如下图

 

总结和回顾

如果用简单的demo来概述下今天遇到的DOM XSS，那么简单的来看下下面这个例子就明白了。

 

我们的输出点是在javascript中，在这里，我们看到对方是做了过滤的，输出的对象内容是经过unicode编码的，但是在javascript中，unicode是会被自动解的，所以在这种情况下，这样的过滤效果是不对的。

正确的解决方式，在javascript输出点的时候应该用html编码下，这样的话我们就不会执行这个DOM XSS了。

在这个案例中，我们可以观察到开发的安全意识非常强，这是借鉴的点，且前端框架是有安全功能的，这也是借鉴点的，大部分公司推动这个很不容易。

但是这里的t.encode 竟然是undefined，因为后来忙自己的SDL工作，忘记分析这个地方为什么是undefined，根据我的印象我是一点也没摸到蛛丝马迹，甚至t下的这个属性也没看到。感觉开发是没想起来。但是回头一想，也可能是javascript中的隐式类型转换导致的没正确的转换到，这个可能性也是有的，毕竟javascript这么灵活。

这是一个比较典型的DOM XSS案例，适合发给开发一起阅读，让他们更好的理解“不同场景下的DOM XSS修复”以及“为什么”

本文始发于微信公众号（xsser的博客）：从一个DOM XSS中学到的