一个设计漏洞引发的故事

一个设计漏洞引发的故事

     -- 根据链接URL的字段值判断采用的下载调度策略

---

讲故事吧，想说明一个漏洞案例是具体如何被触成的而已。引以为鉴！

“秦人不暇自哀，而后人哀之；后人哀之而不鉴之，亦使后人而复哀后人也”

==

2010年，为了节省会员CDN带宽与服务器压力，在客户端程序针对会员CDN的连接，做了流量优化的下载调度策略（保证速度的前提下尽量少去CDN请求下载数据），以达到目的。

PS. 会员CDN即XL公司自己架设的服务器专门提供给迅雷会员加速下载的。

诶，好不容易做了一套效果勉强还行（？）的策略，成了。就这样！那时候我才刚刚接手下载调度模块，显然策略的设计者不是我，而是跨部门A的某同事，但是后面我就一直充当其维护者。

题外话：由于某下载调度老前辈升职去了其他部门A结果就顺着带下载调度模块过去，而我当时任务就是尽快熟悉下载调度并拿回来下载调度模块……

当时，百思不得其解，优化策略其中的一奇怪逻辑：判断该资源来自于会员CDN根据其URL是否包含某字段值。 如：

若下载资源对应的URL包含关键字段为"xxx.vip.xxx"，则任务该资源为会员CDN，即参与资源流量优化调度策略。

不明白为啥这么做，我也问过相关同事（跨部门），得到的说法只是设计简单实用。

好吧，程序就在那持续的跑着，没问题。

====

2011年，刚好另一部门B的其他下载产品同样需要做流量优化。该部门的某同事偷偷在其他同事那边打听到了上面描述的”奇怪逻辑“。然后，他就在其产品的下载任务URL上面增加了关键字段"xxx.vip.xxx"。唉，恰到好处确实可行。我估计，该同事当时肯定偷着乐到了。（其实我是事后2012最近才知道这事情的。）

好吧，程序就在那持续的跑着，没关系。

====

2012年，（上面提到的）另一部门B发现那套优化策略已不适用，存在不合理地方，主要由于其产品演变包括用户数剧增，产品特性变化等。既然不适用了那么就需要找人继续优化了。找谁，找其他部门因为他们不持有该策略的研发（downloadlib），正是我现在所在的部门。

经多方面讨论，决定使用已有的那套优化策略服务部门B的CDN，为节省器服务器带宽。这样的决定，说明了我们都不知晓“2011那段故事”。

直到我们完成了功能的开发设计，在做程序连调时候无意间在LOG上发现存在怪异情况，即使没有新加的逻辑，程序也已经在为部门B的CDN资源做流量优化了啊。

……在此省去很多气愤与无奈的表达……

最后，召集大家一起讨论，说清具体事实情况，才知晓了“2011那段故事”。

其实，那套流量优化策略不仅在为部门A的会员CDN服务着，还默默地为部门B的CDN服务着。

好吧，程序就在那持续的跑着，没关系。

====

显然，那奇怪逻辑就是一个设计漏洞。很容易被外者利用以触发原本不该走到的逻辑。还好上面说的外者是自家的兄弟部门。

若是外面其他公司的CDN知道该漏洞，并加以利用了，那么我们不就白白为他人做了巨大的省钱活儿了吗！

所以，需尽快改正回来！

（完）