一種將前端惡意程式碼關在“籠子”裡的技術方案

Lydiasq發表於2022-11-08

安全,特別是軟體程式碼安全,近年來被業內人士頻繁提出,可見其受重視程度。而這些,起源與全球化的開源大生產。


開源軟體運動如火如荼的進行了二十四五年(如果從1998年2月3日在矽谷的一次會議中首次提出“open source”一說開始算 - 當時網際網路先驅Netscape剛剛宣佈開放他們的瀏覽器原始碼),極大程度的改變了軟體業的面貌。 當前全球企業超過90%直接或者間接甚至在無意識中使用了開源技術。

軟體世界中的程式碼供應鏈


正如物理世界的任何產業都有自己的產業鏈、供應鏈一樣,在虛擬世界的軟體業也一樣,任何終極軟體產品,都用到很多的虛擬“零部件” - 以程式碼庫形態存在的元件、框架、工具,而且這些“零部件”本身也高度依賴其他“零部件”。


以銀行為例,消費者、業務部門使用的軟體,由銀行的IT部門提供。但這些軟體僅僅有小部分是IT自己開發的,更多是從第三方供應商採購。而且,無論軟體是自己開發,還是由系統整合商或軟體廠商開發,都依賴於大量的更加基礎的軟體元件、專案、工具。在這個時代, 也許除了國防軍工領域的軟體,幾乎不可能存在每一行程式碼都100%由自己開發的軟體 - 工作量不允許、經濟規律也不符合。


實際上, 隨便一個軟體,按絕對程式碼行數來算,一個不小心有一半是第三方的 例如在一些微服務裡,自己的程式碼只佔10%,也一點都不奇怪。


都說技術是把雙刃劍,能夠促進人類的生產力,也能夠透過一定的方式,對人類虛擬世界進行“毀滅性”的打擊。

8類常見的前端安全問題


1、跨站指令碼攻擊(Cross-Site Scripting): XSS是跨站指令碼攻擊(Cross-Site Scripting)的簡稱。XSS這類安全問題發生的本質原因在於:瀏覽器錯誤的將攻擊者提供的使用者輸入資料當做JavaScript指令碼給執行了。
XSS漏洞是威脅使用者的一個安全隱患。攻擊者可以利用XSS漏洞來竊取包括使用者身份資訊在內的各種敏感資訊、修改Web頁面以欺騙使用者,甚至控制受害者瀏覽器,或者和其他漏洞結合起來形成蠕蟲攻擊,等等。


2、使用iframe的風險:前端頁面如果需要用到第三方提供的頁面元件,通常會以iframe的方式引入。如使用iframe在頁面上新增第三方提供的廣告、天氣預報、社交分享外掛等。  
iframe在給我們的頁面帶來更多豐富內容和能力的同時,也帶來了不少的安全隱患。因為iframe中的內容是由第三方來提供的,預設情況下他們不受我們的控制,他們可以在iframe中執行JavaScirpt指令碼、Flash外掛、彈出對話方塊等等,這可能會影響甚至破壞前端的使用者體驗。


進一步的,如果iframe中的域名因為過期而被惡意攻擊者搶注,或被第三方駭客攻破,iframe中的內容有可能會被篡改成軟體安全漏洞,誘導使用者下載安裝木馬、惡意勒索軟體等等。可想而知,後果非常嚴重。


3、點選劫持:這是一種欺騙性較強,需要使用者高度參與才能完成的一種攻擊。通常的攻擊步驟是:誘導使用者點選內容(如頁面小遊戲,攻擊內容被攻擊者放置在頁面的iframe中,利用z-index等CSS樣式將這個iframe疊加到小遊戲的垂直方向的正上方),受害者訪問這個頁面,肉眼看到的是一個小遊戲,如果受到誘導進行了點選的話,實際上點選到的卻是iframe中的頁面,於是乎,使用者在其不知情的情況下進行了一些操作。


4、錯誤的內容推斷:攻擊者將含有惡意JavaScript的指令碼副檔名改成圖片格式進行上傳。受害者在訪問某網站的一些內容(如圖文內容,或使用者評論)的時候,瀏覽器會去請求這個偽裝成圖片的JavaScript指令碼,而此時如果瀏覽器錯誤的推斷了這個響應的內容型別(MIME types),那麼就會把這個圖片檔案當做JavaScript指令碼執行,於是攻擊也就成功了。


