在計算機安全領域，攻擊者的手段也在不斷創新。 為了構築堅實的瀏覽器安全防線，谷歌已經為 Chrome 打造了基於沙箱和網站隔離的多進程架構。 不過在近日發佈的一篇博客文章中，Chrome 安全團隊進一步介紹了他們在記憶體安全性方面的最新努力。

（來自：Google Security Blog）

Chrome 安全團隊稱，儘管他們在努力堅守上述主要的安全防線，但模糊測試的結果表明，這些措施的防護效果已達到極限，意味著瀏覽器開發商無法再單純依靠單純的策略來抵禦野外攻擊。

數據表明，去年的時候，有超過 70% 的嚴重安全漏洞都與記憶體相關，尤其是 C / C++ 程式設計語言中的指標 bug 會導致記憶體誤解。 在瀏覽器應用之外，記憶體安全也是一個需要全球軟體工程社區認真對待的問題。

與此同時，Chrome 安全團隊認為這也是一個機遇，畢竟許多bug都具有類似的根本原因，意味著我們能夠一次搞定大部分問題。 為此，Chrome 安全團隊提出了三個著力點：

（1）在編譯時檢查指標是否正確;

（2）在運行時檢查指標是否正確;

（3）調查現有代碼庫部分記憶體安全語言的使用。

“編譯時檢查”意味著在 Chrome 構建過程中確保安全，甚至早於向使用者設備推送更新之前。

“運行時檢查”意味著 Chrome 瀏覽器會在終端設備上運行軟體時進行檢查。 當然，這麼做也會有一定的性能成本開銷。

考慮到有數百萬計的指標，即使每個指標的影響都極其細微，數十億的使用者量級，累加起來還是相當可觀的，尤其許多使用者仍在使用資源相對受限的低功耗行動裝置。

在理想情況下，Chrome 安全團隊傾向於優先選擇第（1）套方案。 遺憾的是，C++ 程式設計語言在設計之初並沒有考慮到這一點。

權衡利弊之後，我們最終只剩下了讓 C++ 更安全（但也更慢）的第（2）和第（3）種選項，或嘗試開始使用其它程式設計語言。

換言之，Chrome 安全團隊將在 C++ 安全解決方案上傾注大量的心力，例如 MiraclePtr 和 ABSL / STL 強化模式。

在每種情況下，我們都希望消除相當一部分可被利用的安全漏洞，但預計也會造成一些性能損失。

比如藉助 MiraclePtr 隔離潛在會被引用的記憶體，以預防釋放后的隱患。 而在記憶體資源更加寶貴的大部分行動裝置上，我們很難專門騰出一塊專門的隔離區。

即便如此，MiraclePtr 仍有望消除瀏覽器進程中超過 50% 的釋放後錯誤使用 —— 對於當前的 Chrome 安全性來說，這已經算得上是一個相當矚目的成就。

同時，Chrome 安全團隊將探索未來是否能夠把 Chrome 的某些部分用”記憶體安全語言”進行重構 —— 比如當前被寄予厚望的 Rust（由 Mozilla 雇員 Graydon Hoare 創立）。

由於 Rust 程式設計語言保障了編譯時的安全性，所以編譯器能夠早在代碼抵達用戶設備前排除指標錯誤，從而避免進一步的性能損失。 至於 C++ 能否與 Rust 良好配合，仍有待時間去檢驗。