作者 | Tina、萬佳
無論是前端還是後端，隻要有代碼存在，就會出現漏洞。
最近，有兩幅關于 Vue 安全問題的截圖在業界廣為傳播，截圖内容表明目前有多家公司統計軟體開發過程中使用 Vue.js 和 SonarQube 的情況，疑似有黑客利用 Vue.js和 SonarQube 中的漏洞對大陸境内機關和重要企事業機關實施網絡攻擊探測。
Vue 是一款流行的 JavaScript 前端架構，于 2014 年作為獨立開源開發者尤雨溪的個人項目釋出。時至今日，Vue 已成為 GitHub 上最受歡迎的開源項目之一。同時，在 JavaScript 架構中，Vue 所獲得的星标數已超過 React，并高于 Backbone.js、Angular 2、jQuery 等項目。
前端架構會不會有安全漏洞？
雖然截圖來源不明，但由于 Vue 使用者衆多，于是就有很多開發者将截圖發給了尤雨溪。
1 月 25 日，尤雨溪在知乎上做了公開回應：https://zhuanlan.zhihu.com/p/461720764
他表示 Vue 對于安全問題是很看重的，近期他們也沒有收到漏洞報告，公開的 CVE 資料庫中目前也沒有任何針對 Vue.js 本身的漏洞。Vue 作為開源項目，又是以 JavaScript 源碼形式釋出的前端項目，每一行代碼都公開接受任何安全審計。Vue 2 釋出至今已經 5 年多，在全球業界被廣泛使用，期間從未有被發現過真正意義上的安全漏洞。
同時他解釋道，“黑客滲透可能會利用被攻擊者所使用的前端架構中的漏洞，但黑客不會用前端架構作為其滲透的工具，因為前端架構根本沒有這個功能。”
前端作為在使用者浏覽器裡執行的代碼，漏洞類型通常都是 XSS (Cross-Site Scripting)，XSS 中文叫跨站腳本攻擊，指的是通過上傳惡意資訊，讓資訊中包含的腳本被意外地渲染，進而能夠在其他使用者登陸時執行，竊取其他使用者的資料。XSS 可以以多種形式出現，在純粹服務端渲染的頁面上也可能發生，不一定涉及前端架構。
我們過去私下也接到過一些所謂的 “漏洞” 報告，但這些報告幾乎全部是在假設了将使用者上傳的任意 HTML 内容當作 Vue 模版或是 v-html 資料使用的前提下 —— 這種場景跟直接渲染使用者上傳的任意 HTML 沒有本質差別，不管用的是不是 Vue 都會導緻 XSS，我們文檔裡的安全章節也對這種做法有特别警告。前端架構的職責是根據開發者提供的模版和資料渲染界面，如果開發者強行要求架構渲染不可信的模版然後指責架構不安全，這就如同用 innerHTML 渲染不可信的内容，然後指責浏覽器有安全漏洞一樣。
最後，他特别強調：“隻要遵循普适的前端安全常識，Vue 本身并不存在任何安全性問題。”
對于尤雨溪的回複，大部分網友都表示支援：“前端架構還能有安全漏洞？”、“甩鍋給 Vue 實在是有些牽強”。
但作為一款應用廣泛的開源軟體，使用者有所擔憂也是正常的，特别是在 Log4j 漏洞事件之後。
Apache Log4j 是 Java 開發領域應用非常廣泛的一款開源日志架構。根據谷歌安全團隊的統計，截至 2021 年 12 月 16 日，來自 Maven Central 的 35,863 個可用 Java 元件依賴于 Log4j。這意味着 Maven Central 上超過 8% 的軟體包裡至少有一個版本會受此漏洞影響。
是以，Log4j 漏洞從去年剛剛爆發開始，就因影響範圍大、危險程度高吸引了安全圈所有人的目光，甚至工信部也專門針對 Log4j 漏洞給出了風險提示。比利時國防部也曾在媒體上确認在其網絡上發生了涉及 Log4j 漏洞的網絡攻擊。
1 月 13 日，美國白宮還針對 Log4j 漏洞專門召開開源軟體安全峰會，聚集了谷歌、蘋果、亞馬遜、微軟和其他主要科技組織，包括 Apache 軟體基金會（Log4j 庫的所有者和維護者）、 Oracle（Log4j 庫運作所在的 Java 軟體平台的所有者）、GitHub 和 Linux 開源基金會等等，共同讨論開源軟體的安全性。
開源軟體安全問題不應被忽視
當今，開源軟體已經成為軟體世界的重要組成部分，根據 Gartner 統計，99% 的組織在其 IT 系統中使用了開源軟體。Gartner 還表示，現代軟體大多數是被“組裝”出來的，不是被“開發”出來的。那麼，與企業自主編寫的源代碼相同，開源軟體同樣位于軟體供應鍊的源頭。從源頭到傳遞，每個環節都可能會引入供應鍊安全風險進而遭受攻擊，上遊環節的安全問題會傳遞到下遊環節并被放大。
有些人認為開源軟體處于“衆目睽睽”之下，漏洞問題就不會太嚴重。但實際上，開源軟體的安全缺陷非常密集。奇安信《2021 中國軟體供應鍊安全分析報告》顯示，2020 年全年，奇安信代碼安全實驗室對 1364 個開源軟體源代碼進行了安全缺陷檢測，代碼總量為 124296804 行，共發現安全缺陷 1859129 個，其中高危缺陷 117738 個，整體缺陷密度為 14.96 個 / 千行，高危缺陷密度為 0.95 個 / 千行。并且，開源軟體之間的關聯依賴，導緻開源軟體的漏洞管理非常複雜。
這也意味着在開源軟體中，約每 1000 行代碼裡面就有一個高危軟體缺陷。
在 InfoQ 之前針對開源安全的采訪中，奇安信表示，漏洞實質是“被利用的網絡缺陷”，缺陷是天生的，但并非每個缺陷都會被利用。逐利、好奇是人的天性，發現缺陷并利用它，漏洞就産生了。“是以，缺陷是天生的，漏洞是不可避免的，網絡攻擊也是必然的。無論是前端還是後端，隻要有代碼存在，就會出現漏洞。”
奇安信代碼安全事業部總經理黃永剛也在之前的采訪中表示：“安全開始左移，大家開始重視源頭上的安全工作。開源軟體是軟體開發的原材料，是我們進行資訊系統開發和建設要把住的第一道安全關口。”
在軟體開發上，無論是技術方面，還是流程和管理方面，任何一點疏忽都會導緻開源軟體出現安全問題。具體說來，黃永剛總結了三個方面的原因：
開源軟體開發者自身的技術能力和安全開發知識存在問題，導緻開發的代碼中有安全缺陷；
大多數開源項目的開發缺少 SDL（安全開發生命周期）的流程和工具。并且，很多開源項目能使用的資源很有限，缺乏專業的代碼安全分析工具，而大部分專業的代碼安全分析工具都是收費的，價格昂貴；
攻擊者對開源生态的攻擊，比如向開源庫中注入惡意代碼、向包管理器倉庫投放惡意元件等。
五點安全建議
如何提高開源軟體的安全性？黃永剛認為，從技術上，開源項目需要更系統地引入保障應用安全的流程、方法和工具，比如基于 SDL 的流程和理念管理開源項目的開發過程，并對開源項目開發者進行安全開發知識的普及。其次，使用源代碼靜态分析、動态安全測試、互動式安全測試等工具，并對開源項目開發者送出的代碼進行全面的安全測試等。
針對軟體開發者和企業，黃永剛建議從引入控制、資産梳理、風險識别、漏洞告警和合理修複五個方面加強開源軟體的安全治理。
引入控制。企業應規範開源軟體的引入流程，建立開源軟體安全引入和退出機制。同時，對開源軟體的引入需要加入安全評估因素，不僅需要評估項目團隊引入的開源軟體是否存在公開的漏洞，是否存在開源法律風險，而且企業應進行完整性驗證，開源軟體是否來自官方，避免使用被篡改的開源軟體。
資産梳理。無論是軟體開發者，還是企業，它們在軟體開發過程中會引入大量開源軟體。然而，企業的安全管理者和開發管理者常常不清楚自身的資訊系統到底引入多少開源軟體，引入了哪些開源軟體。開源軟體有着層層嵌套的依賴關系，軟體開發者或企業很難通過人工方式進行梳理。是以，建議使用專業的自動化工具識别軟體系統中含有哪些開源軟體以及開源軟體之間的關聯關系，形成企業開源軟體可視化資産清單。
風險識别。軟體中使用的開源軟體可能存在已知漏洞，且這些開源軟體背後調用或依賴的其他開源軟體也可能存在已知安全漏洞。在軟體開發過程中，企業應及時發現存在漏洞的開源軟體版本并進行更新。
漏洞告警。在軟體運作階段，企業應監控開源軟體漏洞情報資訊，及時發現開源軟體的最新漏洞資訊，并進行應急響應。
合理修複。絕大多數的開源軟體是通過版本更新實作漏洞修複的。對于不能通過更新新版本或打更新檔來修複漏洞，企業應引入專業的漏洞研究隊伍，定制漏洞修複方案。