偶平时在做安全测试时，一般是以发现问题为主，点到为止，但做安全的同学可能也遇到过这样的问题，当你尝试向开发的同学描述一个漏洞危害怎么怎么样的时候，双方经常会有一种鸡同鸭讲的感觉，甚至他们觉得我们在夸大其词去影响他们去修复，其实面对开发的同学的质疑，我也觉得合理，毕竟你用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、 对输入的数据使用白名单做过滤。
总结：
此类问题的关键还是对数据流的处理问题，当前测试时插入的恶意数据流没有发现问题不代表以后也没问题，对于甲方公司有条件做灰盒测试的同学，可以对输入的数据流进行严格跟踪，数据入口和出口详细分析清楚才能把控好风险，比如：复杂的系统可能是一个数据入口对应多个数据出口，或者多个数据人口对应1个数据出口，甚至可能是多对多的关系。比较保险的做法是找到所有的数据入口和出口，执行以下步骤：
1、对于会被静态存储的数据必须做白名单过滤，比如数据库和日志的入口数据，防止将来可能出现新的数据出口引发的安全问题。
2、对于html的数据出口一定要做安全转义，防止将来可能出现的新的用户可控的数据入口。