5、不安全的第三方依賴包:如今的應用開發,絕大多數開發者都會藉助開發框架和各種類庫提高開發效率。這樣做的好處顯而易見,但其安全風險也在不斷累積,這對應用整體的安全性會造成嚴峻的挑戰。


6、HTTPS中間人攻擊:伺服器端開啟了HTTPS,還是會存在安全隱患,駭客可以利用SSL Stripping這種攻擊手段,強制讓HTTPS降級回HTTP,從而繼續進行中間人攻擊。


該攻擊的原理在於,瀏覽器發出去第一次請求就被攻擊者攔截了下來並做了修改,根本不給瀏覽器和伺服器進行HTTPS通訊的機會。大致過程如下,使用者在瀏覽器裡輸入URL的時候往往不是從https://開始的,而是直接從域名開始輸入,隨後瀏覽器向伺服器發起HTTP通訊,然而由於攻擊者的存在,它把伺服器端返回的跳轉到HTTPS頁面的響應攔截了,並且代替客戶端和伺服器端進行後續的通訊。由於這一切都是暗中進行的,所以使用前端應用的使用者對此毫無察覺。


7 、本地儲存資料洩露:隨著前後端分離,尤其是後端服務無狀態化架構風格的興起,隨著SPA應用大量出現,儲存在前端資料量也在逐漸增多。


前端應用是完全暴露在使用者以及攻擊者面前的,在前端儲存任何敏感、機密的資料,都會面臨洩露的風險,就算是在前端透過JS指令碼對資料進行加密基本也無濟於事。


8 、CDN劫持/汙染:出於效能考慮,前端應用通常會把一些靜態資源存放到CDN上,提高前端應用的訪問速度的同時,也隱含了一個新的安全風險:如果攻擊者劫持了CDN,或者對CDN中的資源進行了汙染,那麼我們的前端應用拿到的就是有問題的JS指令碼或者Stylesheet檔案。這種攻擊方式造成的效果和XSS跨站指令碼攻擊相似。


如此多的、影響重大的前端安全問題,直接把軟體安全防範推上了風口浪尖。更為可怕的是,對於企業們來說,你的所謂“資訊保安”、“安全加固”,也就取決於 畫的這張圖右下角那塊小積木 - 可能是地球上隨便哪個地方的一個路人甲工程師以無私“活雷鋒”精神默默耕耘多年奉獻的一段程式碼:

一種將前端惡意程式碼關在“籠子”裡的技術方案


“永不信任,總是查證”。 零信任,很可能將成為企業數字化轉型的“必要條件”。數字化意味著連線,連線的前提是開放,開放的資格取決於安全風控能力。可以說,安全風控是數字化轉型的第一屬性,而數字化企業的安全風控,建立在零信任基礎上。

懷疑一切,並隔離之


零信任,首先是一種數字化時代的安全“哲學”、架構理念,然後才是一系列的科技產品與工具。其中種類繁多,不一而足;也沒有哪家廠商敢聲稱現在已經提供了所有的、最完整的解決方案。這是一個正在發展的領域,大家都在路上。


虛擬世界的“惡意”程式碼,也只能用虛擬的“牢籠”去“關住”它。安全沙箱(Security Sandbox),就是這麼一種數字牢籠,它的形態和技術實現方式有很多種,本質上它是一種安全隔離機制,透過構建一個封閉的軟體環境,隔離了它所在的“宿主”的資源包括記憶體、檔案系統、網路等等的訪問許可權。執行在這個封閉環境中的程式,其程式碼不受信任,程式不能因為其自身的穩定性導致沙箱的崩潰從而影響宿主系統,程式也無法突破沙箱的安全管控以讀寫宿主系統的資源。

FinClip:前端安全沙箱技術


FinClip是一種小程式容器技術,它有一個比較有趣的邏輯:企業的軟體供應鏈在數字化時代可能是需要被重新定義的 - 有可能你的合作伙伴的程式碼執行在你這裡、也有可能你的程式碼借道合作伙伴的平臺去觸達對方的客戶。FinClip的核心是一個可嵌入任何iOS/Android App、Windows/MacOS/Linux Desktop Software、Android/Linux作業系統、IoT/車載系統的多終端安全執行沙箱。


