在 OWASP（Open Web Application Security Project）2015 年的年報中，SQL注入和跨站點腳本再次被列入Top 10軟件隱患。
你是否覺得過去十年一直一成不變，從表面上也可以這么看。那么，為什么我們能夠建造智能機器人，將無人機發射至太空，甚至創造出能夠識別自然語言并能在智力競答節目中擊敗人類的計算機，但卻一直沒有解決這些軟件隱患？
安全公司 Cigital 首席技術官 John Steven 曾這樣說道：修補這些漏洞使得“我們正處于并厭煩于一個倉鼠轉輪的痛苦之中”。Rogue Wave 的首席技術官 Rode Cope 也深表贊同：「你也許會覺得 15 年過后這將不再是個問題。但是 OWASP 的前十榜單似乎每年都一模一樣。」
Gartner 的前沿應用安全分析專家 Joseph Feiman 說：「開發者將會繼續寫出不安全的代碼，而對此他們自己也無能為力。面對黑客，這是一場注定失敗的戰爭。」
現在的軟件生命周期與二十年前的相比已經大不相同，那時候你只需要開發軟件然后放在防火墻后面運行，在接下來六個月到一年（或者更久），新的軟件版本開發出來之前你完全不用對它做出任何改變。測試機構 Bugcrowd 的 CTO Chris Raethke 指出，時下軟件應用都是基于部件橫向開發出來的。「所有的應用都是因特網的碎片。」他說道，「且依賴于微服務（microservice）和面向服務的架構。」
Raethke 更進一步說到，因為版本發行時間的存在，開發者必須爭分奪秒，產品特點和更新更多由公司內非技術人員引導。他如實說到：「你不能期待某種魔法能夠變出機構想要的安全、可擴展且萬能的應用」。
安全，誰之責？
長久以來，安全倡議者都認為代碼的安全性由開發者決定。其他人則堅持認為相對于安全專業人員來說，開發者由于不專攻系統漏洞因此對漏洞的最新進展知之甚少。
「底線在于，我們不能讓開發者去做這件事，」Cope 補充道，「這不是一個復選框，而是整個開發過程中至關重要的一部分。」
對于開發者來說在代碼階段保證安全就是一個魔咒。相對于保證軟件的抗攻擊性，他們對開發出酷炫的功能更有興趣。Cope 說開發者并不覺得代碼安全工作有趣，他們總是這樣對自己說：「我不會因為寫出安全的代碼而出名。只有開發出酷炫的新功能才能讓我揚名，或者因為遭受攻擊而因此被責備。但是除了避免更多的痛苦意外并沒有其他更好的辦法。」
Cope 還提到開發機構面對的另外一個大問題是，新人入職時對代碼里的脆弱性并不了解。他表示：「總會有新的開發人員不斷加入，因此已經在幾年前遇到攻擊問題的人會知道避免 SQL 注入的問題或緩存溢出，而剛入職的新人可能現在正維護著他的代碼。」
「但那些剛離開學校，或是剛使用新語言開始寫代碼的人不知道那些漏洞具體長什么樣，而他們正學習這些新代碼。在過去十五年內不斷犯錯的人并不是同一個人，而是一些新手正重新制造這些漏洞。」
遠遠不止不明白他們寫出的代碼，開發者加入一個正在進行中的項目還需要了解 Gemalto 產品經理 Todd Steel 所說的操作環境的邊界性。開發者的安全測試「更多的是數據分析和問題解決，遠不是理解系統框架和該框架的局限性。」
但是 Steel 同時又堅決地相信「了解（系統）環境和漏洞是開發者義不容辭的責任。」
在傳統意義上，開發者寫代碼，執行功能和回歸測試，制造出堅固的架構。然后，QA （質量保證）組保證其正常工作。Cope 指出，軟件安全測試則是另外一回事。他認為應該有安全專家來確定軟件易被攻擊的地方，而不僅僅是確定它能正常運行而已。而這些技能常常是開發者沒有學過因而不具有的。
Steven 說 code hygiene 總會有問題出現。「作為測試者的我們有點像牙醫，當我們去看牙醫時他會問「每次就餐后你都刷牙了嗎？」我們會說「沒有，我吃的是商務餐，沒法刷牙」衛生是不可能的。要求開發者在寫每行代碼時注意 code hygiene 是不可能的。」
新方案的到來
自從軟件在很多高調且有破壞性的情形中崩潰，在撰寫此文我們訪問的專家都認為已經到了重估軟件安全的時間，解決措施是使用自動工具甚至是開發一種全新的能夠使應用保護自己免受攻擊的辦法。
「有些事情簡潔明了，如密碼存儲，我們知道怎樣做才是正確的但是對一般的開發者來說卻異常痛苦，」 Steven 解釋道，「我們能夠向他們展示一次。在公司里我們能夠教他們寫一次代碼，而他們再次使用時還是會忘記…安全 API 的概念，對嗎？」
「然后還有很多 hygienic 問題，」他繼續說道，「例如之前我們已經討論到的注入問題缺陷，沒有任何測試或單一控制能解決這個問題。因此我們需要同等的 hygienic 程序，而它們擁有不同的庫和框架。如果使用不同的工具應付軟件漏洞，那么開發者就不可能陷入這個泥淖。」
Cope 認為不能指望開發者手動解決安全問題。「這不會發生，」他說，「對他們來說這太冗長乏味了。」
「因此開發周期必須囊括這個重要必不可少的步驟而不僅僅是某項檢查框。就如你快速寫出代碼需要后續的可行性測試，包括單元測試，功能測試等等，我認為安全測試應該被提升到同等的首要位置上來。」
「第二點」他繼續說道，「就是你必須實現自動化。不管是第一次還是后續檢測你都不可能手動把它做好。代碼審查是很好，但是并不是每行代碼都會被仔細地檢查。開發者也是人……他們也會覺得累，會覺得餓，寫出的代碼永遠不會是完美的。你需要相關的工具能幫忙時刻盯著，某個開關是否正確，是否重要等等，一些小工具能夠閱讀代碼并檢查安全錯誤。這兩者需要結合一致，不能指望開發者在沒有任何外界的幫助因素下就能解決所有問題。管理層必須提高視野高度。」
Gartner 公司的 Feiman 有一個全新的方法。「如果我們不能或很好地檢測所有的應用，我只看到一個解決辦法：應用軟件自我測試，」他說，「我們做不到對所有應用都進行分析，這就是為什么 Apps 必須自我檢測。而且因為利用現有的方法（ firewalls、IPSes、IDSes、Web application firewalls、encryption ）我們無法保護所有的應用，唯一的解決辦法就是軟件應用必須實現自我保護。”
軟件安全就是一個難惹的毛球。如 Feiman 指出的那樣「軟件安全是最近才出現在應用安全大家庭之中的。其中身份管理問題，45 年；網絡防護，30 年；端點問題：25 年。我們看到的這些攻擊都十分普遍而且很成功，我們無法阻止它們，這讓我們感到絕望。」
「但是網絡銷售商仍舊不斷出售它們……甚至推送它們，不僅僅是銷售它們。防火墻經銷商也一樣。端點保護也是如此。他們不斷添加著新的特性，這里改一改那里修一修，然后說現在的產品更好了，效果更佳了。而由于我們并不知道詳情，我們會照單全收。這就像在青霉素出現以前他們會推薦使用草藥，而你使用它們是因為市場上沒有更好的選擇了。我想說的是，這和四年前我們剛從事這個研究時所問的問題出現的巨大的反差，那時候我們說「怎么會，如果我們都認為應用（ app ）是最重要的財產（應用以及它處理的數據），那么它怎么會是完全軟弱的呢？它不能自我檢查，不能自我保護，這怎么會呢？」」
因此，Feiman 想出了運行時應用軟件保護（ Runtime Application Software Protection (RASP) ）的概念。他同時也警告道：「我們給了身份驗證管理 45 年的進化時間。而 45 年過后，這仍然不夠。我們給網絡安全 30 年的進化時間，結果也是沒有起到作用。那么在最后，我們給了端點防護 25 年的進化時間，而現在仍有它不能抵御的病毒。」
「所有的技術都擁有復雜的執行部件，而 RASP 現在還處于萌芽發展時期，但是一些有名的世界組織正在使用由企業收購的生產執行部件，以保護它們的財產。」
由 Bugcrowd 公司的 Raethke 提出的另外一種方法則是創造一支由各個部門代表組成的能夠在企業內部捍衛變革的「fire team 」。「一兩個工程師，一個生產人員、安全人員、管理人員，以及一兩個銷售部門人員代表和市場部員工代表，」他說。這樣的話，任何關于產品的反饋都會傳達到所有團隊，這個方法對改變運行操作十分高效。「這給所有的人都提供了參與的機會。」
Raethke 認為跨組織規則之間的交流是關鍵所在。「任何向組織內部推廣的措施（包括安全）都必須是可持續的。」他建議在開始階段納入兩名開發者和兩名操作團隊成員，在共同性確定之后再帶入銷售，市場和行政部門的人員。
未完待續...
如今，多樣化的攻擊手段層出不窮，傳統安全解決方案越來越難以應對網絡安全攻擊。OneRASP 實時應用自我保護技術,可以為軟件產品提供精準的實時保護，使其免受漏洞所累。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客
