偶平时在做安全测试时，一般是以发现问题为主，点到为止，但做安全的同学可能也遇到过这样的问题，当你尝试向开发的同学描述一个漏洞危害怎么怎么样的时候，双方经常会有一种鸡同鸭讲的感觉，甚至他们觉得我们在夸大其词去影响他们去修复，其实面对开发的同学的质疑，我也觉得合理，毕竟你用XSS去弹个框，能说明什么呢？因此，本案例着偏重渗透的过程，目的是通过一个案例来解决以后鸡同鸭讲的局面，同时也能树立安全部的权威。

YS OMM在记录日志时未对输入数据进行过滤，易导致存储型XSS攻击【高】

问题描述：

         OMM模块在日志中记录了用户对设备等资源的相关操作，但是有些操作日志的内容是用户可控制的，故可以通过特定的接口往OMM日志写入可产生攻击的特殊字符，比如当向日志写入恶意JS脚本，当OMM管理员登录OMM系统查看用户日志时，恶意脚本执行，此时，我们可以下载一段更加强大的JS脚本作为产生一个XSS代理，在外围和内网之间搭建一个通信的“桥梁”，然后利用OMM的公告管理功能向所有YS用户发送带恶意JS脚本的系统公告，一旦用户登录上线，公告的恶意代码自动执行，用户的cookie即被盗取。

注：为了向开发的同志们说明此漏洞的真正危害所在，我们决定在测试平台上进行实战演习，即盗取所有测试账号的cookie，也便于澄清XSS不再是弹一个框的问题。

测试步骤：

1、  启动burp，并开启http拦截代理功能：

2、  登录YS，选择 配置管理> 设备管理> 设备详情> 修改名称，输入合法名称并提交，，如下所示：

3、  在burp拦截到的请求中改为带攻击性的名称，并提交，如下图：

4、  登录OMM数据查看日志，可以看到脚本语句已被写入日志，如下图：

5、  等待OMM管理员登录查看日志。

6、  等待一段时间过后，在xss shell工具的控制界面看到，我们的代码被成功执行了，有浏览器上线，这也说明OMM管理员中招了：

7、  启动xss tunnel工具，配置代理监听端口，这里设置为本地的8079，如图：

8、  设置浏览器使用该代理进行访问，如图：

9、  可以看到，以及成功的访问到YS的OMM控制台，各种强大功能（比如：公告管理）在浏览器上展现出来，如下图所示：

10、              我们模拟攻击者向测试平台推送了一条含有xss代码的系统公告，该xss的代码作用是收集登录用户的cookie，如图：

11、              过了一段时间，我们成功收集到了一些同事的cookie，并且成功登录。

问题扩展：

         可能还有其它接口（比如手机API，PC客户端API）存在同样类似问题，所以对于用户能够控制日志内容的接口都应该应仔细排查。

解决建议：

1、  对写入日志的内容进行html编码（可参考ESAPI的encodeForHTML方法），以确保读取日志时不会产生有害攻击。

2、  对输入的数据使用白名单做过滤。

一个典型的XSS盲打漏洞可导致全网用户cookie被盗取