我们被黑客攻击了！！！

记修复Struts2的S2-046漏洞前后

Struts2的这个漏洞的主要介绍：

由于上传功能的异常处理函数没有正确处理用户输入的错误信息，导致远程攻击者可通过发送恶意的数据包，利用该漏洞在受影响服务器上执行任意命令。
攻击者可通过发送恶意构造的HTTP数据包利用该漏洞，在受影响服务器上执行系统命令，进一步可完全控制该服务器，造成拒绝服务、数据泄露、网站造篡改等影响。由于该漏洞利用无需任何前置条件（如开启dmi，debug等功能）以及启用任何插件，因此漏洞危害较为严重。

漏洞是今年三月初爆出来的，开始的时候大家也关注了一下，但是当时每个人手上的项目都没有使用Struts2，而且也没听说公司有什么项目用Struts2然后大家就不太注意。到了3月中（估计是爆出漏洞的第3天），有人攻击进公司旗下的一个电商平台（一个有点年纪的项目了，而且没有人用）估计是白帽子黑客，只是发了段警告给我们，这个时候运维就联合我们一起修复，当时也不太重视而且其他项目很赶，就拖拖拉拉的。后面到了3月底，又有人来了这次就不是上一次那么好说话了，直接获取权限把数据清空。运维估计是一下子就慌了，数据没有完全备份的情况下，把系统重装（其实这个时候我们修复的版本已经弄好了，不知道什么原因没有上上去）。这下苦日子来了。

修复这个漏洞并不是件很复杂的事情，换换jar包轻轻松松就搞定。最严重的问题反而是来自于系统重装。

下面介绍各个问题解决的前后的相关细节：

1. 线上的系统死活上传不了图片和文件（注意是连服务器都没有提交进去），但是测试服和开发机器上面一点问题都没有；
2. 用户无法注册，提交信息之后直接页面超时；
3. 用户无法使用平台的金币买单；
4. 问题1修复好之后，部分图片上传报下面的异常：

java.lang.ClassNotFoundException: com.sun.image.codec.jpeg.JPEGCodec

上传图片做头像。

5. 上面的问题都弄好之后，出现了一个大boss----solr。solr服务器启动不了（这里启动不了就完全用不了搜索功能）；
6. solr启动之后，还是用不了搜索功能。后来有同事说solr要同步索引。
7. 同步索引失败：同步时报400 Bad Request: unknown field 'type'

下面介绍各个问题解决的前后的相关细节：

参与背景：

这次修复人员名单里面其实是没有我的（开会没有我，绩效没有我），只不过后来实在感兴趣而且组长吩咐（估计想叫多一点人，不至于大家被骂惨。当时一位新入职的同事也被临时加派其中），后来觉得这次忙帮得很值！

各个问题解决前后的细节：

问题1：
看起来最简单的第一个问题其实花了我们最多的时间，早上开会（还好没叫我去）领导开骂，大概10点半开始，然后下午两点多的时候才弄好。
对于这个问题大家的定位一开始有：
a. 项目的上传路径分隔符写死；
b. Struts里面有拦截器/过滤器把提交的表单给拦截了；
c. 为解决S2-046漏洞替换的jar在Linux下，无法正常工作；
关于a：查看源码之后发现分隔符是使用标准的File.separator，路径什么是System.getProperty("user.dir")反正就是一点毛病都没有，后面怕线上的文件被替换过又拷贝一份进行对比，还是没问题---------排除
关于b: 在定位b的时候，发现的一个很严重的问题。由于系统重装，服务器时间比标准时间慢3个多小时。这个时候顺便把2,3完美解决掉了（因为所有关于钱的交易都在另一台服务器上，并且每一次交易都会进行时间验证。注册和登录在另一台服务器上原理大致一样）。正在我们雄赳赳的想把这个问题解决掉的时候，突然发现人家根本没有时间验证，不死心的我们，把自己的机器的时间也调了一下，一测还是可以上传。后来发现有一个管理员ip限制的拦截器，以为自己最终找到了问题，打断点发现人家进都没进，而且如果是这个问题测试服估计都是有问题的。
关于c：直接pass

