摘要
對互聯網行業而言，安全總是后知后覺！只有遭受損失時才想辦法去彌補。互聯網的歷史就非常清楚的驗證這個理論，早在1969年美國軍方就發明了互聯網命名為「Arpanet」，1973年 Arpanet 發明了 TCP/IP 協議，隨后在1981年發明了一系列的應用協議如「SMTP，POP3，FTP，TELNET 」等等，在1991年，就發明了 HTTP 協議。
這一系列的應用協議都是采用明文傳輸的，沒有進行任何加密措施，在當時如何將世界各地的人聯系在一起和增加新的功能才是最高優先級。黑客非常容易就可以截取傳輸的內容，在經過非常慘痛的損失后才出現了加密傳輸協議「FTPS，SMTPS，SSH 以及 HTTPS」。假如互聯網在在設計之初就對安全進行很好的的設計，就不會出現現在這么多安全問題了。
同樣的情況發生在軟件開發過程，安全開發的優先級永遠低于功能的開發，都是在開發后期才考慮安全問題。本文主要討論如何開發安全軟件以及探討為什么 SDLC (系統開發生命周期)是開發安全軟件的最理想模型。
該模型引出 「安全設計」和「深度防御」的方案，安全開發應該是 SDLC 過程的一個非常重要的組成部分，應該在軟件開發和測試的每個過程將安全完整的進去，越早期修復安全漏洞所花費的成本，時間和代價都是最低的。
應用層安全攻擊
隨著時間的流逝，網絡攻擊不斷沿著 OSI 協議模型往上移動的趨勢越來越明顯，大多數攻擊集中在應用層，在80、90年代的大多數攻擊集中在 OSI 模型的1層，2層和3層，?現在網絡層的防護已經非常出色了，但是應用層安全仍然是一個很大的挑戰。
根據 Gartner 的研究報告，指出今天75%的攻擊發生在 OSI 模型的應用層。根據 Trustwave 公司的一項調查顯示，82%的 Web 應用程序容易受到 XSS 攻擊。根據另一項調查，金融領域80%的安全事故是由于跨網站腳本攻擊導致的。因此，應用層的防御是不可或缺的。
應用層防護方案
現在市面主要有兩種應用層安全防護方案，一種是應用安全防火墻（WAF），另外一種是運行時應用程序自我保護（RASP）。
WAF 可以做為一種額外應用程序保護層，但是所有 WAF 基本上是基于一個「黑名單」來判斷輸入是否為攻擊，黑名單就是把所有已知的 Web 攻擊行為歸納起來形成一個黑名單，但是相對于黑名單來說只允許有限的合法輸入的白名單更有效，但是由于應用程序是非常動態的，形成白名單是非常不現實的。但是基于黑名單的保護防護方式效果不是太好，現在有太多的繞過防火墻的方式了。繞過防火墻對一般黑客都不是特別麻煩的事情。極端一點來說 WAF 可以說是形同虛設了。
運行應用程序自我保護（RASP）是防止應用層的攻擊一種新方法，在運行時保護應用程序面試攻擊。RASP 保護程序位于應用程序等應用程序與數據庫、文件系統和網絡的連接點上，識別和阻擋任何惡意活動，使應用程序能夠保護自己。相對應WAF來說，RASP 熟悉應用程序的上下文，可以非常精確的識別攻擊，能關鍵點保護程序，黑客基本不可以繞過，可以自適應云環境，這些都是 WAF 沒法比的。雖然從長遠來看 RASP 是應用安全防護領域的趨勢，但是目前大部分 RASP 還是基于黑名單保護的基礎上，技術上還沒有完全成熟，同時和應用程序綁定在一起，保護代碼的質量直接影響應用程序，同時在性能上也也有一定的影響。
雖然應用程序保護方案在一定程度上能防護網絡攻擊，但是作為底線，你不能寫一個充滿漏洞的程序然后依賴安全保護系統來保護。
安全的 SDLC 流程
上面講到的安全防護措施的確能起到一定的保護作用，但是絕不是最好的辦法，最好的辦法就是讓應用程序能真正的自己保護自己，盡可能少的漏洞。要做到這一點就需要從程序設計的初始階段把安全考慮將來并且將安全嵌入到SDLC 即需求收集、設計、開發、測試以及實施的各個階段。
下面筆者就詳細討論在 SDLC 各個階段需要做哪些方面的安全工作。
需求分析
SDLC 的第一階段是需求分析，在這個階段確定整個項目的范圍和目標，OWASP 組織推薦在需求分析時也應該把安全的需求和目標確定下來，客戶的需求也應該依據相應的安全標準比如密碼策略，安全網絡協議等進行明確，使之符合安全標準。
設計階段
在設計階段：設計人員應該樹立良好的安全意識，清楚現有的安全模型有哪些，應用程序可能面臨哪些安全威脅，攻擊途徑可能有哪些，實施哪些安全策略和計劃會緩解安全攻擊的危害性，以及如何去實施這些安全測試。
這段視頻非常清楚的介紹了安全模型方面的知識：
https://youtu.be/ZtSrcq7gscE， 能翻墻英文好的同學可以學些一下。
開發階段
寫出安全代碼首先需要制定安全代碼規范，各種語言都有現成的代碼安全規范，企業可以根據自己的情況進行適當修改。同時要對項目中所有的開發人員培訓安全編碼規范，確保每個人能夠完全明白如何編寫安全的代碼。最重要的一步就是要確保每行代碼都符合安全規范，每個開發提交代碼前都應該由安全專業人員對代碼進行安全審查，確保代碼的安全性，審查員非常關鍵可以是公司內部的資深安全人士，也可以聘請第三方專業人士（這種 Review 可能更客觀一些）。
測試階段
測試階段應該進行大規模的滲透測試，使用靜態 SAST 和動態（DAST）以及 IAST 進行漏洞掃描，驗證所有已知的漏洞是否已經在設計和開發過程以及被修復。必須對所有模塊進行徹底的掃描，條件允許的話可以使用多個掃描工具進行，因為每個掃描工具范圍不完全一致。這樣就可以最大限度的將漏洞消除在發布前。
還有特別需要注意的是應用程序本身邏輯的 Bug，程序是多種多樣的，每個應用程序的功能邏輯是不一樣的，這方面的 Bug 如果在設計和開發階段做的足夠好的話應該不會有太多 bug，同時通過功能和系統測試可以消除這方面的 Bug。
部署
在確保沒有漏洞后，將系統部署到生產環境，在部署過程中應該遵守安全部署，不講新的漏洞帶入到生產環境。部署完成后再使用漏洞掃描工具進行掃描，確保沒有漏洞發現。同時要確保環境配置和環境是安全的，比如 Tomcat 等容器有相應的安全配置，操作系統，容器以及使用的第三方軟件保持最新的狀態。
后語：
坦率地講，這是一個比較理想的開發模式，真正能完全執行的項目很少，各種因素都會導致重功能而輕安全的情況比如：開發周期快，上線壓力大，人員素質無法滿足，安全資源缺乏等等。但是在這里我還是呼吁所有的軟件提供商重視安全，早期安全投資一塊錢，收獲將是100塊。
在的確沒有能力去實施 SDLC 的企業，上面提到的 RASP 技術是退而求其次的選擇，它在一定程度充當一個虛擬補丁的作用，可以暫時修復應用程序和第三方程序的漏洞，使用 RASP 可以讓企業可以將不安全的程序上線后大幅度緩解安全攻擊，具備一定自我保護的能力。
本文系 OneRASP 安全總監劉再耀原創文章。如今，多樣化的攻擊手段層出不窮，傳統安全解決方案越來越難以應對網絡安全攻擊。OneRASP 實時應用自我保護技術，可以為軟件產品提供精準的實時保護，使其免受漏洞所累。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客
