32 | 同源策略：爲什麼XMLHttpRequest不能跨域請求資源？
瀏覽器安全可以分爲三大塊--Web頁面安全、瀏覽器網絡安全、瀏覽器系統安全。
本節來分析頁面中的安全策略。在沒有安全保障的 Web 世界中，我們是沒有隱私的，因此需要安全策略來保障我們的隱私和數據的安全。這就引出了頁面中最基礎、最核心的安全策略：
同源策略（Same-origin policy）。
什麼是同源策略
如果兩個 URL 的協議、域名和端口都相同，我們就稱這兩個 URL 同源.
瀏覽器默認兩個相同的源之間是可以相互訪問資源和操作 DOM 的。兩個不同的源之間若想要相互訪問資源或者操作 DOM，那麼會有一套基礎的安全策略的制約，我們把這稱爲同源策略。
具體來講，同源策略主要表現在 DOM、Web 數據和網絡這三個層面。
- 第一個：DOM層面。同源策略限制了來自不同源的 JavaScript 腳本對當前 DOM 對象讀和寫的操作。
- 第二個：數據層面。同源策略限制了不同源的站點讀取當前站點的 Cookie、IndexDB、LocalStorage 等數據。
- 第三個，網絡層面。同源策略限制了通過 XMLHttpRequest 等方式將站點的數據發送給不同源的站點。
安全和便利性的權衡
瀏覽器出讓了同源策略的一些安全性。
1. 頁面中可以嵌入第三方資源
頁面中可以嵌入第三方資源，但是卻有可能嵌入的是惡意代碼，惡意讀取Cookie等數據，於是瀏覽器中引入了內容安全策略，稱爲CSP。
CSP 的核心思想是讓服務器決定瀏覽器能夠加載哪些資源，讓服務器決定瀏覽器是否能夠執行內聯 JavaScript 代碼。
2. 跨域資源共享和跨文檔消息機制
爲了解決不同源的資源不能共享問題，引入了
跨域資源共享(CORS)，使用該機制可以進行跨域訪問控制，從而使跨域數據傳輸得以安全進行。
在介紹同源策略時，我們說明了如果兩個頁面不是同源的，則無法相互操縱 DOM。不過在實際應用中，經常需要兩個不同源的 DOM 之間進行通信，於是瀏覽器中又引入了跨文檔消息機制，可以通過 window.postMessage 的 JavaScript 接口來和不同源的 DOM 進行通信。
33 | 跨站腳本攻擊(XSS):爲什麼Cookie中有HttpOnly屬性？
通過上一節我們知道：同源策略可以隔離各個站點之間的 DOM 交互、頁面數據和網絡通信，雖然嚴格的同源策略會帶來更多的安全，但是也束縛了 Web。這就需要在安全和自由之間找到一個平衡點，所以我們默認頁面中可以引用任意第三方資源，然後又引入 CSP 策略來加以限制；默認 XMLHttpRequest 和 Fetch 不能跨站請求資源，然後又通過 CORS 策略來支持其跨域。不過支持頁面中的第三方資源引用和 CORS 也帶來了很多安全問題，其中最典型的就是 XSS 攻擊。
什麼是XSS攻擊
XSS 全稱是 Cross Site Scripting，爲了與“CSS”區分開來，故簡稱 XSS，翻譯過來就是“跨站腳本”。XSS 攻擊是指黑客往 HTML 文件中或者 DOM 中注入惡意腳本，從而在用戶瀏覽頁面時利用注入的惡意腳本對用戶實施攻擊的一種手段。
惡意腳本可以做哪些事情呢？
- 可以獲取Cookie消息。
- 可以監聽用戶行爲。
- 可以通過修改DOM僞造假的登錄窗口，用來欺騙用戶輸入用戶名和密碼等信息。
- 還可以在頁面內生成浮窗廣告。
惡意腳本是怎麼注入的
常見的注入方式有：存儲型XSS攻擊、反射型XSS攻擊、基於DOM的XSS攻擊。
如何阻止XSS攻擊
- 服務器對輸入腳本進行過濾或轉碼。
- 充分利用CSP。
- 使用 HttpOnly 屬性。
34 | CSRF攻擊：陌生鏈接不要點
在上一節中我們簡單瞭解了 XSS 攻擊，XSS 的攻擊方式是黑客往用戶的頁面中注入惡意腳本，然後再通過惡意腳本將用戶頁面的數據上傳到黑客的服務器上，最後黑客再利用這些數據進行一些惡意操作。XSS 攻擊能夠帶來很大的破壞性，不過另外一種類型的攻擊也不容忽視，它就是 CSRF 攻擊。
什麼是CSRF攻擊
CSRF 英文全稱是 Cross-site request forgery，所以又稱爲“跨站請求僞造”，是指黑客引誘用戶打開黑客的網站，在黑客的網站中，利用用戶的登錄狀態發起的跨站請求。簡單來講，CSRF 攻擊就是黑客利用了用戶的登錄狀態，並通過第三方的站點來做一些壞事。
黑客有三種方式實施CSRF攻擊：
- 自動發起Get請求。
- 自動發起POST請求。
- 引誘用戶點擊鏈接。
和 XSS 不同的是，CSRF 攻擊不需要將惡意代碼注入用戶的頁面，僅僅是利用服務器的漏洞和用戶的登錄狀態來實施攻擊。
如何防止CSRF攻擊
發起 CSRF 攻擊的三個必要條件：
- 第一個，目標站點一定要有 CSRF 漏洞；
- 第二個，用戶要登錄過目標站點，並且在瀏覽器上保持有該站點的登錄狀態；
- 第三個，需要用戶打開一個第三方站點，可以是黑客的站點，也可以是一些論壇。
要讓服務器避免遭受到 CSRF 攻擊，通常有以下幾種途徑:
- 充分利用好Cookie的SameSite屬性。SameSite選項通常有Strict、Lax、None三個值。
- Strict最爲嚴格，舉個例子，黑客從他的網站去去訪問你網站的資源，如果你的網站的某些Cookie設置了SamteSite = Strict，那麼在黑客網站上的Cookie是不會發送到你的網站上的，只有你從你的站點去請求你站點的資源，纔會帶上這些Cookie。
- Lax相對寬鬆，在跨站點的情況下，從第三方站點的鏈接打開和從第三方站點提交 Get 方式的表單這兩種方式都會攜帶 Cookie。但如果在第三方站點中使用 Post 方法，或者通過 img、iframe 等標籤加載的 URL，這些場景都不會攜帶 Cookie。
- 而如果使用 None 的話，在任何情況下都會發送 Cookie 數據。
驗證請求的來源站點
服務器可以禁止來自第三方站點的請求。那麼該怎麼判斷請求是否來自第三方站點呢？這裏介紹的是HTTP請求頭中的Referer和Origin屬性。
Referer是HTTP請求頭中的一個字段，記錄了該HTTP請求的來源地址,會包含具體的 URL 路徑。
雖然可以通過 Referer 告訴服務器 HTTP 請求的來源，但是有一些場景是不適合將來源 URL 暴露給服務器的，因此瀏覽器提供給開發者一個選項，可以不用上傳 Referer 值，具體可參考 Referrer Policy。
但在服務器端驗證請求頭中的 Referer 並不是太可靠，因此標準委員會又制定了Origin屬性，在一些重要的場合，比如通過 XMLHttpRequest、Fecth 發起跨站請求或者通過 Post 方法發送請求時，都會帶上 Origin 屬性.
Origin 屬性只包含了域名信息，並沒有包含具體的 URL 路徑.CSRF Token
第一步，在瀏覽器向服務器發起請求時，服務器生成一個 CSRF Token。CSRF Token 其實就是服務器生成的字符串，然後將該字符串植入到返回的頁面中。
第二步，在瀏覽器端如果要發起轉賬的請求，那麼需要帶上頁面中的 CSRF Token，然後服務器會驗證該 Token 是否合法。如果是從第三方站點發出的請求，那麼將無法獲取到 CSRF Token 的值，所以即使發出了請求，服務器也會因爲 CSRF Token 不正確而拒絕請求。
35 | 安全沙箱：頁面和系統之間的隔離牆
安全視角下的多進程架構
我們通過學習第一節《宏觀視角下的瀏覽器》，瞭解了瀏覽器的發展史以及架構的演變，這節是從操作系統安全的視角來看瀏覽器的多進程架構的。
瀏覽器是被劃分爲瀏覽器內核和渲染內核兩個核心模塊，其中瀏覽器內核是由網絡進程、瀏覽器主進程和GPU主進程組成的。渲染內核就是渲染進程。這兩個模塊通過IPC來通信。
瀏覽器多進程架構的設計不單單是爲了增加其穩定性，重要的一點也是因爲從安全角度去考慮、設計的。
安全沙箱
基於安全原因(主要是爲防止危險資源獲取系統權限)，在渲染進程和操作系統之間建了一道牆，即便渲染進程由於存在漏洞被黑客攻擊，但由於這道牆，黑客就獲取不到渲染進程之外的任何操作權限。將渲染進程和操作系統隔離的這道牆就是安全沙箱。
瀏覽器中的安全沙箱是利用操作系統提供的安全技術，讓渲染進程在執行過程中無法訪問或者修改操作系統中的數據，在渲染進程需要訪問系統資源的時候，需要通過瀏覽器內核來實現，然後將訪問的結果通過 IPC 轉發給渲染進程。
安全沙箱最小的保護單位是進程。因爲單進程瀏覽器需要頻繁訪問或者修改操作系統的數據，所以單進程瀏覽器是無法被安全沙箱保護的，而現代瀏覽器採用的多進程架構使得安全沙箱可以發揮作用。
36 ｜ HTTPS：讓數據傳輸更安全
瀏覽器安全主要分爲三大塊內容：頁面安全、系統安全、網絡完全，本節主要學習網絡安全。
我們使用 HTTP 傳輸的內容很容易被中間人竊取、僞造和篡改，通常我們把這種攻擊方式稱爲中間人攻擊。
具體來講，在將HTTP數據提交給TCP後，數據會經過用戶電腦、WIFI路由器、運營商和目標服務器，在這中間的每個環節中，數據都有可能被竊取或篡改。
在HTTP協議棧中引入安全層
![]()
安全層有兩個主要的職責：對發起 HTTP 請求的數據進行加密操作和對接收到 HTTP 的內容進行解密操作.
我們知道了安全層最重要的就是加解密，那麼接下來我們就利用這個安全層，一步一步實現一個從簡單到複雜的 HTTPS 協議。第一版:使用對稱加密
提到加密，最簡單的方式是使用對稱加密。所謂對稱加密是指加密和解密都使用的是相同的密鑰。
將對稱加密加到安全層後，實現了第一版的對稱加密，但是其中傳輸的client-random和server-client的過程都是明文，所以黑客其實也是可以拿到並篡改的，因此此數據依然可以破解。第二版：使用非對稱加密
含義：和對稱加密只有一個密鑰不同，非對稱加密算法有 A、B 兩把密鑰，如果你用 A 密鑰來加密，那麼只能使用 B 密鑰來解密；反過來，如果你要 B 密鑰來加密，那麼只能用 A 密鑰來解密。
第三版：對稱加密和非對稱加密搭配使用
最終選擇了一個更加完美的方案，那就是在傳輸數據階段依然使用對稱加密，但是對稱加密的密鑰我們採用非對稱加密來傳輸.
第四版：添加數字證書
爲了防止黑客通過DNS劫持將用戶目標官網的IP地址進行更換，而需添加數字證書，該證書是服務器向瀏覽器證明“我”就是“我”。
小結
由於 HTTP 的明文傳輸特性，在傳輸過程中的每一個環節，數據都有可能被竊取或者篡改，這倒逼着我們需要引入加密機制。
於是我們在 HTTP 協議棧的 TCP 和 HTTP 層之間插入了一個安全層，負責數據的加密和解密操作。
我們使用對稱加密實現了安全層，但是由於對稱加密的密鑰需要明文傳輸，所以我們又將對稱加密改造成了非對稱加密。
但是非對稱加密效率低且不能加密服務器到瀏覽器端的數據，於是我們又繼續改在安全層，採用對稱加密的方式加密傳輸數據和非對稱加密的方式來傳輸密鑰，這樣我們就解決傳輸效率和兩端數據安全傳輸的問題。
採用這種方式雖然能保證數據的安全傳輸，但是依然沒辦法證明服務器是可靠的，於是又引入了數字證書，數字證書是由 CA 簽名過的，所以瀏覽器能夠驗證該證書的可靠性。
世界有多大，取決於你認識和見過多少人和事。
如有疑問請添加我的微信號：18231133236。歡迎交流！
更多內容，請訪問的我的個人博客：https://www.liugezhou.online.
您也可以關注我的個人公衆號：【Dangerous Wakaka】
