在《安全編碼有章可循（一）》一文中為大家講述了在做好安全軟件開發的準備之后，開發團隊還需要清楚安全編碼的原則的一部分，例如：保持代碼清潔，確保可以向前和向后追溯源代碼等。本文中將繼續為您介紹更多安全編碼原則，讓我們一起來看看吧。

避免本地和非本地代碼、被動代碼和動態代碼之間的安全沖突

應用程序常常依賴于用另一種編程語言編寫的代碼，或者在應用程序初期開發完成之后，還要使用另外一種編程語言進行后期處理。例如，有些非本地的JAVA應用程序可能會依賴本地的C代碼來處理與硬件的接口。這是一個潛在的漏洞，因為即使JAVA代碼部分并不易于遭受攻擊，攻擊者也有可能會對本地代碼執行緩沖區的溢出攻擊。

再舉另一個例子，AJAX應用程序為了執行某項操作，有可能支持Web瀏覽器動態生成的JavaScript。因而，動態生成的代碼有可能在原始的應用程序開發完成之后，再開發動態生成的代碼。此時，如果動態生成的代碼做出了關于應用程序環境和狀態的不同假設，這就會導致AJAX應用程序的非法輸入驗證。

在這兩種情形中，應用程序將本地代碼和動態代碼當作是潛在的不可信的實體，這一點是很關鍵的。另外，開發人員對發送給不可信代碼、來自不可信代碼的數據進行驗證也是至關重要的。

編碼期間和日后的檢查

安全代碼檢查的主要目的是發現安全缺陷并確認可能的修復手段。測試報告應當提供關于軟件可能的漏洞點的足夠詳細信息，使其開發者能夠根據這些漏洞被黑客利用的可能性進行分類，并區分其優先順序。應用指南應當包含在檢查代碼時應當考慮的問題清單。這會確保被檢查的代碼符合確定的標準，而不會受到檢查者偏好的影響。

代碼的安全檢查的一些技巧：

何時檢查：應當在軟件的單元或模塊水平上就進行代碼的安全檢查。在將軟件的不同單元或模塊提交進行編譯和鏈接之前，程序員還應當檢查軟件單元或模塊之間的接口缺陷。應當盡早并經常地在軟件的生命周期進行源代碼的分析和白盒測試。最有效的白盒測試是在個別模塊或在功能性的進程單元水平上進行的，這種測試可以在將模塊添加到更大的代碼庫之前相對輕松、快速地糾正發現的問題。全面的系統代碼檢查應當著重于不同組件之間的關系和接口上。

同行檢查：程序員應當樂于請其它程序員檢查自己的代碼，因為程序員容易遺漏自己所犯的錯誤。

工具的使用：可以用靜態、動態、二進制分析工具來發現常見的漏洞。例如微軟就提供了FxCop的免費下載，這是一個靜態的分析工具。此外，還有 BinScope Binary Analyzer、Mini-Fuzz File Fuzzer 。不過，這些工具可以產生大量的似是而非的信息，因而應當結合人工檢查使用，切不可用它完全替代人工檢查。

代碼檢查者的能力：只有檢查者洞悉安全問題時，人工檢查才會有用。至少代碼檢查者應當清楚軟件編碼所用語言的漏洞及解決漏洞的方法，還要熟悉數據庫、Web應用程序、加密技術等。

充分利用測試案例：程序員應當創建一些一般的測試案例。測試應當有助于指出明顯的程序漏洞，它還應當是一個測試誤用情況的機會。

威脅模型的檢查：安全代碼的檢查應當包括檢查威脅模型的文檔，確保所識別的威脅在發布代碼前能夠被正確地處理。

遵循標準：安全的編碼檢查應當確保遵循所有的編碼標準，其中包括使用安全的函數庫，并排除被廢止的函數。

此外，在安全的編碼檢查期間應當關注如下問題：

1、所有的組件都應當遵循同樣的框架和確定的編碼風格。

2、查找開發者在代碼中的后門、調試命令、硬編碼憑證、敏感評論、過于詳細的錯誤消息等。這些增加到源代碼中的要素可以使開發人員在測試時更易于調整軟件的狀態。在軟件被編譯并部署之后，這些元素也容易被利用。開發者應當從一開始就避免使用這些元素，除非絕對必要。

3、在軟件系統的執行期間，要查找任何沒有用到的調用和沒有完成任何功能的代碼。因為這些代碼有可能包括會激發環境級別或中間件級別的進程調用，而系統并不要求在目標環境中出現這些進程。

4、還要查找惡意代碼的線索和指示。例如，如果該代碼是用C語言編碼的，那么，檢查者就有可能尋找可以指明漏洞特性的注釋或復雜的、難以跟蹤的代碼部分，或者查找包含嵌入的匯編語言代碼的源代碼。檢查人員應當檢查所有已發現的漏洞，看其是否存在潛在的被利用的機會。可能被利用的漏洞稱為安全漏洞，應當在代碼發布之前就解決這些漏洞。