外包的项目，上线前一定要排查清楚漏洞

今天早上很早就醒来，打开手机发现昨天晚上快12点的时候，我们业务经理打电话给我，然后我打开我们的APP，发现我们的APP报连接服务器错误，第一反应是我们的项目又内存溢出了。

由于这个项目是从外包手里接手过来的，很多内容也没有去优化，所以有时候会报内存溢出，所以自然而然地想到了这一方面。

打开服务器一看，有点诧异，服务器竟然没有运行项目，然后我就自觉地把服务器重启了下，还以为是阿里云自动重启了。还自以为是地给经理发了个信息，说由于阿里云自动重启，所以昨晚的服务死掉了。以为事情就这么结束了。

结果一到公司，同事跟我说，昨天晚上服务器被人攻击了，由于一时半会儿没找到问题，他就直接把服务器停了，这才让我意识到问题的严重性。

主要问题是昨天晚上有一个用户在我们平台下了很多单，通过支付宝付款，前端显示都已经支付成功，但我们的支付宝账户没有进一分钱。

由于整个项目是外包那边接手过来的，现在又在开始开发新系统，所以里面的很多风险都无法预测，接下来只有一一去排查问题了。

问题一：是否直接在我们的数据库修改的信息

我们首先去看了下tomcat的日志，看看他到底有没有请求接口。后来想想也不太可能，服务器所有密码都重新修改过，数据库也已经做了迁移，现在只有内网能访问，所以基本可以排除到这一点。那么自然而然想到了第二点。

问题二：他们模拟了支付宝的回调

这让我们感到有点不可思议，我们平台才运行几天，总共用户也才几百个，谁会花这么大心思来搞我们这个东西呢。其实，我们做开发的明白，这个模拟请求是需要我们生成给支付宝的公钥以及发给支付宝的参数才能这么干。我们心里也明白，八九不离十是外包团队干的。不得不说，这也是我们的疏忽。

为了验证我们的想法，我们去查看了后台数据，发现昨天晚上回调的支付宝订单号根本就不是支付宝给我们的订单号格式。

找到了问题的来源之后，接下来就是要想办法解决了。

尝试了很多方法：

方法一：尝试去重新生成一个订单号用于和支付宝校验。

后来发现，这个订单号，app端也是需要使用的，更大的坑是，支付宝的签名竟然直接放在APP端，这样如果要改的话，就要更新版本，代价太大。

方法二：修改支付宝的回调地址。

本来以为是在支付宝的后台修改的，后来发现又是在客户端写死的。

方法三：获取回调地址的来源

本来以为可以从request中获取到，后来不知道是我们方法的问题，还是支付宝那边做了处理，就是获取不到回调地址的来源，只能放弃。

方法四：重新验证

为了保证数据的安全，只能牺牲一点效率。怎么做呢？我们在支付宝回调之后，用支付宝给我们的参数，又去支付宝获取了订单详情，如果可以正常获取到，并且参数也正常的话，就判断为合法。这样至少保证了数据的安全。

折腾了一天，最后不管怎样，解决了问题，还是挺开心的。