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