不要告訴我，有人在網絡編程時又提示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 的重要性的管理者，這樣的例子不勝枚舉。

很遺憾，這些事故非常普遍，并且不可能消除。

來自: blog.jobbole.com