瀏覽器安全可以分為三大塊——Web 頁面安全、瀏覽器網(wǎng)絡(luò)安全和瀏覽器系統(tǒng)安全

[[333761]]

在web頁面中的安全策略中最基礎(chǔ)、最核心的安全策略：同源策略(Same-origin policy)。

Web 頁面安全

同源策略(Same-origin policy)

如果兩個(gè) URL 的協(xié)議、域名和端口都相同，我們就稱這兩個(gè) URL 同源。瀏覽器默認(rèn)兩個(gè)相同的源之間是可以相互訪問資源和操作 DOM 的。兩個(gè)不同的源之間若想要相互訪問資源或者操作 DOM，那么會有一套基礎(chǔ)的安全策略的制約，我們把這稱為同源策略。

主要表現(xiàn)

• DOM 層面

同源策略限制了來自不同源的 JavaScript 腳本對當(dāng)前 DOM 對象讀和寫的操作。

• 數(shù)據(jù)層面

同源策略限制了不同源的站點(diǎn)讀取當(dāng)前站點(diǎn)的 Cookie、IndexDB、LocalStorage 等數(shù)據(jù)。

• 網(wǎng)絡(luò)層面

同源策略限制了通過 XMLHttpRequest 等方式將站點(diǎn)的數(shù)據(jù)發(fā)送給不同源的站點(diǎn)

安全和便利性

不過安全性和便利性是相互對立的，讓不同的源之間絕對隔離，無疑是最安全的措施，但這也會使得 Web 項(xiàng)目難以開發(fā)和使用。因此我們就要在這之間做出權(quán)衡，出讓一些安全性來滿足靈活性;

出讓的安全性

• 頁面中可以嵌入第三方資源

頁面中可以引用第三方資源,不過這也暴露了很多諸如 XSS 的安全問題，因此又在這種開放的基礎(chǔ)之上引入了 CSP (內(nèi)容安全策略)來限制其自由程度。CSP 的核心思想是讓服務(wù)器決定瀏覽器能夠加載哪些資源，讓服務(wù)器決定瀏覽器是否能夠執(zhí)行內(nèi)聯(lián) JavaScript 代碼

• 跨文檔消息機(jī)制

兩個(gè)不同源的 DOM 是不能相互操縱的，瀏覽器中又引入了跨文檔消息機(jī)制，可以通過 window.postMessage 的 JavaScript 接口來和不同源的 DOM 進(jìn)行通信。

• 跨域資源共享

不同域之間使用 XMLHttpRequest 和 Fetch 都是無法直接進(jìn)行跨域請求的,瀏覽器又在這種嚴(yán)格策略的基礎(chǔ)之上引入了跨域資源共享策略(CORS)，使用該機(jī)制可以進(jìn)行跨域訪問控制，從而使跨域數(shù)據(jù)傳輸?shù)靡园踩M(jìn)行。

Web網(wǎng)絡(luò)安全

我們使用 HTTP 傳輸?shù)膬?nèi)容很容易被中間人竊取、偽造和篡改，通常我們把這種攻擊方式稱為中間人攻擊。具體來講，在將 HTTP 數(shù)據(jù)提交給 TCP 層之后，數(shù)據(jù)會經(jīng)過用戶電腦、WiFi 路由器、運(yùn)營商和目標(biāo)服務(wù)器，在這中間的每個(gè)環(huán)節(jié)中，數(shù)據(jù)都有可能被竊取或篡改。比如用戶電腦被黑客安裝了惡意軟件，那么惡意軟件就能抓取和篡改所發(fā)出的 HTTP 請求的內(nèi)容。或者用戶一不小心連接上了 WiFi 釣魚路由器，那么數(shù)據(jù)也都能被黑客抓取或篡改。

在 HTTP 協(xié)議棧中引入安全層

鑒于 HTTP 的明文傳輸使得傳輸過程毫無安全性可言，且制約了網(wǎng)上購物、在線轉(zhuǎn)賬等一系列場景應(yīng)用，于是倒逼著我們要引入加密方案。從 HTTP 協(xié)議棧層面來看，我們可以在 TCP 和 HTTP 之間插入一個(gè)安全層，所有經(jīng)過安全層的數(shù)據(jù)都會被加密或者解密。安全層有兩個(gè)主要的職責(zé)：對發(fā)起 HTTP 請求的數(shù)據(jù)進(jìn)行加密操作和對接收到 HTTP 的內(nèi)容進(jìn)行解密操作。

HTTPS傳輸數(shù)據(jù)

在傳輸數(shù)據(jù)階段依然使用對稱加密，但是對稱加密的密鑰我們采用非對稱加密來傳輸

