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的数据出口一定要做安全转义,防止将来可能出现的新的用户可控的数据入口。