不要告诉我有人在网络编程时又提示101错误信息

这篇文章的内容,主要是一个金融服务公司采用报警和要求支付维护费用等手段,抨击指出其公司url机制存在明显漏洞的人。

问题出在哪?表面上看,他们将原始数据库中的id放在url中以区别客户,所以每个人只要修改一下号码就可以看到别人的账户信息了。从根本上说,你可能会写出这种最愚蠢的网络程序。这个公司非但没有感谢他,反倒为了这个问题责怪他,好像是他的发现才让这个bug显露出来一样。我不知道该如何表述这种情况,也许是一种逆向的海森堡现象?与其说在你观察的时候,这个bug发生了变化;不如说在你观察的时候,这个bug显露出来。

我完全理解这样一种严重的愚蠢行为让网络应用变得多么脆弱,管理者的思维方式经常是这类问题产生的主要原因。与此同时,人们也不熟悉用网络语言编写系统。从我的经验来看,这些问题在金融服务和医疗公司普遍存在。

我曾经和一所当地的公办大学签署了短期的工作合同(准确来说,我并不能算是高质量编码的典范)。小组的一位管理者以前是出纳员出身,她幸运地做上了这个管理的职位(这种情况在大量的人员调动时并不常见),并且很好地维护了手下程序员的优势。我首先注意到的是,只需要通过url中的用户名和密码这种功能上的单一标志就进入到下一个程序(这样就允许你使用后门来获取任何人的密码),不过作为一个局外人,我不想跟管理者说明这种情况,以免引起管理者的疑虑。

合同结束之后我还有一点时间来看看这个小组的主要成果。这是一个应用,这所大学里面的每个部门都要用它来查证他们的官方经费所用何处。如果该信息失效的话,政府会扣留该校所有的费用(基本上大部分是学校的预算)。url看起来比较奇怪,我就查了它的来源。基本上都是上面提到过的同样的bug:数据库的id逐字体现在url中。不仅如此,我们还可以获取所有的行为,包括删除操作。

所以我跟他们说明,只要坐下来,通过浏览器,在url中改动ID,就可以一步一步却肯定能删除整个数据库,这是一件很容易的事情。只需要一点小聪明,我本来就已经写出了一小段命令行客户端程序来为我执行这些操作。这种情况最终引起了管理者的注意(这个机械式的应用普遍存在),我把最后一天的时间都花在了用散列id修补该应用上面(我希望他们以后能改变删除的功能)。

在金融服务公司的时候,我曾经就每次部署新的顾客账户应用时产生的差别很小却更加有趣的缺陷写过很多邮件。几个小时之后,关于人们可以查到其他人的账户信息(投资,结余数额等等)混入自己账户的现场报告形成了。这个应用在QA服务器上运转正常,所以这些现场报告让管理者很震惊,当即在可能有1000个人查到这些信息之前终止这个系统。

我们使用java(这不是一件坏事)和Weblogic作为应用服务器,DB2做后台,以及来自微软IIS网络服务器的服务(这确实是一组奇怪的搭配)。

很显然,几个月前有些顾问已经写了关于这个系统的一些看法,不过都离题很远。他们决定使用Stateless Session EJBs存储语句来为当前登录的用户隐藏数据。这显然是一种完全矛盾的做法,就像SSBeans在所有的对话中共享,你永远无法再次获得同一个SSBean。这看起来行得通的原因在于对bean的引用保存在用户的对话中,(那个时候)它只是一个简单的值而已。后续依次检索到的值将返回同一个bean。这种行为在开发测试环境下的应用池看起来运行良好。该公司没钱,所以只能在QA服务器上面测试该产品。对于产品而言,它只是一个群集;而在QA中,它就是一个简单的app服务器。

所以,一旦存在于无从属引用beans的应用都指向同一个服务器中重用的bean,以及其他群集服务器上面的参考编号,我们就可以通过两种方法将其混淆。你还可以依靠负载多次重复这一过程并且从不同用户的信息中“收集”数据。现在每个数据都应该存储在数据库中。这些混淆的数据应该需要几个月才能理清。

Java编程团队因为这个问题遭到批评,尽管这个错误是由不受管制和从无文档记录的承包商引起的。我认为,项目经理(这是他的过失)责任重大。

当然,几乎任何方法都可以修复这个问题,拥有合适的QA硬件,负载测试,切勿雇佣随便的顾问公司以及相信他们的所作所为,代码审查,真正了解编程的项目经理(如果我没记错的话,首相以前在饭店工作),了解合适的QA的重要性的管理者,这样的例子不胜枚举。

很遗憾,这些事故非常普遍,并且不可能消除。

1 收藏 3 评论

关于作者:李盛晖

李盛晖:毕业于广州一所普通本科院校,读了四年软件专业,却最终回到生我养我的老家,从事印制线路板的设计及品质等相关工作。喜欢上网,喜欢求知探索,喜欢IT科技,喜欢看小说,也许是专业使然,兴趣使然。乐观上进,偶尔也消极低沉,多重性格是也。(新浪微博:@寻找流浪兔) 个人主页 · 我的文章

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部