尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
你說安全就安全？
最近，紅芯瀏覽器「套殼」一事被網路輿論炒的沸沸揚揚。紅芯瀏覽器被官方標榜為「安全、穩定、可控的企業瀏覽器」，其中「自主可控」一項已經被輿論所質疑，但是被官方放在第一項進行宣傳的「安全」是否屬實呢？
據筆者所知，紅芯瀏覽器的主要客戶為國內政府、大型國有企業，單位主體的性質決定了其內部會有大量涉及商密、機密、甚至涉及國家安全的重要信息，而紅芯瀏覽器則被設計為觸及這些重要信息的媒介，如果它出了問題，那麼後果不堪設想。
為了驗證紅芯瀏覽器的安全性到底如何，小編決定做了一個簡單的安全測試。對於這種套殼瀏覽器，安全測試大體可以分為兩個部分，一個是「殼」的安全性，一個是瀏覽器「內核」的安全性。
對於「殼」，由於小編沒有服務器環境，暫時無法接觸到「殼」的主要邏輯，暫時作罷，如果你有測試環境，可以分享給小編，我們將在後續文章中分享測試結果。
圖1 需要設置服務器地址才可以登陸，進而才可以測試「殼」
那麼我們就測一下」內核」。根據之前網路上的爆料文章，紅芯為了兼容XP，使用了最後一個兼容XP的內核：Chromium49。說起這個內核，筆者不禁回憶起了自己的青春，當初學編寫chrome擴展的時候正是基於這個版本，說起來已經是兩年前的事情了。
換句話說，如果你使用了兩年前的版本，你失去不僅僅是兩年內Chromium的新特性、新功能，更重要的是你失去了這兩年內Chromium積累的安全補丁。
本次測試文件為紅芯企業瀏覽器的3.0.54版本。
圖2 紅芯瀏覽器3.0.54安裝文件
測試項目：XSS Auditor(filter) ByPass
XSS Auditor(filter)ByPass 翻譯過來意思是：XSS審計器（或稱XSS過濾器）的繞過。一直以來，XSS攻擊是web前端領域里面威脅最大、利用最廣泛的漏洞。在國際權威組織owasp針對最流行的Top10的web攻擊統計中，XSS攻擊從未掉隊。
圖3 2013-2017之間XSS的排名變化
然而，從這張圖可以看到XSS從2013年的第3滑落到2017年的第7名，這其中的原因是多方面的，但其中重要的原因，就是現代瀏覽器引入並不斷完善的XSS Auditor對反射型XSS的「狙擊」，讓XSS攻擊越來越難用。
XSS Auditor最早被Chrome4、IE8引入。當然，道高一尺魔高一丈，XSS Auditor的更新不是閉門造車，而是在不斷的攻防對抗中完善自己。全世界的黑客都在樂此不疲尋找XSS Auditor中的缺陷，以求繞過防護進行XSS攻擊。而幾乎Chrome的每次更新、IE的每個補丁，都會更新XSS Auditor，讓這些繞過措施失效。然後黑客又找、官方又更新……由此往復循環，才有了今天較為完善的XSS Auditor防護體系。
我是不是扯遠了。回到正題，紅芯用了兩年前的內核，那麼意味著XSS Auditor已經兩年沒有更新，理論上這兩年內的任何一個繞過XSS審計器的利用代碼都是可以生效的。
我們先構造一個簡單的反射形XSS漏洞：
我們檢查紅芯瀏覽器是否能抵禦XSS攻擊。地址欄輸入：
輸入的js並沒有執行，可見紅芯是開啟了XSS Auditor的。
百度隨手搜了一段繞過XSS Auditor代碼，即在上面的js前面加一串%00。「%00」是16進制的0，在C語言中代表字符串的結束。不同的程序對0字符的理解不同，因此這個字符經常會引發一些安全問題。輸入：
圖4 繞過紅芯的防護，執行了XSS
成功繞過XSS Auditor執行了js。
相同的代碼在我的Chrome63（非最新）上卻被成功攔截。
圖5 該漏洞早已被Google官方修復
測試項目：UXSS
Same origin policy（同源策略，簡稱SOP）一直是web前端安全的基礎。簡單來說，SOP是指就是每個網站中的可執行腳本（包括html/js/flash等）只有讀寫自己網站內資源的權限，禁止跨域讀寫其它網站的內容。
舉個例子，你同時打開了淘寶和京東的網站，淘寶和京東網站的js會同時在你的瀏覽器上運行。瀏覽器認為這兩個網站是嚴格隔離的，淘寶的js不可能訪問京東的收藏夾，同樣，京東的js也不可能訪問淘寶的購物車。這很好理解。
那麼如果這種規則被破壞，後果則不堪設想。設想你訪問某個網站，其中某個不知名的小廣告商的js有權限訪問你郵箱中的商業合同、你網盤中的私密照片，我就問你還敢不敢上網。
既然SOP這麼重要，黑客又怎麼可能放過呢。黑客們也在不斷尋找繞過SOP的方法，這類繞過方法，或者說SOP的缺陷，被稱為uxss漏洞。此類漏洞一旦被發現，基本上都被定性為高危漏洞。
圖6和圖7，Google高額懸賞uxss漏洞
與XSS Auditor一樣，Google官方也不斷修復著這些漏洞，而對於一個已經停止維護的內核，這類漏洞的PoC（即漏洞利用代碼）在網上比比皆是。
在chromium項目的bug反饋頁面，找到一個作用於chrome <52的UXSS。這個漏洞提交時間為2016年4月份。
https://bugs.chromium.org/p/chromium/issues/detail?id=604901
根據作者提供的Demo，把目標域名修改為baidu，把要執行的js修改為如下：
圖8 修改跨域執行的js，效果為展示當前url並讀取cookie
將Demo部署到本地http://127.0.0.1/中，用紅芯訪問。
圖9 demo提供三種跨域方式分別為：跳轉後執行、新標籤頁執行、iframe中執行uxss
點擊第一個按鈕，意為「跳轉後執行uxss」，點擊後調轉至baidu，並以baidu域的權限執行了我們定義的js代碼。
圖10 以baidu的權限執行了js
上面的過程，演示了http://127.0.0.1/中的js讀取了http://www.baidu.com/上的Cookie，Cookie意為著什麼我就不多說了。換句話說，瀏覽器的SOP被破壞，http://127.0.0.1/將有權限讀取http://www.baidu.com/上的任何資源。如果進一步的利用，可以讀取你百度搜尋歷史，百度網盤里的文件等等。
作為對比，我們換Chrome63試一下：
圖11 漏洞已經修復
頁面報錯，代碼沒有執行。
解決方案
首先是對官方的建議，新內核不代表一定不會兼容XP。完全可以像360瀏覽器那樣，把不兼容的函數一一手改成兼容的，當然這個工程量很大。
對於普通用戶，尤其是政企類用戶，在官方沒有給出升級方案之前，暫時不建議使用。
後記
我從新審視了紅芯官方對於安全功能的闡述，看上去很高大上。
圖12 紅芯主要對身份認證和通訊加密方面進行了介紹
紅芯對於安全的宣傳集中在身份認證和通訊加密，如果瀏覽器內核出了問題，導致瀏覽器被惡意代碼接管，談這些是沒有意義的。
由於沒有測試環境，對於這兩點並沒有測試，不過也沒有必要了，畢竟決定你安全級別是木桶的短板。
安全不是銷售的誇誇其談，不是產品經理的紙上談兵，不是投資人的患得患失，也不是工程師的「想當然」。安全是一件很專業的事情，應當交給專業的人去做。
*本文作者：山東星維九州安全技術有限公司，轉載請註明來自FreeBuf.COM