• 首先瀏覽器向服務(wù)器發(fā)送對稱加密套件列表、非對稱加密套件列表和隨機(jī)數(shù) client-random;
• 服務(wù)器保存隨機(jī)數(shù) client-random，選擇對稱加密和非對稱加密的套件，然后生成隨機(jī)數(shù) service-random，向?yàn)g覽器發(fā)送選擇的加密套件、service-random 和公鑰;
• 瀏覽器保存公鑰，并生成隨機(jī)數(shù) pre-master，然后利用公鑰對 pre-master 加密，并向服務(wù)器發(fā)送加密后的數(shù)據(jù);
• 最后服務(wù)器拿出自己的私鑰，解密出 pre-master 數(shù)據(jù)，并返回確認(rèn)消息。

數(shù)字證書

通過上面的方式我們實(shí)現(xiàn)了數(shù)據(jù)的加密傳輸，不過這種方式依然存在著問題，黑客通過 DNS 劫持將網(wǎng)址的 IP 地址替換成了黑客的 IP 地址，這樣訪問的其實(shí)是黑客的服務(wù)器了，黑客就可以在自己的服務(wù)器上實(shí)現(xiàn)公鑰和私鑰，而對瀏覽器來說，它完全不知道現(xiàn)在訪問的是個(gè)黑客的站點(diǎn)。所以我們還需要服務(wù)器向?yàn)g覽器提供證明“我就是我”。證明我就是我需要使用權(quán)威機(jī)構(gòu)頒發(fā)的證書，這個(gè)權(quán)威機(jī)構(gòu)稱為 CA(Certificate Authority)，頒發(fā)的證書就稱為數(shù)字證書(Digital Certificate)。

數(shù)字證書有兩個(gè)作用：一個(gè)是通過數(shù)字證書向?yàn)g覽器證明服務(wù)器的身份，另一個(gè)是數(shù)字證書里面包含了服務(wù)器公鑰。

完整的HTTPS請求流程

通過引入數(shù)字證書，我們就實(shí)現(xiàn)了服務(wù)器的身份認(rèn)證功能，這樣即便黑客偽造了服務(wù)器，但是由于證書是沒有辦法偽造的，所以依然無法欺騙用戶。

總結(jié)

我們使用對稱加密實(shí)現(xiàn)了安全層，但是由于對稱加密的密鑰需要明文傳輸，所以我們又將對稱加密改造成了非對稱加密。但是非對稱加密效率低且不能加密服務(wù)器到瀏覽器端的數(shù)據(jù)，于是我們又繼續(xù)改在安全層，采用對稱加密的方式加密傳輸數(shù)據(jù)和非對稱加密的方式來傳輸密鑰，這樣我們就解決傳輸效率和兩端數(shù)據(jù)安全傳輸?shù)膯栴}。采用這種方式雖然能保證數(shù)據(jù)的安全傳輸，但是依然沒辦法證明服務(wù)器是可靠的，于是又引入了數(shù)字證書，數(shù)字證書是由 CA 簽名過的，所以瀏覽器能夠驗(yàn)證該證書的可靠性

瀏覽器系統(tǒng)安全

瀏覽器安全架構(gòu)

如果瀏覽器被曝出存在漏洞，那么在這些漏洞沒有被及時(shí)修復(fù)的情況下，黑客就有可能通過惡意的頁面向?yàn)g覽器中注入惡意程序，其中最常見的攻擊方式是利用緩沖區(qū)溢出。和 XSS 攻擊頁面相比，這類攻擊無疑是枚“核彈”，它會將整個(gè)操作系統(tǒng)的內(nèi)容都暴露給黑客，這樣我們操作系統(tǒng)上所有的資料都是不安全的了。為了提高安全性，瀏覽器的采用了如下的多進(jìn)程架構(gòu)。并且提供了安全沙箱和站點(diǎn)隔離來進(jìn)一步加強(qiáng)安全

安全沙箱

由于渲染進(jìn)程需要執(zhí)行 DOM 解析、CSS 解析、網(wǎng)絡(luò)圖片解碼等操作，如果渲染進(jìn)程中存在系統(tǒng)級別的漏洞，那么以上操作就有可能讓惡意的站點(diǎn)獲取到渲染進(jìn)程的控制權(quán)限，進(jìn)而又獲取操作系統(tǒng)的控制權(quán)限，這對于用戶來說是非常危險(xiǎn)的?；谝陨显颍覀冃枰阡秩具M(jìn)程和操作系統(tǒng)之間建一道墻，即便渲染進(jìn)程由于存在漏洞被黑客攻擊，但由于這道墻，黑客就獲取不到渲染進(jìn)程之外的任何操作權(quán)限。將渲染進(jìn)程和操作系統(tǒng)隔離的這道墻就是我們要聊的安全沙箱。

