《遊戲設計師修煉之道：資料驅動的遊戲設計》一2.3 建立漏洞：一個例子

現在，讓我們使用上文提到的所有項目設計一個場景，通過實際演練來了解善意程式造成的惡劣後果。本章開始提到的電子郵件程式就是個好例子。稍後，我們将按照sdlc的所有步驟，來看看是哪裡會出現問題。

1）概念和方案：xyz公司認為，如果他們使用比市面上任何其他程式都好的特定程式發送和管理電子郵件，是一件很不錯的事情。該特定程式将使用經特殊改寫的格式，在消息中提供獨一無二的功能。會出現什麼問題呢？它将會使系統更加複雜。跟gdi+ api例子類似，更多的複雜性帶來更多的故障。如果新功能對該産品的成功非常重要，那麼從項目一開始，就應該重視系統中特定部分的安全性。至少，關鍵元件的可靠性和安全性應該是概念中的一項重要内容。

2）需求收集：從提出概念的人那裡收集詳細的功能需求。我們對所有将采用的功能設計及其能夠對業務模型起到的提升作用都感興趣，因為它們可能會在将來的某個時刻起到重大作用。會出現什麼問題呢？沒有一項需求包含有關安全性和可靠性的内容。而提供安全性和可靠性應該是任何應用需求的一部分。來自需求收集過程中的每個想法都将導緻某種程度的項目需求變更，這将引發功能性的設計缺陷。在需求階段，限定需求的範圍，除了能夠使成本最小化且確定時間進度外，還能最小化漏洞産生的幾率。

3）設計：應用程式的細節，包括資料庫、檔案系統、作業系統、相容性，都需要仔細設計。會出現什麼問題呢？設計，像需求分析一樣，隻考慮功能，所有的注意力都集中在如何使應用程式工作上。應該将一部分工作優先放在確定應用程式建立嚴格符合限定條件的資料流上，然後對輸入/輸出資料的有效性進行驗證，這樣就可以較好地保證輸入的應用程式函數參數的合法性。程序間通信必須設有資料有效性檢測和權限授予的代碼段，以使程序能夠驗證來自另一個程序資料有效性和程序來源的合法性及操作權限。從這個階段開始應該引入威脅模組化分析。通過識别程式可能遭受攻擊的高危部分，開發團隊可以集中精力來改進各個元件，尤其是最易受到攻擊的元件。

4）編碼：完成設計之後，開始編寫代碼。會出現什麼問題呢？在漏洞世界裡衆所周知的是：程式開發人員并不都願意遵照那些能夠避免類似緩沖區溢出等漏洞的優化編碼方案。但是，應該盡量使用最佳安全編碼方案，例如動态調整的資料結構的邊界檢查（bound checking）和輸入資料的有效性檢查。

5）測試：測試的頻率很高。故障不斷被發現并被迅速修複。測試員不斷對所有未包括安全元件的功能需求項進行驗證以確定它們的正常實作。會出現什麼問題呢？軟體測試一般承受着最大的時間壓力，因為管理者希望盡快生産出成品，并且幾乎不能容忍絲毫的延遲。開發人員常常将程式分解以期盡快通過測試階段，因為每當這樣做時，測試人員的注意力就會全部集中在功能上而跳過回歸測試（regression test）。應該參照前文提到過的威脅模型分析來對産品進行某些滲透測試。

6）部署：最終産品出廠了，經過包裝被運送到世界各地毫無戒心的顧客手中，附帶軟體的安裝使用說明書。會出現什麼問題呢？說明書中沒有對軟體運作最合适、最安全的系統配置做任何說明，也沒有指出在網絡接口上哪些網絡端口是除了伺服器外對其他任何ip位址都不能開放的。開發團隊應該制定一些政策來處理發現的漏洞。如此一來，就需要更多的測試人員來對軟體進行滲透測試了。

7）漏洞檢測：一個對該産品感興趣的使用者可能會好奇，如果利用這個電子郵件軟體發送一封經過特殊設計的電子郵件會産生什麼情況。這封特殊的郵件能夠滿足軟體特定子產品的處理要求，但是，其消息資料超出了該子產品标準資料結構的要求。結果是程式崩潰了，并在作業系統的記憶體中留下一些消息碎片。

8）漏洞利用：現在，該使用者想知道是否能在這封特殊郵件的消息内容中嵌入一個程式以使其能夠留在記憶體中并運作。結果發現這确實可行。在實驗中，一個小的“hello world”程式運作起來了。

9）漏洞修複：此刻這個非常激動的使用者開發了一個增強版本，在郵件消息中嵌入的程式能夠生成郵件自身的多份副本，并自動将其發送給通訊錄中的其他收件人。電子郵件程式強大的功能設計使得通路郵件通訊錄變得更為容易了。就這樣，該産品的首個電子郵件蠕蟲誕生了。

建議：應該盡早解決能夠被利用的漏洞。從長遠來看，在達到相同安全等級的情況下，這樣做能有效減少技術上和安全上的工作量，并能減少檢測和防範工具的開銷。