自上而下做好安全代碼審查
英文原文：Security Code Review Tips for Application Developers
安全的程序開發實踐的一個關鍵方面就是安全代碼審查。安全代碼審查，與常規的代碼審查一樣，可以使用自動化工具完成，也可以要求開發者親自參與 到代碼審查中人工完成。那么，安全代碼審查與常規的代碼審查有哪些差別、如何做到更有效的安全代碼審查呢？大家可以通過本文了解一下。
安全代碼審查：對安全知識要求高
常規的程序代碼審查需要代碼審查者具備業務、程序語言和相關技術知識的積累，安全代碼審查則需要具備以下 3 個不同方面的安全知識：
- 常見威脅（可以前往 STRIDE 了解此類威脅）
- 安全漏洞（OWASP 描述了 10 種最常見的安全漏洞）
- 常見的程序修復技術 </ul>
- 角色（Actor，外部實體）
- 數據流
- 應用程序/模塊
- 數據存儲 </ul>
- SQL 注入攻擊：在查詢相關的代碼中搜索參數化 API（parametrized API）的使用情況。同時，也要請求一個或多個輸入驗證架構，如 OWASP ESAPI 用在轉義可能帶來注入攻擊的字符的情況。
- 跨站點腳本攻擊（XSS）：搜索基于 HTML 上下文（主體、屬性、JavaScript、CSS 或 URL）用于轉義全部不受信任數據的代碼。可以查看 OWASP 跨站點腳本攻擊備忘了解數據轉義技術細節。
- 敏感數據曝光：查詢敏感數據并檢查該類數據的存儲策略。可以從代碼角度來檢查數據的加密強度。
- 功能級權限控制缺失：在代碼審查時，要確認何人具備訪問該功能的授權、是否根據用戶類型賦予了其合理的權限控制。在控件或業務邏輯中，數據集有時僅能由特定類型的用戶進行訪問。 </ul>
讓安全代碼審查更有效：自上而下
要做到有效的安全代碼審查，方式之一就是采用自上而下的方法，此方法要求代碼審查者了解用例細節且對此有比較深入地掌握。進行安全代碼審查，建議你按照下面的步驟進行。
1，了解待審查代碼的用例細節
2，分解用例
以下面形式分解用例，該種分解屬于數據流圖（DFD）式威脅模型：
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 每個單獨鏈接頁查看相應的補救控制措施建議。
下面針對部分威脅和安全漏洞給出了對應的補救控制建議：
結語
目前，對部分開發者來說，可能還需要一定程度的安全培訓才能勝任安全代碼審查工作、實現有效的安全代碼審查。代碼的常規審查不可少，安全審查也 不可少，對安全性要求較高的程序尤其要注意。如果缺少了這道流程，萬一遭受攻擊，帶來的損失將遠超過我們的想象，“預則立，不預則廢”說的就是這個道理。
Via Vitalflux
<span id="shareA4" class="fl"> </span>