目錄
習慣 1：承擔責任
習慣 2：永遠不相信數據
習慣 3：模擬針對您的代碼的威脅
習慣 4：始終提前一步
習慣 5：模糊！
習慣 6：不要編寫不安全的代碼
習慣 7：識別策略不對稱
習慣 8：盡可能使用最佳工具
我非常榮幸在過去的幾年中曾經與數千位出色的開發人員一起工作，他們希望了解如何編寫更安全的 軟件。在此期間，我也從構建安全系統方面表現出色的人員那裡學到了很多東西，這使我開始思考一個問 題。我在想“安全開發人員”之間是否有共同的技能或習慣。答案是當然有！本文介紹了安全代碼開發人 員之間共有的一系列習慣。
目前我可以肯定的一點是，任何看過這篇文章的人都會立即發現自己不具備的習慣。這非常好。我知 道除此以外還有其他好的想法。這裡只是列出我所觀察到的！因此，下面介紹的是我在這幾年中注意到的 幾種典型習慣。
習慣 1：承擔責任
這是長期以來“沒有銀彈”觀點的一種轉變，該觀點是 25 年前 Fred Brookes 在其“人月神話”一 書中提出的。能否使您的產品具有足夠的安全性完全取決於您自己。其他任何人或任何出色的工具或編程 語言都無法解決所有安全隱患。不要誤解我的意思，我喜歡源代碼分析工具，但他們無法神奇般地修復您 的所有安全漏洞。只有您自己可以做到這一點。
只有創建安全設計和編寫安全代碼的開發人員才能構建出安全產品。最後，編寫代碼由個人完成。工 具不能取代個人完成這項工作。因此，您產品的安全性就是您的責任！Blaster 和 CodeRed 蠕蟲利用的 就是個人編寫的代碼（參見圖 1）。
圖 1 有弱點的代號是人編寫的
請記住，要仔細檢查所有代碼，所有代碼都有可能受到攻擊。沒關系。受到攻擊也沒關系。關鍵是， 您的代碼是否會遭到破壞？只有您可以決定最終結果。因此您的代碼必須要使您自己滿意。您必須對代碼 的質量充滿信心，因而在晚上可以安心地休息，因為您知道如果受到攻擊，您已經做好了萬全的准備，可 以防止代碼受到破壞。
如果有可能，最好請一位安全專家對您的代碼進行專業評審。不要讓那些對安全一無所知的人來檢查 您的代碼，不要期望他們能夠找出安全錯誤和漏洞。要留出充分的時間讓真正了解安全性的人檢查您的代 碼。
不要過於自負，在需要幫助時應主動尋求幫助。我剛剛提到了，您不應完全依賴於工具，但您應該利 用一切可利用的資源。請對您的代碼運行所有可用的源代碼分析工具，並經常這樣做。利用所有可用的防 御性語言構造和庫技巧。例如在 C# 語言中，將執行數組訪問的面向網絡的代碼打包，其中數組索引來自 網絡請求，采用 checked 操作符的形式，以檢測可能出現的整數算法錯誤。
習慣 2：永遠不相信數據
對於這一點，我已經說過無數次，但我還要重申一遍：所有輸入在得到證明之前都是不可信的。看看 那些最讓人深惡痛絕的安全漏洞，您就會發現它們所擁有的最顯著的共性就是開發人員相信了輸入的數據 。問題在於您的代碼假定這些數據是可靠的，那麼如果您的假設不正確將會怎樣？在某一天您的應用程序 很可能會崩潰。如果嚴重的話，攻擊者可能會在您的流程中插入惡意代碼並破壞您的流程。
安全系統的定義是只執行所要求的任務而不執行其他任務的系統。這一定義有些古怪。當輸入的數據 存在信任問題時，您往往會讓系統執行其他任務。常見漏洞和披露 (CVE) 數據 (cve.mitre.org) 的粗略 分析顯示，從 2001 年至 2004 年，CVE 跟蹤的所有安全漏洞中有 47% 的漏洞屬於輸入信任問題。最顯 著的問題就是緩沖區溢出、整數算法錯誤、跨站點腳本和 SQL 插入錯誤。我們開始不斷看到這種漏洞的 新變體，如 XPath 插入漏洞和輕型目錄訪問協議 (LDAP) 插入漏洞。
您可以根據幾個簡單規則糾正輸入信任問題。首先，不要只看您知道的錯誤，這就假定了您知道所有 錯誤，並可預測將來發生的所有錯誤。查找錯誤是可以的，但條件是這不是您唯一的防御手段。更好的策 略是將輸入控制在您知道的正確的范圍內。對於諸如 C# 和 Perl 此類的高級語言，我喜歡使用正則表達 式來確保這一點。
其次，拋棄您已知的錯誤。例如，如果某人通過您的代碼遠程請求一個文件，並且文件名中包含不確 定的字符（如：or ），請拒絕該請求。並且不要告訴攻擊者原因；只要說“找不到文件”即 可。
最後，淨化數據，這一點並非對所有情形都適用。例如，在 Web 服務器中，您應對可能不受 信任的輸入的輸出進行 HTML 編碼。
習慣 3：模擬針對您的代碼的威脅
您應該有威脅模型 對吧？利用威脅模型，您可以了解您的軟件可能面臨的風險，並確保您有適當的降低風險的舉措。但威脅 建模帶來的益處不僅僅限於安全設計。威脅模型還可以幫助您確保代碼質量。威脅模型可以告訴您數據的 來源。數據是遠程的還是本地的？數據來自匿名的用戶，還是來自可信賴的（已驗證的）用戶、管理員？
通過掌握這些信息，您可以確定您的防御措施是否到位。例如，匿名用戶和遠程用戶都可以訪問 的代碼最好是非常安全的代碼。這並不是說只有本地管理員可以訪問的代碼就應該是不安全的代碼，我的 意思是遠程可訪問的代碼（尤其是默認情況下運行的代碼）必須非常安全，這就意味著要提供更多的防御 措施、對代碼進行更詳細的審查、更注意代碼的細節。此外，威脅模型還可以告訴您受保護的數據的特點 。例如高價值業務數據和個人可識別的信息應受到嚴格保護。您的防御措施是否到位？
確保您的 威脅模型准確並保持最新，然後確定您的代碼的所有入口點，並按可訪問性（遠程還是本地，高權限還是 低權限（或無權限）用戶）對其進行排序。首先要對最多人可訪問的代碼進行最深入的審查。最後沿著匿 名數據路徑審查所有代碼，換句話說，從每個匿名可訪問的入口點開始，沿著該路徑跟蹤數據，檢查代碼 的准確性。
習慣 4：始終提前一步
安全環境總是在不斷變化中。似乎每個星期都會出現安 全問題的新變體。這就意味著您必須不斷演變並了解新威脅和防御措施，否則您就要承受由此帶來的後果 。
可保持領先的幾個簡單策略是經常閱讀關於軟件安全性的優秀書籍。同時從您過去的錯誤中吸 取教訓，當然能夠從他人的錯誤中吸取教訓則更好。要做到這一點，您可以閱讀 bugtraq — 轉至 securityfocus.com 並同意通過您的收件箱接收 bugtraq 發布的內容。但請務必采納以下建議：創建一 項收件箱規則，將發布的內容轉移到一個特定的文件夾中，以便您進行處理。這一點非常重要。
習慣 5：模糊！
模糊化處理是一項測試技術，旨在找出可靠性錯誤。經證實，有 1% 的可靠性錯 誤為安全漏洞，很有可能被利用！當然，緩沖區溢出可能會使應用程序崩潰，但假定出現設計完善的惡意 負載，可能不會出現應用程序崩潰，攻擊者可能會按照他的意願運行代碼。在這一點上我們的格言是 “今天拒絕服務就是明天代碼的執行”。
偶然的運氣或模糊化處理幾乎可以找出所有 文件解析錯誤/漏洞。Microsoft 對 XLS、PPT、DOC 和 BMP 等多種文件格式進行了解析，並發現了多個 安全漏洞。大多數供應商都存在類似的漏洞，因為對復雜的數據結構進行解析是一項非常復雜的任務，復 雜的代碼會存在錯誤，其中一些錯誤會暴露出安全漏洞。
您必須對解析文件和網絡流量的所有代 碼進行模糊處理。Microsoft 的安全開發生命周期 (SDL) 中就此對文件格式有何意義有非常具體的介紹 。您必須利用一個文件模糊處理程序，通過對不正確文件的 100,000 次迭代對所有解析器進行模糊處理 。目前有一些比較好的模糊處理程序，在我和 Steve Lipner 合著的“安全開發生命周期”一 書 (microsoft.com/MSPress/books/8753.asp) 中，我們提供了一個文件模糊處理程序及 C++ 源代碼。
關於模糊化處理還需要注意一點。如果出現了崩潰，不要認為這只是崩潰。這些所謂的崩潰中有 很大一部分都是在請求某人編寫漏洞。因此不要簡單地將一次崩潰認定為“只是一次崩潰”。
習慣 6：不要編寫不安全的代碼
在 Microsoft，我們使用質量把關的概念來幫助降低開發 人員使存在漏洞的代碼流入產品的可能性。質量把關是在代碼上運行一組源代碼分析工具，然後進行登記 ，對所有問題進行標記。所有發現的問題必須在登記完成前修復。您還可以執行嚴格的代碼規則，如阻止 對禁用功能的使用，如不能調用 strcpy 或 strncat，不允許無用的加密。（Microsoft 已經禁用了超過 100 個針對新代碼的 C runtime 函數！）例如，就加密算法而言，我們不允許在新代碼中使用 DES（密 鑰長度太短）、MD4 或 MD5（它們目前都已被破解），除非行業標准中規定使用這些算法。
不要 重新發明功能。如果您具備對特定文件格式進行解析的代碼，那麼您無需兩套或三套解析代碼；只需一套 解析代碼即可，使其功能足夠強大並將其捆綁在一個可在多個項目之間使用的窗體中。
最後，請 記住，工具不能取代人來了解如何編寫安全代碼。這就是安全和隱私教育為何如此重要的原因。您需要全 面深入的了解這些概念，對您的工具無法進行的調用和洞察做出判斷。
習慣 7：識別策略不對稱
這是我最喜歡的一種習慣。記住，作為一名軟件開發人員，安全方面的隱患會對您不利。我喜歡 稱之為“攻擊者的優勢和防御者的尴尬”您需要確保代碼和設計在 100% 的時間內 100% 准確 ，這是不可能的。更糟糕的是，您還必須在固定的預算內達到這一無法實現的目標，同時還必須考慮到可 支持性、兼容性、可訪問性和其他“能力”的要求。攻擊者會用足夠長的時間來找出錯誤，然 後向全世界宣布您的應用程序是不安全的。
在習慣 6 中，我曾經提到，您應該停止編寫新的不安 全代碼。對於習慣 7，您應該關注所有代碼，因為攻擊者會攻擊所有代碼，無論是哪個時期的代碼。花些 時間查看舊代碼，找出安全漏洞，並認真考慮受到貶低的舊的不安全功能。如果您使用的是靈活的開發方 法，那麼您應該考慮派一名或多名專業人員修復舊代碼，使其質量與新代碼持平。
習慣 8：盡可 能使用最佳工具
最後，盡可能使用最佳工具。我喜歡源代碼分析工具，並且喜歡所有能夠幫助我 編寫出更安全代碼的技術。正如我提到的，工具並非萬能的，但它們會有所幫助。會有很大幫助！工具還 可以幫助衡量源代碼分析得出的問題。工具可以快速掃描大量代碼，比人工速度要快得多。而且，這還可 以使您感覺到某些代碼有多麼“差”。
我喜歡的一種技巧就是使用可能的最高警告級 別編譯代碼，例如在使用 Visual C++® 時使用 /W4 警告級別，或者在使用 gcc 時使用 –Wall 警告級別。如果您在代碼中發現了大量警告，那麼可能該代碼還存在編譯程序或其他工具沒 有發現的其他錯誤。對於這種代碼，在提供代碼前應該對其進行更詳細的安全檢查（參見習慣 3）。
我發現我所尊敬的 Microsoft 內部和外部的開發人員具備了這八種良好的習慣。這些習慣本身不 會使您成為一流的安全開發人員，但它們肯定會對您有所幫助！
