解决重定向漏洞事故的反思

事故描述

今天早上过来，运维全局群里有同事反馈我们微信分享被封掉了，起因是模拟炒股的一个 redirect 的接口，重定向了一个内容不符合微信要求的地址(包含了诱导用户分享的内容)。

08:00 ZJP 群里反馈问题

08:14 WX 给我打电话

08:35 我到达运维这里开始处理

08:41 将这个接口重定向到了模拟炒股官网

08:45 ZJP 让大家去微信这边进行申诉

10:02 WX 将这个接口改为直接返回 404 了

10:12 ZJP 反馈申诉未通过

11:13 新的申诉通过了

11:14 网站恢复

问题反思

为什么这个解决流程持续了 3 个多小时？我在这个过程中，有好几个方面都有问题。

主动性不够

从 8 点开始反馈问题，我这边就没有引起足够的重视，那个域名是模拟炒股的，这应该是我负责的。

解决方式不对

一开始接到问题，我下意识的想到的方案是通过修改 docker 里面的程序，去掉重定向。

这个一方面是因为运维还没到公司，另外应该也是出于怕麻烦人的因素。

这是我的一个非常大的问题，没有明确目标，没有采用能够最快解决问题的方案，而是因为怕麻烦人，去走了弯路。

技术问题

重定向搞了好几分钟，基础不牢固，没有记在心里，平时都是面向搜索引擎编程，遇到问题就搜，改完就丢。

没有明确问题关键点

我选择了重定向，而不是直接 404，导致审核不通过，又重新提交申请；这浪费了一个半小时的时间。