一個有趣的小Bug避免了一場大災難
我要講述的這個故事是，在一個下午，視頻游戲中的小bug造成的故障，如何促使我去清除來自于軟件的潛在危險漏洞，而該軟件被來自于世界各地的企業和政府使用，這么還讓我明白了一個實踐教訓，即你為什么要將代碼中發現的問題報告上去，即使一開始它們看上去那么微不足道。
這一切都始于這個秋天一個下午，我正在哈佛商學院上關于創業的本科課程。我們正在學習如何用小組的形式來有效地工作，途徑是通過參與一個商學院的模擬游戲，這個模擬游戲是用來教授團隊協作專業管理課程的。
我們被分為五組，并被告知我們的目標是共同努力作為一個團隊登頂一座山峰。此外，還給了我們每個人到模擬網站的鏈接，一旦我們登錄網站，里面就會有 一個屏幕告訴我們，我們在這個團隊中需要扮演的獨特角色。一個是領導者，一個是經驗豐富的登山者，一個是醫護人員，而我則是極其有用的環境保護者，嘿嘿
從根本上而言，模擬是一個老式的、回合制的菜單游戲，用Javascript和HTML在瀏覽器中實現。就像是《龍與地下城》的高級訓練版本，在每 個回合中，每個玩家都需要對往山上的哪里走，以及如何使用他們的設備做出選擇。完成共同的團隊目標和特定個人目標還可以獲得積分（我的目標自然就是通過清 理山上的垃圾來保護自然了，哈哈）。
整個游戲是通過網站上的一系列表格運行的，但除此之外，還有一個一直保持在頁面頂部的對話框，它允許你直接發送即時消息給其他玩家，或整個團隊。當我的隊友對虛擬用品產生爭執時，我開始擺弄對話框，并很快意識到，它會換碼任何我輸入的HTML。
這意味著，我可以通過跨站點腳本，對任意我的隊友的模擬頁面運行我想要的Javascript代碼（如果你不知道跨站點腳本以及為什么換碼HTML的重要性，那么我極力推薦這個視頻）。
因為有了這個新的權力，于是我發送代碼給我的隊友們——在他們的屏幕上彈出消息，通知他們如果清理山上的垃圾，就會有獎勵積分，以及扮演醫護人員角 色的人（特別好斗）并不需要登上山頂。我們很快就收集好了虛擬垃圾，同時也放棄了醫護人員。我置身于模擬游戲之外，轉而讓我的隊友們互相競逐積分，并陶醉 在隨之而來的混亂中。
利用模擬網站中的bug，我制造了很多混亂（當然所有的混亂又都是有趣的），但這絕非嚴重問題。因為問題內置于游戲，所以即便是最壞的情況，心思不 正的學生也只能用來干擾同學，而不能用它來竊取重要信息，也不能像其他著名的跨站腳本漏洞一樣劫持帳戶。我琢磨著，創造這個游戲的商學院教授，后期將這個 網站等的所有事宜都扔給了一個學生去做，而這個學生則匆匆忙忙地在一個喝著咖啡熬夜的夜晚，因為疏忽而遺漏了這個bug。
我本來可以就此放手，隨它去，但我一想到，如果有這樣一個漏洞在我寫的代碼中，我會希望別人能夠告訴我。所以，我決定負責到底，在課后報告bug。
這就是事情變得有趣的地方了。
我寫了一封電子郵件給哈佛商學院出版社，因為它擁有游戲的出版權。我告訴他們，我在這個軟件中找到了一個跨站點腳本問題，然后他們要求我能夠與他們 負責維護模擬優秀的人接觸，這樣以便于我告知他們漏洞的細節。他們告訴我，此模擬實際上是由第三方軟件開發公司創建的，他們會把我提供的消息告知這個第三 方軟件開發公司，以便于該開發公司可以直接跟進。
好吧，事情跟我想得不大一樣。bug不是由粗心學生引進的，它的始作俑者是一家專業公司里的專業開發人員。
現在，你可能會想，這有什么大不了的呢？這只是一個游戲而已。就算有里面有bug，也不會導致什么不好的事情。問題不在于游戲有bug，問題在于， 當一個專業的軟件公司犯了這樣的錯誤時，往往不會是一次性的。很有可能這家公司所使用的質量保證流程，根本不能捕捉這個這個bug，于是乎，他們甚至有可 能正在將這段缺陷代碼用于其他客戶的項目中，從而導致更多的安全漏洞。
我等了兩個星期，也沒有收到那家公司任何有關的后續郵件，因此我給哈佛商學院出版社發了另一條消息，想要知道這家公司的名字以及負責人的聯系方式。然后出版社告知了我這家公司的名稱以及公司CTO的郵件地址。
幸運的是，當我告知CTO bug的時候，他非常敏銳地認識到了問題的嚴重性，快速跑去驗證并解決問題。他證實了公司通過使用由一系列通用工具和模 塊組成的平臺來創建軟件，這意味著他們會天然地復制組件，例如不同產品中的即時通訊系統，但他向我保證，所有的bug實例都會被修復。
由于這家公司通過重用模塊來創建軟件，因此在其產品中的任何一個問題都很有可能存在于其他很多產品中，作為缺陷代碼被重用。此外，事實證明該公司使 用該平臺并不只是為學校教育構建了模擬軟件。他們還開發了為“世界各地的企業和政府機構”提供共享和可視化數據的軟件，并期望通過瀏覽他們網站的“案例” 部分，許多他們面向業務的應用程序趨向于囊括用戶之間的消息功能。這意味著，我們課堂軟件中的那個低風險bug，可能會成為實時應用程序處理政府或企業的 敏感數據時的高風險bug，導致消息系統易受攻擊。
每一個程序員都會犯錯，而且像這樣的跨站點腳本問題是不可避免的。質量保證流程可能會錯過類似于這樣的bug，原因或許是因為團隊正火燒眉毛地沖刺最后的截止時間，所以 規避質量保證能為他們爭取時間，而且他們的代碼將在系統的低風險部分使用。但是，如果你正在構建軟件模塊化它，然而卻沒有重新測試缺陷組件，就把它用到了 其他地方，從而讓其他地方也出現安全隱患，就可能會造成實實在在的災難。
當然，不要誤解我的意思，我并不是說重用代碼不好，重用代碼是一件了不起的事情，它能讓我們更快速地構建系統，而且通常正確率更高。這個真實的故事 告訴我們，得益于重用代碼的巨大好處，因此幾乎我們使用的所有軟件都不可能存在于真空中，同時一個無聊游戲中的bug實際上可能也會導致嚴重的系統漏洞， 防微杜漸，刻不容緩。
譯文鏈接：http://www.codeceo.com/article/little-bug-avert-disaster.html
英文原文：How Finding a Fun Little Bug Can Avert Disaster
