2021年1月底，在新年即将到来之际，身边又出现一例安全事件。

下面会详细介绍本次事件造成的原因，排查手法，与解决方法，希望程序员小伙伴们引以为范，不要再出现同样的错误。主要是分享思路。

吃瓜观众，请谨慎吃瓜。故事开始！

简单来说，就是企业把所有收费的音视频资源都放在阿里云oss服务中的，而有黑客非法获取并下载了所有资源，并上传到了百度网盘中。

通过与该企业进行沟通，发现网站服务器并没有被入侵的异常情况，功能以及日志等一切正常。那么可以先假设问题点是在阿里云OSS中。

笔者并没有用过阿里云OSS，但这个并不妨碍我们解决问题。随手百度一搜索，发现其实就是一种资源存储服务，通过API接口进行通讯。安全核心就是AccessKeyID和AcessKeySecret，也就是“接口的账号和密码”

点着一根烟，思考了零点几秒，总结出主要问题原因最大可能应该是AccessKeyID和AcessKeySecret的泄露导致。较小可能是网站/服务器被入侵。

那么，又有以下多个问题引出，需要咨询该公司：

一：是否在github上有代码？代码状态为公共还是私有？

解析: 

防止项目代码在github上没有进行权限设置，搞成开源项目并且代码中还保存有核心安全配置信息就尴尬了。

二：AccessKeyID和AcessKeySecret的配置方式是采用的哪种方式？

1：数据库存储，服务端查询数据库获取私钥然后进行签名

2：服务端代码配置文件中存储与签名

3：客户端通过JavaScript代码存储与签名

解析：

如果是数据库中存储，那么可能存在sql注入，黑客已经是拥有了数据库的读写权限。（严重）

如果是在配置文件中存储，可能黑客已经拿到了网站服务器的webshell，接管了网站的"所有权",包括了增删改查等等。(严重）

如果是在客户端JS存储，那么当前的影响低一些，较大概率服务器没有被入侵。仅是私钥泄露导致的安全事件，只影响阿里云OSS，不影响业务网站与服务器的安全。

4：网站开发所用语言(比如java/php)，以及框架(比如ci/thinkphp/laravel/springboot等)。

解析：

如果是使用的的开源框架，高风险的诸如thinkphp(竟然爆漏洞)，那么网站/服务器在本次安全事件中被入侵的几率会提升。

然而，与我沟通的人员并非开发人员，以上问题基本不知道！需要联系开发人员。但时间有限，不管了，只能自己先开始测试了，虽然已知的信息实在是有限 

一、事件描述

系统音视频资源文件遭遇泄露，但代码与网站暂时未发现安全问题。

泄露的收费内容，已被公布在百度网盘，甚至在淘宝上贩卖。

根据目前掌握的情况来看，最大可能为存在OSS存储的资源文件泄露，怀疑是AccessKeyID和AcessKeySecret泄露导致的。

二、信息资料

业务网站地址；

资源存储采用了阿里云OSS；

不是用的thinkphp;

没了...

三、事件排查

资源泄露主要有以下几种可能性：

1：有权限观看的用户通过技术手段把资源文件下载到了本地【低】(因为攻击者的百度网盘的文件目录结构信息与OSS高度相符)。

2：单纯的AccessKeyID和AcessKeySecret信息泄露(比如聊天泄露，github泄露，说明文件泄露等)【低】；

3：网站系统配置不当导致AccessKeyID和AcessKeySecret信息泄露【高】；

4：网站系统/服务器被入侵，黑客已经拿到网站控制权限，找到了AccessKeyID和AcessKeySecret信息【中】；

四、手工排查操作方法记录

掌握的信息有限，可以先测试前端泄露问题是否存在，并且前端隐私信息泄露的可能性还是很高的，很多没有安全意识的开发人员很容易犯这种错误。

1：先随手打开网站地址(由于隐私问题，暂不公开)，查看html源码，如下：

整个页面其实只是个登录的前端页面。JS文件大概有10多个。

根据开发经验，文件名规则，排除UI框架，编辑器JS，以及其他一些JS库之后，发现仅有/js/util.js这个文件为开发人员自定义写的。如果存在泄漏，那么可能也是在该文件中。

2：打开/js/util.js，查看源码，随便翻翻，果然！果然！发现了敏感信息泄露漏洞！

到了这一步，基本已经可以断定是由于把OSS的接口秘钥信息保存在前端JS中导致的安全问题了！

还好，还好，不然这继续下去要检查和排除的地方就太多了，甚至还要搞代码审计，服务区环境安全检查，日志分析等;

五、根源性解决方案

OSS的配置信息，不要在前端配置。OSS安全的使用，需要在后端程序中进行签名。前端不需要的。

1：修改OSS的接口账号密码。或新建OSS。

2：限制OSS登录的IP等，仅允许服务器。(没使用过OSS，不知道有没有这功能)

3：删除 /js/util.js文件中的OSS配置信息代码。在服务端写上传签名逻辑。

六：其他备注

本地应急响应仅解决了此次安全问题，可以一定程度上避免后续遭遇OSS泄露问题。但不排除有其他漏洞或安全隐患导致被入侵。

为了最大化避免后续被黑客攻击入侵造成损失，建议选择忘忧草安全团队的企业安全托管服务。实时应急响应、安全监控、攻击溯源等。减少被攻击导致的损失。

到了这里，本次分享就快结束了，最后再提醒大家：

重要的配置信息，千万不要放在前端！一定要在后端做处理。不要用js！

另外，如果采用.env等文件存储，那么一定要放在网站根目录之外，或者配置访问规则，禁止访问。

如有转载，请注明出处!《记一次应急响应,OSS安全配置不当引发的商业血案》的原文地址：http://www.xiao6.net/post/230.html