第三方組件的安全剖析
一、Apache Struts2再曝高危漏洞
前段時間，Apache Struts2又接連曝出了兩個高危遠程代碼執行(Remoce Code Execution，下文簡稱RCE)漏洞(CVE-2017-5638)。為什么要說“又”呢?那是因為這早就不是Apache Struts2第一次曝出這類漏洞了。
你應該還有印象，早幾年前Apache Struts2披露了一系列RCE漏洞，而且他們家在披露RCE漏洞的同時還附帶了證明漏洞存在的POC(Proof Of Concept)腳本。在那次事件中，由于POC包含的信息量太大，其本意可能是想方便開發者了解更多漏洞細節，但未曾想卻為黑客攻擊提供了重要線索，不得不讓人覺得是“神助攻”。再加上，這種做法幾乎就沒給使用Struts2的開發團隊留出進行修復的時間，以至于在短時間里，國內外眾多使用Struts2的網站，包括一些知名網站均遭到黑客攻擊，大量網站紛紛表示躺槍。
二、前端JS框架、庫的安全性同樣令人擔憂
如果說現如今Struts2在新開發的應用中的使用量小到幾乎可以忽略不計，它的安全漏洞所帶來的影響有限，那么當下火爆的各種前端JavaScript開發框架、庫當中也存在安全漏洞這一事實卻讓情況變得不容樂觀。
早在2014年，當時的一份調查研究發現，在Alexa排名前10萬的網站中，有60%的網站使用了至少含有一個已知安全漏洞的JavaScript庫。時間來到2017年，美國波斯頓Northeastern University做了一次跟進調查，發現Alexa排名前13萬的網站中，有37%的網站使用了至少含有一個已知安全漏洞的JavaScript庫。
三、挑戰
使用含有已知安全漏洞的第三方組件的現象為何會如此普遍呢?原因是多方面的，比如，在采用第三方組件的時候沒有對其進行安全檢查，或者最初該組件并沒有安全漏洞，只是隨著時間推移，一段時間后被發現存在安全問題并披露了出來，等等。要想扭轉這一局面，開發團隊卻也面臨著不小的挑戰。
1. 挑戰一：第三方組件及其版本號眾多，需要快速確認哪些存在已知安全漏洞，是否受到漏洞披露的影響
無論是服務器端應用還是運行在瀏覽器里的前端應用，使用幾十個第三方組件、庫是稀疏平常的事情，更何況這還只是直接依賴的第三方組件，要是算上間接依賴(即第三方組件所依賴的第三方組件，以此類推)的話，組成一個應用的第三方組件數量將會相當可觀。
在知道應用所使用的所有第三方組件之后，還需要知道各個組件的精確版本號，然后才能將組件、版本號在已知漏洞數據庫里進行匹配查詢，得出最后的結果。
讓問題變得更加棘手的是，一個企業里往往有不止一個應用系統，而每個系統都需要定期或者不定期的做這樣的排查，所需要的工作量有多么巨大可想而知。
2. 挑戰二：和時間賽跑，需要在第一時間內得到通知，以最短時間完成修復和測試，并發布到生產環境
應用在還未發布時如果遇到這類問題，開發團隊有充足的時間來做出應對，但對于已經處于運營中的應用而言，時間就是生命線，這是一場和黑客爭分奪秒的戰爭，如果不能趕在黑客進行攻擊前完成修復、發布等一系列任務，那就只能祝你好運了。
3. 挑戰三：對企業持續交付能力是個考驗
在第三方組件的提供商披露安全漏洞的同時，還會給出修復建議，而通常的情況是，開發團隊只需要將受到影響的第三方組件升級到新版本即可。看上去這似乎一點不難，但卻細思極恐。
第一，版本升級可能會帶來兼容性問題，導致應用無法正常啟動、使用等。解決兼容性問題就可能得花去不少時間。
第二，邁過了兼容性這一關，開發團隊還得對應用進行回歸測試，以確保版本升級沒有破壞原有的業務功能。那么問題來了，你的團隊需要花多少時間進行這一測試呢?幾分鐘?幾小時?還是幾天甚至幾周?
第三，開發團隊排除重重困難，避開了兼容性問題，完成了回歸測試，終于走到了發布修復這一步。此時，你的團隊是否能對應用進行藍綠部署、滾動發布以保證生產環境業務不會因為部署而中斷?
四、解決之道
1. 創建和維護第三方組件信息庫
開發團隊可以將應用中所使用到的所有第三方組件，包括那些間接依賴的第三方組件，及其版本號集中收集起來，形成一個組件信息庫。于是，每當有第三方組件安全漏洞信息披露出來的時候，開發團隊都可以立即做出判斷，了解自己的應用是否受此次漏洞披露的影響。
2. 定期匹配排查
除了在得到第三方組件安全漏洞的信息披露通知后進行識別判斷，開發團隊還非常有必要主動的對所用到的組件進行定期安全檢查。因為在上一步中已經識別出了所有的第三方組件及其版本號，開發團隊接下來需要做的，是將這些信息在已知安全漏洞數據庫(例如National Vulnerability Database)中進行匹配。
3. 自動化
剛才已經提到，識別第三方組件及其版本號，并且還要對其進行細致的匹配排查，工作量是非常巨大的，如果沒有自動化的幫助，僅僅依靠人工的話，幾乎是不可能完成的任務。
幸運的是，目前已經有不少工具能幫我們完成這一工作，例如兩次入選ThoughtWorks技術雷達的OWASP Dependency Check，它能自動完成第三方組件識別、漏洞數據庫維護，以及漏洞匹配、生成檢查報告等一些列活動。除了支持Java和.Net應用外，還支持Ruby、NodeJS以及Python應用，以及部分C/C++應用。
同類型的工具還有支持.NET的OWASP SafeNuGet，專門針對Node應用的Node Security Project等等。對于其他語言，也有各自對應的自動化檢查工具，在此就不一一列舉了。
4. 貫穿整個生命周期
在應用開發過程中，第三方組件可能會不斷的被加入到項目里，或者移除出去，其版本也可能會隨著時間的推移而不斷更改。在這個過程中，組件的的每一次變化都可能會帶來新的安全隱患。
開發團隊可以利用上一步提到的自動化檢查工具，并將其和CI服務器集成起來，可以很容易做到在每次代碼提交的時候進行一次安全檢查，從而達到持續監控組件安全性的目標。
五、總結
應用往往使用了大量第三方組件，它們可能含有安全漏洞，給應用的整體安全性埋下隱患。開發團隊和黑客一直都在進行時間競賽，其必須要在第一時間內得到安全漏洞的披露通知，趕在黑客發動攻擊之前，完成漏洞修復工作。
好在開發團隊可以利用各種自動化工具，快速且全面的發現那些有問題的第三方組件，通過運行回歸測試以確保原有業務行為的正確性，并且結合持續交付的能力，在不影響生產環境業務持續運行的情況下，將代碼改動發布到生成環境，及時避免第三方組件安全漏洞給應用帶來安全風險。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
