自上而下做好安全程式碼審查

　　安全的程式開發實踐的一個關鍵方面就是安全程式碼審查。安全程式碼審查，與常規的程式碼審查一樣，可以使用自動化工具完成，也可以要求開發者親自參與到程式碼審查中人工完成。那麼，安全程式碼審查與常規的程式碼審查有哪些差別、如何做到更有效的安全程式碼審查呢？大家可以通過本文了解一下。

 

　　安全程式碼審查：對安全知識要求高

　　常規的程式程式碼審查需要程式碼審查者具備業務、程式語言和相關技術知識的積累，安全程式碼審查則需要具備以下 3 個不同方面的安全知識：

• 常見威脅（可以前往 STRIDE 瞭解此類威脅）
• 安全漏洞（OWASP 描述了 10 種最常見的安全漏洞）
• 常見的程式修復技術

　　讓安全程式碼審查更有效：自上而下

　　要做到有效的安全程式碼審查，方式之一就是採用自上而下的方法，此方法要求程式碼審查者瞭解用例細節且對此有比較深入地掌握。進行安全程式碼審查，建議你按照下面的步驟進行。

　　1，瞭解待審查程式碼的用例細節

　　2，分解用例

　　以下面形式分解用例，該種分解屬於資料流圖（DFD）式威脅模型：

• 角色（Actor，外部實體）
• 資料流
• 應用程式/模組
• 資料儲存

　　3，識別威脅

　　STRIDE 可用來識別對上述元素的威脅。STRIDE，是“假冒身份、篡改資料、否認、資訊洩露、拒絕服務和許可權提升”英文單詞的縮寫（對應的英文為 Spoofing Identity、Tampering Data、Repudiation、Information Disclosure、Denial of Service 與 Elevation of Privelege)。比如，角色（Actor）可能會受到來自“假冒身份”和“否認”的威脅；資料流可能會受到“篡改資料”、“資訊洩露”和“拒絕服務”等方式的威脅等。

　　4，檢查安全漏洞

　　一旦威脅與全部元素髮生了關係，則需檢查潛在的可能轉變為攻擊的安全漏洞。如，SQL 注入，會話處理，已破壞的驗證與授權等。可以檢視文章  OWASP Top 10 瞭解常見的 10 種安全漏洞。

　　5，做好補救控制

　　一旦確認安全漏洞，則需檢查補救控制措施是否到位或針對這些漏洞的措施是否恰當。這些補救控制措施通常就是更為安全的程式碼。可以在OWASP Top 10 每個單獨連結頁檢視相應的補救控制措施建議。

　　下面針對部分威脅和安全漏洞給出了對應的補救控制建議：

• SQL 注入攻擊：在查詢相關的程式碼中搜尋引數化 API（parametrized API）的使用情況。同時，也要請求一個或多個輸入驗證架構，如 OWASP ESAPI 用在轉義可能帶來注入攻擊的字元的情況。
• 跨站點指令碼攻擊（XSS）：搜尋基於 HTML 上下文（主體、屬性、JavaScript、CSS或URL）用於轉義全部不受信任資料的程式碼。可以檢視 OWASP 跨站點指令碼攻擊備忘瞭解資料轉義技術細節。
• 敏感資料曝光：查詢敏感資料並檢查該類資料的儲存策略。可以從程式碼角度來檢查資料的加密強度。
• 功能級許可權控制缺失：在程式碼審查時，要確認何人具備訪問該功能的授權、是否根據使用者型別賦予了其合理的許可權控制。在控制元件或業務邏輯中，資料集有時僅能由特定型別的使用者進行訪問。

　　結語

　　目前，對部分開發者來說，可能還需要一定程度的安全培訓才能勝任安全程式碼審查工作、實現有效的安全程式碼審查。程式碼的常規審查不可少，安全審查也不可少，對安全性要求較高的程式尤其要注意。如果缺少了這道流程，萬一遭受攻擊，帶來的損失將遠超過我們的想象，“預則立，不預則廢”說的就是這個道理。

　　英文原文：Security Code Review Tips for Application Developers