FinClip安全沙箱中執行的輕應用,選擇了相容網際網路主流的小程式規範。這是一個非常明智的設計,FinClip的開發團隊沒有重新發明自己的技術規格,而是全力支援小程式這種形態的輕應用,一方面是因為小程式類技術的體驗和效果在網際網路上得到充分驗證、獲得巨大成功,另一方面是網上積累了豐富的技術生態、開發框架、以及更重要的 - 人才資源,從而讓企業IT幾乎是無縫掌握這個技術,能迅速投入應用。 一種將前端惡意程式碼關在“籠子”裡的技術方案


FinClip的嵌入式安全沙箱,又被稱之為小程式容器,它的本質其實是建立在Security Capability model基礎上的瀏覽器核心的擴充套件,其沙箱的特點,體現在三個方面:

  • 沙箱內小程式之間的隔離

  • 沙箱對執行其中的小程式程式碼,隔離其對宿主環境的資源訪問。以一家銀行與它的合作生態為例,銀行在自己的App上引入了衣食住行各類消費場景的小程式,這些小程式均非本行開發,也不能訪問到當前宿主App的任何資料資源

  • 沙箱隔離了宿主對於沙箱中執行的小程式所產生的資料。以一家銀行與一家券商的合作為例,券商把自己的業務小程式投放到銀行的App中,銀行App作為宿主,並不能訪問沙箱內部該小程式的執行資料(當然,這是需要有一定的行業規範、監管政策去約束,但技術上首先是完全可能)


換句話說, FinClip試圖構建一個Zero Trust(“零信任”)環境,不管小程式的“供應商”是誰,它們的程式碼都被隔離、同時也被保護在沙箱環境中。


FinClip安全沙箱還配備了雲端的管控後臺,讓任何小程式可以被關聯到指定的App宿主所嵌的沙箱例項中,從而能且僅能執行在某一款App或者某一個終端上。像網際網路小程式一樣, FinClip的小程式也可以被實時上下架,對於金融機構來說,起到“實時風控”的效果,因為上下架的管理工具和許可權,都由企業私有化執行、自行負責。任何有潛在安全風險的前端程式碼,一經發現即可瞬間下架,使用者端再也無法開啟使用。
這些安全管控的能力,可以說是企業尤其是金融機構數字化轉型所必須。對於企業而言,內部IT、外部合作伙伴,均可以作為“供應商”以小程式方式實現、提供數字化場景,從而形成數字生態。

Deno:雲端安全沙箱技術


Deno是Node.js的發明者Ryan Dahl的重新發明。在推動伺服器端JavaScript的應用生態獲得巨大成功後,Ryan也看到Node.js的很多存在問題,在2018年的一次公開演講中,提到了其為Node.js感到後悔的十件事。最終他另起爐灶,按自己的理想重新打造一個新的技術,也就是Deno,其中最重要的設計考慮就是安全優先、為deno技術設計的第一性、並採用V8引擎作為JavaScript執行的安全沙箱。
一種將前端惡意程式碼關在“籠子”裡的技術方案


當然,Deno不僅是一個安全沙箱,在本文我們僅從這個角度去談論它。它的野心不僅在於替代Node.js把之前沒有做對的事情做對,它基於Rust語言實現,支援WebAssembly,提出了“Isolated Cloud”(隔離雲)的概念,給網際網路提供比docker等容器類技術更加輕量和啟動時間更短、實現程式級隔離的新一代安全基礎技術設施,最新訊息是幾天前由紅杉資本領投獲得了新一輪2100萬美元的投資。


沙箱技術有很多種類,是否能稱之為“安全沙箱”,則視乎其隔離的程度和自身的技術目的。例如能模擬出一整臺伺服器或者桌面電腦的虛擬機器,應該能稱之為安全沙箱 - 你可以在裡面跑企業服務、也可以在裡面打遊戲,並不能影響宿主的安全穩定執行,你也可以把這個虛擬機器一鍵刪除,不管裡面安裝了什麼東西。


技術的發展總是相輔相成的。全球權威諮詢機構Gartner於2022年10月19日釋出企業機構在2023年需要探索的十大戰略技術趨勢, 超級App(Superapps)也在榜單之中。縱觀中國的超級App生態的建設,小程式應用生態幫了非常大的忙。


在App中內嵌小程式容器安全沙箱,也許是超級App兼顧快速應用生態引入及前端安全防護的更優技術。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70023421/viewspace-2922304/,如需轉載,請註明出處,否則將追究法律責任。

相關文章