這篇文章的內容，主要是一個金融服務公司採用報警和要求支付維護費用等手段，抨擊指出其公司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的重要性的管理者，這樣的例子不勝列舉。
很遺憾，這些事故非常普遍，並且不可能消除。