瀏覽器中的安全沙箱是利用操作系統(tǒng)提供的安全技術(shù)，讓渲染進(jìn)程在執(zhí)行過程中無法訪問或者修改操作系統(tǒng)中的數(shù)據(jù)，在渲染進(jìn)程需要訪問系統(tǒng)資源的時(shí)候，需要通過瀏覽器內(nèi)核來實(shí)現(xiàn)，然后將訪問的結(jié)果通過 IPC 轉(zhuǎn)發(fā)給渲染進(jìn)程。安全沙箱最小的保護(hù)單位是進(jìn)程。因?yàn)閱芜M(jìn)程瀏覽器需要頻繁訪問或者修改操作系統(tǒng)的數(shù)據(jù)，所以單進(jìn)程瀏覽器是無法被安全沙箱保護(hù)的，而現(xiàn)代瀏覽器采用的多進(jìn)程架構(gòu)使得安全沙箱可以發(fā)揮作用。

安全沙箱影響的模塊功能

持久存儲

存儲 Cookie 數(shù)據(jù)的讀寫。通常瀏覽器內(nèi)核會維護(hù)一個(gè)存放所有 Cookie 的 Cookie 數(shù)據(jù)庫，然后當(dāng)渲染進(jìn)程通過 JavaScript 來讀取 Cookie 時(shí)，渲染進(jìn)程會通過 IPC 將讀取 Cookie 的信息發(fā)送給瀏覽器內(nèi)核，瀏覽器內(nèi)核讀取 Cookie 之后再將內(nèi)容返回給渲染進(jìn)程。一些緩存文件的讀寫也是由瀏覽器內(nèi)核實(shí)現(xiàn)的，比如網(wǎng)絡(luò)文件緩存的讀取。

網(wǎng)絡(luò)訪問

同樣有了安全沙箱的保護(hù)，在渲染進(jìn)程內(nèi)部也是不能直接訪問網(wǎng)絡(luò)的，如果要訪問網(wǎng)絡(luò)，則需要通過瀏覽器內(nèi)核。不過瀏覽器內(nèi)核在處理 URL 請求之前，會檢查渲染進(jìn)程是否有權(quán)限請求該 URL，比如檢查 XMLHttpRequest 或者 Fetch 是否是跨站點(diǎn)請求，或者檢測 HTTPS 的站點(diǎn)中是否包含了 HTTP 的請求。

用戶交互

為了限制渲染進(jìn)程有監(jiān)控到用戶輸入事件的能力，所以所有的鍵盤鼠標(biāo)事件都是由瀏覽器內(nèi)核來接收的，然后瀏覽器內(nèi)核再通過 IPC 將這些事件發(fā)送給渲染進(jìn)程。

渲染進(jìn)程需要渲染出位圖。為了向用戶顯示渲染進(jìn)程渲染出來的位圖，渲染進(jìn)程需要將生成好的位圖發(fā)送到瀏覽器內(nèi)核，然后瀏覽器內(nèi)核將位圖復(fù)制到屏幕上。

操作系統(tǒng)沒有將用戶輸入事件直接傳遞給渲染進(jìn)程，而是將這些事件傳遞給瀏覽器內(nèi)核。然后瀏覽器內(nèi)核再根據(jù)當(dāng)前瀏覽器界面的狀態(tài)來判斷如何調(diào)度這些事件，如果當(dāng)前焦點(diǎn)位于瀏覽器地址欄中，則輸入事件會在瀏覽器內(nèi)核內(nèi)部處理;如果當(dāng)前焦點(diǎn)在頁面的區(qū)域內(nèi)，則瀏覽器內(nèi)核會將輸入事件轉(zhuǎn)發(fā)給渲染進(jìn)程。

站點(diǎn)隔離

所謂站點(diǎn)隔離是指 Chrome 將同一站點(diǎn)(包含了相同根域名和相同協(xié)議的地址)中相互關(guān)聯(lián)的頁面放到同一個(gè)渲染進(jìn)程中執(zhí)行。由于最初都是按照標(biāo)簽頁來劃分渲染進(jìn)程的，所以如果一個(gè)標(biāo)簽頁里面有多個(gè)不同源的 iframe，那么這些 iframe 也會被分配到同一個(gè)渲染進(jìn)程中，這樣就很容易讓黑客通過 iframe 來攻擊當(dāng)前渲染進(jìn)程。而站點(diǎn)隔離會將不同源的 iframe 分配到不同的渲染進(jìn)程中，這樣即使黑客攻擊惡意 iframe 的渲染進(jìn)程，也不會影響到其他渲染進(jìn)程的。

作者：一只菜鳥攻城獅啊

鏈接：https://www.cnblogs.com/suihang/p/13271872.html