最终结局：

后来越想越奇怪为什么测试服可以，开发机可以就线上不行呢？后来有人说可不可能是重装导致线上的应用服务器没有上传权限。真是一眼惊醒梦中人，怎么想怎么像，而且页面跳转也是报404而不是500。好写一个简单的文件上传页面，拿到线上一测。所有的问题都明了了，就是这个权限问题，运维被我们打了一顿。

问题2：
因为重装导致服务器时间不标准（相差3个小时），注册登录服务器与该项目部署到不同的机器，而且要时间验证。所有报超时异常。

问题3：
与问题2类似

问题4：
其实这个问题也是线上才出问题。我们上网搜了一下，有人说com.sun.image.codec.jpeg.JPEGCodec人家已经不推荐使用了，后来换了ImageIO。测过之后线上线下都没问题。

问题5：
其实这个不算是问题，只不过找不到之前的solr服务器备份了。后面找了很早之前的一个备份，然后根据solr的部署规则部署在一台tomcat上。问题解决。

问题6：
原本以为部署solr之后，搜索功能就会乖乖回来。测了一下--毛线都没有！！！想打人，不过看看已经在墙角躺尸的运维忍了。这时候一直没有存在感的新同事来了一句关键的----“solr是要同步索引的”。走上一条不归路。。。

问题7：
听新同事说Solr索引同步可以在Solr后台进行，登录后台之后发现这他妈是什么，整么跟百度谷歌上面长得一点都不像。弄了好久。。。后来运维做了一件事，让我深深地惭愧，运维居然找出了写在后台的一个跟新solr索引库的方法，自责！不应该对运维这么粗鲁，这么多大汉对他一个有点残忍。。。。正当我们以为可以走人的时候，方法报错了。哈哈哈！贼老天有什么事你倒是冲其他人啊，老是抓住我们不放是个什么意思。
不过好在solr服务器有明显的报错---400 Bad Request: unknown field 'hnihh'。这个时候我们居然在没有百度谷歌的情况下完全靠猜把问题解决了。当时我们是这么想的，solr估计就像个数据库，那么里面的索引什么的估计是在什么地方有配置的，看看配置信息估计是solr没有将字段'hnihh'没有配置进去，看了看Solr里面的文件组成，确定是xml文件配置的。
然后就将solr下面所有的xml搜下来，最后锁定在scheme.xml这里。打开一看，果然项目中的索引字段都在里面，唯独缺了"hnihh"。添加完标签之后，重启再来，问题解决。最后搜出结果的那一刻、那一种心情，估计只有程序员才能理解。

后续问题：

所有代码、系统层面上的问题都解决之后。页面显示还是有bug--很多图片都没有，这个就是因为没备份导致图片缺失。其中各种找备份还原，其中辛苦不足为外人道。

本次漏洞修复心得：

1. 对于极大多数人来说在代码面前没有什么问题是解决不了的。
   很多时候代码上的一个小问题都会使得你精疲力尽、无可奈何，但其实背后的问题其实很小很小（参考问题1、2、3）；
   很多时候看起来很复杂的技术，其本质估计你早已知晓。花一两个小时认真学进去，不焦急不慌（参考问题5、6、7）；

2. 许多互联网公司提倡的九九六根本就没有必要。

    本次bug解决总时长12个小时，去掉不是问题的问题（问题1）花去的时间大概9个小时。参与人员：3人，这说明什么问题估计大家都明白。

3. 遇到漏洞一定要重视。
   这个就不说了
4. 公司有同样的问题要解决的时候，要积极参与。不叫你也厚脸皮问他几下、看他几眼。
5. 大胆假设问题所在，通过其他方面进行联想问题。
6. 尽量不选择Struts2
   为前公司的组长默哀一分钟。