在計算機安全領域，攻擊者的手段也在不斷創新。為了構築堅實的瀏覽器安全防線，谷歌已經為 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 良好配合，仍有待時間去檢驗。