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