知識星球作者：山東星維九州安全技術有限公司
來自：FreeBuf.COM
你說安全就安全？
近日，紅芯瀏覽器“套殼”一事被網路輿論炒的沸沸揚揚。紅芯瀏覽器被官方標榜為“安全、穩定、可控的企業瀏覽器”，其中“自主可控”一項已經被輿論所質疑，但是被官方放在第一項進行宣傳的“安全”是否屬實呢？
據筆者所知，紅芯瀏覽器的主要客戶為國內政府、大型國有企業，單位主體的性質決定了其內部會有大量涉及商密、機密、甚至涉及國家安全的重要資訊，而紅芯瀏覽器則被設計為觸及這些重要資訊的媒介，如果它出了問題，那麼後果不堪設想。
為了驗證紅芯瀏覽器的安全性到底如何，小編決定做了一個簡單的安全測試。對於這種套殼瀏覽器，安全測試大體可以分為兩個部分，一個是“殼”的安全性，一個是瀏覽器“核心”的安全性。
對於“殼”，由於小編沒有伺服器環境，暫時無法接觸到“殼”的主要邏輯，暫時作罷，如果你有測試環境，可以分享給小編，我們將在後續文章中分享測試結果。
圖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 該漏洞早已被谷歌官方修複
測試專案：UXSS
Same origin policy（同源策略，簡稱SOP）一直是web前端安全的基礎。簡單來說，SOP是指就是每個網站中的可執行指令碼（包括html/js/flash等）只有讀寫自己網站內資源的許可權，禁止跨域讀寫其它網站的內容。
舉個例子，你同時開啟了淘寶和京東的網站，淘寶和京東網站的js會同時在你的瀏覽器上執行。瀏覽器認為這兩個網站是嚴格隔離的，淘寶的js不可能訪問京東的收藏夾，同樣，京東的js也不可能訪問淘寶的購物車。這很好理解。
那麼如果這種規則被破壞，後果則不堪設想。設想你訪問某個網站，其中某個不知名的小廣告商的js有許可權訪問你郵箱中的商業合同、你網盤中的私密照片，我就問你還敢不敢上網。
既然SOP這麼重要，駭客又怎麼可能放過呢。駭客們也在不斷尋找繞過SOP的方法，這類繞過方法，或者說SOP的缺陷，被稱為uxss漏洞。此類漏洞一旦被髮現，基本上都被定性為高危漏洞。
圖6和圖7，谷歌高額懸賞uxss漏洞
與XSS Auditor一樣，谷歌官方也不斷修複著這些漏洞，而對於一個已經停止維護的核心，這類漏洞的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 紅芯主要對身份認證和通訊加密方面進行了介紹
紅芯對於安全的宣傳集中在身份認證和通訊加密，如果瀏覽器核心出了問題，導致瀏覽器被惡意程式碼接管，談這些是沒有意義的。
由於沒有測試環境，對於這兩點並沒有測試，不過也沒有必要了，畢竟決定你安全級別是木桶的短板。
安全不是銷售的誇誇其談，不是產品經理的紙上談兵，不是投資人的患得患失，也不是程式員的“想當然”。安全是一件很專業的事情，應當交給專業的人去做。
●編號686，輸入編號直達本文
●輸入m獲取文章目錄
Linux學習
更多推薦《18個技術類公眾微信》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
