前言：一次偶然的src挖掘，挖到了xss，有些好奇，因为已经是上线很久的src了，竟还有xss，难道是大佬们都对xss不屑嘛，然后就想着看看一些安全平台有没有xss，这不看不知道，一看还真不少！

此次涉及到的安全平台就有此文章发布的某buf平台~

某buf

位置在某buf的在线公开课平台：

而xss发生的位置就在公开课的搜索框，下面简述一下发现的过程

随手对搜索框输个asdf，然后看到有回显，如下图：

然后直接搜一下<img src=1>试一下：

这里是搜出来了一些课的，这里我就觉得不对劲了，看一眼前端源码，有没有我们输入的xss代码

是没有的，应该是给过滤掉了，猜测是对<>的过滤，那么接着看能不能绕过

这里正常的思路应该是先测试对<>进行编码绕过，如下图：

但是这里是没有执行的，正准备放弃时，随手一个asdf<img src=1>，然后出现了这样一幕：

啊这，xss无疑了（经测试弹窗也成功）

但是这个原理有点奇怪呀，对比两种情况的前端代码：

下图是没有解析的情况

下图是解析了的情况

可以看到一个是输出在一行的，另一个是有自动换行的，解析不解析和1的双引号是没有关系的，那么这里到底是为什么呢，继续测试：

在搜索<img src=1>之前如果不是搜索不到的情况的话，那么是不会有回显的，例如搜索a<img src=1>，这样是会回显搜索关键字为a的结果的：

于是通过对搜索过程的数据包抓取分析，发现，数据包返回的并没有我们搜索的关键字：

那么在搜索关键字结果存在时呢，返回结果如下：

这里想一下，应该是后台逻辑的问题，大概捋一下，在后台与数据库交互搜索时，是过滤掉了<img src=1>的，那么如果前面a的搜索结果存在，就返回，如果不存在，就通过前端js返回搜索的关键字，这里在返回搜索的关键字时是利用的前端js直接修改前端代码的，所以应该算是DOM型xss

那么逻辑是搞清楚了

但是这里还是没有搞清楚为什呢&#60;img src=1&#62;虽然前端解析成了<img src=1>但是并没有当成xss标签来解析。

问了大哥，通过大哥的解释，俺也是搞明白了，由于采取了实体编码的形式替换特殊字符，在解析html时词法分析器会跳过它，不把它当成html标识挂在Dom tree上，脚本解释器也会跳过它，不去解释这段脚本。

freebuf平台的xss就分析到这里了~

于是向平台人员反馈

过几天再看，再用之前的payload测试，发现已经修复了，效率杠杠的~

总结

某buf是安全爱好者们比较常用的平台，也是国内顶尖的安全平台了,但是也都由于功能或者其他原因存在一些漏洞，虽然危害可能微不足道，不过也时刻提醒着我们一定要细心，善于发现，截止本文发布，文中所包含漏洞已修复！

水平有限，哪里有问题的地方或者有什么好的意见建议各位师傅们提一下，感谢~