不懂瀏覽器安全，被老板邀請爬山？
瀏覽器安全可以分為三大塊——Web 頁面安全、瀏覽器網(wǎng)絡(luò)安全和瀏覽器系統(tǒng)安全
在web頁面中的安全策略中最基礎(chǔ)、最核心的安全策略：同源策略(Same-origin policy)。
Web 頁面安全
同源策略(Same-origin policy)
如果兩個 URL 的協(xié)議、域名和端口都相同，我們就稱這兩個 URL 同源。瀏覽器默認兩個相同的源之間是可以相互訪問資源和操作 DOM 的。兩個不同的源之間若想要相互訪問資源或者操作 DOM，那么會有一套基礎(chǔ)的安全策略的制約，我們把這稱為同源策略。
主要表現(xiàn)
- DOM 層面
同源策略限制了來自不同源的 JavaScript 腳本對當前 DOM 對象讀和寫的操作。
- 數(shù)據(jù)層面
同源策略限制了不同源的站點讀取當前站點的 Cookie、IndexDB、LocalStorage 等數(shù)據(jù)。
- 網(wǎng)絡(luò)層面
同源策略限制了通過 XMLHttpRequest 等方式將站點的數(shù)據(jù)發(fā)送給不同源的站點
安全和便利性
不過安全性和便利性是相互對立的，讓不同的源之間絕對隔離，無疑是最安全的措施，但這也會使得 Web 項目難以開發(fā)和使用。因此我們就要在這之間做出權(quán)衡，出讓一些安全性來滿足靈活性;
出讓的安全性
- 頁面中可以嵌入第三方資源
頁面中可以引用第三方資源,不過這也暴露了很多諸如 XSS 的安全問題，因此又在這種開放的基礎(chǔ)之上引入了 CSP (內(nèi)容安全策略)來限制其自由程度。CSP 的核心思想是讓服務(wù)器決定瀏覽器能夠加載哪些資源，讓服務(wù)器決定瀏覽器是否能夠執(zhí)行內(nèi)聯(lián) JavaScript 代碼
- 跨文檔消息機制
兩個不同源的 DOM 是不能相互操縱的，瀏覽器中又引入了跨文檔消息機制，可以通過 window.postMessage 的 JavaScript 接口來和不同源的 DOM 進行通信。
- 跨域資源共享
不同域之間使用 XMLHttpRequest 和 Fetch 都是無法直接進行跨域請求的,瀏覽器又在這種嚴格策略的基礎(chǔ)之上引入了跨域資源共享策略(CORS)，使用該機制可以進行跨域訪問控制，從而使跨域數(shù)據(jù)傳輸?shù)靡园踩M行。
Web網(wǎng)絡(luò)安全
我們使用 HTTP 傳輸?shù)膬?nèi)容很容易被中間人竊取、偽造和篡改，通常我們把這種攻擊方式稱為中間人攻擊。具體來講，在將 HTTP 數(shù)據(jù)提交給 TCP 層之后，數(shù)據(jù)會經(jīng)過用戶電腦、WiFi 路由器、運營商和目標服務(wù)器，在這中間的每個環(huán)節(jié)中，數(shù)據(jù)都有可能被竊取或篡改。比如用戶電腦被黑客安裝了惡意軟件，那么惡意軟件就能抓取和篡改所發(fā)出的 HTTP 請求的內(nèi)容?；蛘哂脩粢徊恍⌒倪B接上了 WiFi 釣魚路由器，那么數(shù)據(jù)也都能被黑客抓取或篡改。
在 HTTP 協(xié)議棧中引入安全層
鑒于 HTTP 的明文傳輸使得傳輸過程毫無安全性可言，且制約了網(wǎng)上購物、在線轉(zhuǎn)賬等一系列場景應(yīng)用，于是倒逼著我們要引入加密方案。從 HTTP 協(xié)議棧層面來看，我們可以在 TCP 和 HTTP 之間插入一個安全層，所有經(jīng)過安全層的數(shù)據(jù)都會被加密或者解密。安全層有兩個主要的職責：對發(fā)起 HTTP 請求的數(shù)據(jù)進行加密操作和對接收到 HTTP 的內(nèi)容進行解密操作。
HTTPS傳輸數(shù)據(jù)
在傳輸數(shù)據(jù)階段依然使用對稱加密，但是對稱加密的密鑰我們采用非對稱加密來傳輸
- 首先瀏覽器向服務(wù)器發(fā)送對稱加密套件列表、非對稱加密套件列表和隨機數(shù) client-random;
- 服務(wù)器保存隨機數(shù) client-random，選擇對稱加密和非對稱加密的套件，然后生成隨機數(shù) service-random，向瀏覽器發(fā)送選擇的加密套件、service-random 和公鑰;
- 瀏覽器保存公鑰，并生成隨機數(shù) pre-master，然后利用公鑰對 pre-master 加密，并向服務(wù)器發(fā)送加密后的數(shù)據(jù);
- 最后服務(wù)器拿出自己的私鑰，解密出 pre-master 數(shù)據(jù)，并返回確認消息。
數(shù)字證書
通過上面的方式我們實現(xiàn)了數(shù)據(jù)的加密傳輸，不過這種方式依然存在著問題，黑客通過 DNS 劫持將網(wǎng)址的 IP 地址替換成了黑客的 IP 地址，這樣訪問的其實是黑客的服務(wù)器了，黑客就可以在自己的服務(wù)器上實現(xiàn)公鑰和私鑰，而對瀏覽器來說，它完全不知道現(xiàn)在訪問的是個黑客的站點。所以我們還需要服務(wù)器向瀏覽器提供證明“我就是我”。證明我就是我需要使用權(quán)威機構(gòu)頒發(fā)的證書，這個權(quán)威機構(gòu)稱為 CA(Certificate Authority)，頒發(fā)的證書就稱為數(shù)字證書(Digital Certificate)。
數(shù)字證書有兩個作用：一個是通過數(shù)字證書向瀏覽器證明服務(wù)器的身份，另一個是數(shù)字證書里面包含了服務(wù)器公鑰。
完整的HTTPS請求流程
通過引入數(shù)字證書，我們就實現(xiàn)了服務(wù)器的身份認證功能，這樣即便黑客偽造了服務(wù)器，但是由于證書是沒有辦法偽造的，所以依然無法欺騙用戶。
總結(jié)
我們使用對稱加密實現(xiàn)了安全層，但是由于對稱加密的密鑰需要明文傳輸，所以我們又將對稱加密改造成了非對稱加密。但是非對稱加密效率低且不能加密服務(wù)器到瀏覽器端的數(shù)據(jù)，于是我們又繼續(xù)改在安全層，采用對稱加密的方式加密傳輸數(shù)據(jù)和非對稱加密的方式來傳輸密鑰，這樣我們就解決傳輸效率和兩端數(shù)據(jù)安全傳輸?shù)膯栴}。采用這種方式雖然能保證數(shù)據(jù)的安全傳輸，但是依然沒辦法證明服務(wù)器是可靠的，于是又引入了數(shù)字證書，數(shù)字證書是由 CA 簽名過的，所以瀏覽器能夠驗證該證書的可靠性
瀏覽器系統(tǒng)安全
瀏覽器安全架構(gòu)
如果瀏覽器被曝出存在漏洞，那么在這些漏洞沒有被及時修復(fù)的情況下，黑客就有可能通過惡意的頁面向瀏覽器中注入惡意程序，其中最常見的攻擊方式是利用緩沖區(qū)溢出。和 XSS 攻擊頁面相比，這類攻擊無疑是枚“核彈”，它會將整個操作系統(tǒng)的內(nèi)容都暴露給黑客，這樣我們操作系統(tǒng)上所有的資料都是不安全的了。為了提高安全性，瀏覽器的采用了如下的多進程架構(gòu)。并且提供了安全沙箱和站點隔離來進一步加強安全
安全沙箱
由于渲染進程需要執(zhí)行 DOM 解析、CSS 解析、網(wǎng)絡(luò)圖片解碼等操作，如果渲染進程中存在系統(tǒng)級別的漏洞，那么以上操作就有可能讓惡意的站點獲取到渲染進程的控制權(quán)限，進而又獲取操作系統(tǒng)的控制權(quán)限，這對于用戶來說是非常危險的?；谝陨显?，我們需要在渲染進程和操作系統(tǒng)之間建一道墻，即便渲染進程由于存在漏洞被黑客攻擊，但由于這道墻，黑客就獲取不到渲染進程之外的任何操作權(quán)限。將渲染進程和操作系統(tǒng)隔離的這道墻就是我們要聊的安全沙箱。
瀏覽器中的安全沙箱是利用操作系統(tǒng)提供的安全技術(shù)，讓渲染進程在執(zhí)行過程中無法訪問或者修改操作系統(tǒng)中的數(shù)據(jù)，在渲染進程需要訪問系統(tǒng)資源的時候，需要通過瀏覽器內(nèi)核來實現(xiàn)，然后將訪問的結(jié)果通過 IPC 轉(zhuǎn)發(fā)給渲染進程。安全沙箱最小的保護單位是進程。因為單進程瀏覽器需要頻繁訪問或者修改操作系統(tǒng)的數(shù)據(jù)，所以單進程瀏覽器是無法被安全沙箱保護的，而現(xiàn)代瀏覽器采用的多進程架構(gòu)使得安全沙箱可以發(fā)揮作用。
安全沙箱影響的模塊功能
持久存儲
存儲 Cookie 數(shù)據(jù)的讀寫。通常瀏覽器內(nèi)核會維護一個存放所有 Cookie 的 Cookie 數(shù)據(jù)庫，然后當渲染進程通過 JavaScript 來讀取 Cookie 時，渲染進程會通過 IPC 將讀取 Cookie 的信息發(fā)送給瀏覽器內(nèi)核，瀏覽器內(nèi)核讀取 Cookie 之后再將內(nèi)容返回給渲染進程。一些緩存文件的讀寫也是由瀏覽器內(nèi)核實現(xiàn)的，比如網(wǎng)絡(luò)文件緩存的讀取。
網(wǎng)絡(luò)訪問
同樣有了安全沙箱的保護，在渲染進程內(nèi)部也是不能直接訪問網(wǎng)絡(luò)的，如果要訪問網(wǎng)絡(luò)，則需要通過瀏覽器內(nèi)核。不過瀏覽器內(nèi)核在處理 URL 請求之前，會檢查渲染進程是否有權(quán)限請求該 URL，比如檢查 XMLHttpRequest 或者 Fetch 是否是跨站點請求，或者檢測 HTTPS 的站點中是否包含了 HTTP 的請求。
用戶交互
為了限制渲染進程有監(jiān)控到用戶輸入事件的能力，所以所有的鍵盤鼠標事件都是由瀏覽器內(nèi)核來接收的，然后瀏覽器內(nèi)核再通過 IPC 將這些事件發(fā)送給渲染進程。
渲染進程需要渲染出位圖。為了向用戶顯示渲染進程渲染出來的位圖，渲染進程需要將生成好的位圖發(fā)送到瀏覽器內(nèi)核，然后瀏覽器內(nèi)核將位圖復(fù)制到屏幕上。
操作系統(tǒng)沒有將用戶輸入事件直接傳遞給渲染進程，而是將這些事件傳遞給瀏覽器內(nèi)核。然后瀏覽器內(nèi)核再根據(jù)當前瀏覽器界面的狀態(tài)來判斷如何調(diào)度這些事件，如果當前焦點位于瀏覽器地址欄中，則輸入事件會在瀏覽器內(nèi)核內(nèi)部處理;如果當前焦點在頁面的區(qū)域內(nèi)，則瀏覽器內(nèi)核會將輸入事件轉(zhuǎn)發(fā)給渲染進程。
站點隔離
所謂站點隔離是指 Chrome 將同一站點(包含了相同根域名和相同協(xié)議的地址)中相互關(guān)聯(lián)的頁面放到同一個渲染進程中執(zhí)行。由于最初都是按照標簽頁來劃分渲染進程的，所以如果一個標簽頁里面有多個不同源的 iframe，那么這些 iframe 也會被分配到同一個渲染進程中，這樣就很容易讓黑客通過 iframe 來攻擊當前渲染進程。而站點隔離會將不同源的 iframe 分配到不同的渲染進程中，這樣即使黑客攻擊惡意 iframe 的渲染進程，也不會影響到其他渲染進程的。
作者：一只菜鳥攻城獅啊
鏈接：https://www.cnblogs.com/suihang/p/13271872.html
