瀏覽器安全——Web頁面安全&瀏覽器網路安全(HTTPS)&瀏覽器系統安全

請移步：極客時間——瀏覽器中的安全

一、Web頁面安全

同源和跨域：

同源：
頁面中最基礎、最核心的安全策略：同源策略（Same-origin policy），瀏覽器默認兩個相同的源之間是可以相互訪問資源和操作 DOM 的，
什么是同源？如果兩個頁面擁有相同的協議、域名和埠，那么這兩個頁面具有相同的源，
同源政策：是瀏覽器提供的一個安全功能，是為了保證用戶資訊的安全，防止惡意的網站竊取資料，
同源策略主要表現在 DOM、Web 資料和網路這三個層面，
第一個，DOM 層面，同源策略限制了來自不同源的 JavaScript 腳本對當前 DOM 物件讀和寫的操作，（解決：跨檔案訊息機制：通過window.postMessage 的 JavaScript 介面來和不同源的 DOM 進行通信，）
第二個，資料層面，同源策略限制了不同源的站點讀取當前站點的 Cookie、IndexDB、LocalStorage 等資料，
第三個，網路層面，同源策略限制了通過 XMLHttpRequest 等方式將站點的資料發送給不同源的站點，
跨域：
什么是跨域？同源指的是兩個url的協議、域名、埠一致，反之則是跨域，出現的根本原因：由瀏覽器的同源策略導致，

如何解決跨域？實作跨域資料請求有三種解決方案：JSONP、CORS和通過自家服務器訪問別的服務器再回應回自家客戶端，

第三種方法：
腳手架配置代理

JSONP:
注意JSONP和Ajax之間沒有任何關系，不能把JSONP請求資料的方式叫做ajax,因為JSONP沒有用到XMLHttpRequest這個物件，
JSONP的實作原理：JSONP是JSON的一種“使用模式”

手寫JSONP（封裝JSONP）：

    <script>
        function jsonp(options){
            var script=document.createElement('script');
            var fnName='myJsonp'+Math.random().toString().replace('.','')
            window[fnName]=options.success;//.后面不能跟變數，只能跟屬性，所以用中括號
            var params='';
            for(let attr in options.data){
                params+='&'+attr+'='+options.data[attr];//jsonp屬于get請求
            }
            script.src=options.url+'?callback='+fnName+params;
            document.body.appendChild(script);
            script.onload=function(){
                document.body.removeChild(script);
            }
        }
        jsonp({
            url:'http://localhost:3001/better',
            data:{
                name:'lisi',
                age:19
            },
            success:function(data){
                console.log(data);
            }
        })

使用JSONP的風險：

CORS（cross origin resource sharing跨域資源共享）：
它允許瀏覽器向跨域服務器發送Ajax請求，克服了瀏覽器的同源政策，（客戶端不做什么，主要是服務器端回應頭中做一些改動，設定哪些客戶端可以訪問服務器以及設定客戶端可以以哪種方式(get/post)訪問服務器）

總結：

1. 讀取資料和操作 DOM 要用跨檔案機制
2. 跨域請求（Ajax、fetch）要用 CORS 機制
3. 參考第三方資源要用內容安全策略：CSP（解決XSS攻擊）

跨站腳本攻擊（XSS）

支持頁面中的第三方資源參考和 CORS 也帶來了很多安全問題，其中最典型的就是 XSS 攻擊，
什么是XSS攻擊?XSS 全稱是 Cross Site Scripting，XSS攻擊是指黑客往HTML檔案或者DOM中注入惡意腳本，從而在用戶瀏覽頁面時利用注入的惡意腳本對用戶實施攻擊的一種手段，
惡意腳本能做的事情：

• 可以通過document.cookie竊取Cookie資訊，然后通過XMLHttpRequest 或者 Fetch 加上CORS 功能將資料發送給惡意服務器，惡意服務器拿到用戶的 Cookie 資訊之后，就可以在其他電腦上模擬用戶的登錄，然后進行轉賬等操作；
• 可以監聽用戶行為，惡意 JavaScript 可以使用“addEventListener”介面來監聽鍵盤事件，比如可以獲取用戶輸入的信用卡等資訊，將其發送到惡意服務器，
• 可以通過修改 DOM 偽造假的登錄視窗，用來欺騙用戶輸入用戶名和密碼等資訊，
• 可以在頁面內生成浮窗廣告，這些廣告會嚴重地影響用戶體驗，

常見的注入惡意腳本的方式：存盤型XSS攻擊、反射性XSS攻擊、基于DOM的XSS攻擊，
1，存盤型XSS攻擊

攻擊步驟：
首先黑客利用站點漏洞將一段惡意 JavaScript 代碼提交到網站的資料庫中；
然后用戶向網站請求包含了惡意 JavaScript 腳本的頁面；
當用戶瀏覽該頁面的時候，惡意腳本就會將用戶的 Cookie 資訊等資料上傳到服務器
2，反射型XSS攻擊
在一個反射型 XSS 攻擊程序中，惡意 JavaScript 腳本屬于用戶發送給網站請求中的一部分，黑客通過各種方式誘導用戶去點擊惡意鏈接，隨后網站又把惡意 JavaScript 腳本回傳給用戶，當惡意 JavaScript 腳本在用戶頁面中被執行時，黑客就可以利用該腳本做一些惡意操作，
Web 服務器不會存盤反射型 XSS 攻擊的惡意腳本，這是和存盤型 XSS 攻擊不同的地方，
3，基于DOM的XSS攻擊
基于 DOM 的 XSS 攻擊是不牽涉到頁面 Web 服務器的，具體來講，黑客通過各種手段將惡意腳本注入用戶的頁面中，比如通過網路劫持在頁面傳輸程序中修改 HTML 頁面的內容，這種劫持型別很多，有通過 WiFi 路由器劫持的，有通過本地惡意軟體來劫持的，它們的共同點是在 Web 資源傳輸程序或者在用戶使用頁面的程序中修改 Web 頁面的資料，

如何阻止XSS攻擊？
我們知道存盤型 XSS 攻擊和反射型 XSS 攻擊都是需要經過 Web 服務器來處理的，因此可以認為這兩種型別的漏洞是服務端的安全漏洞，而基于 DOM 的 XSS 攻擊全部都是在瀏覽器端完成的，因此基于 DOM 的 XSS 攻擊是屬于前端的安全漏洞，
但無論是何種型別的 XSS 攻擊，它們都有一個共同點，那就是首先往瀏覽器中注入惡意腳本，然后再通過惡意腳本將用戶資訊發送至黑客部署的惡意服務器上，
所以要阻止 XSS 攻擊，我們可以通過阻止惡意 JavaScript 腳本的注入和阻止惡意訊息的發送來實作，
常見策略：

• 服務器對輸入腳本進行過濾或轉碼
• 充分利用CSP
  CSP 的核心思想是讓服務器決定瀏覽器能夠加載哪些資源，讓服務器決定瀏覽器是否能夠執行行內 JavaScript 代碼，
  CSP 有如下幾個功能：
  限制加載其他域下的資源檔案，這樣即使黑客插入了一個 JavaScript 檔案，這個 JavaScript檔案也是無法被加載的；
  禁止向第三方域提交資料，這樣用戶資料也不會外泄；
  禁止執行行內腳本和未授權的腳本；
  還提供了上報機制，這樣可以幫助我們盡快發現有哪些XSS 攻擊，以便盡快修復問題，
• 使用HttpOnly屬性
  由于很多 XSS 攻擊都是來盜用 Cookie 的，服務器可以將某些 Cookie 設定為 HttpOnly 標志，HttpOnly 是服務器通過 HTTP 回應頭來設定的，set-cookie 屬性值最后使用了 HttpOnly 來標記該 Cookie，顧名思義，使用 HttpOnly 標記的 Cookie 只能使用在 HTTP 請求程序中，所以無法通過 JavaScript 來讀取這段 Cookie（document.cookie)，

當然除了以上策略之外，我們還可以通過添加驗證碼防止腳本冒充用戶提交危險操作，而對于一些不受信任的輸入，還可以限制其輸入長度，這樣可以增大 XSS 攻擊的難度，

CSRF攻擊

什么是CSRF攻擊？
CSRF 英文全稱是 Cross-site request forgery，所以又稱為“跨站請求偽造”，是指黑客引誘用戶打開黑客的網站，在黑客的網站中，利用用戶的登錄狀態發起的跨站請求，簡單來講，CSRF 攻擊就是黑客利用了用戶的登錄狀態，并通過第三方的站點來做一些壞事，
通常當用戶打開了黑客的頁面后，黑客有三種方式去實施 CSRF 攻擊：
1，自動發起Get請求
舉例，在黑客的頁面中，有一張圖片的src對應的鏈接是一個轉賬的api，當用戶被引誘進入了黑客的頁面，頁面被加載的時候，瀏覽器會自動發器img的資源請求，同時，借用用戶的登錄狀態，就完成了這個轉賬的操作，
2,自動發起POST請求
舉例，在黑客的頁面中，有一個隱藏的表單，表單的內容為轉賬的api，當用戶進入這個頁面，表單被自動提交，服務器就會執行轉賬操作，
3，引誘用戶點擊鏈接
舉例，通過引誘用戶點擊某個黑客的鏈接，該鏈接為轉賬的api，一旦點擊鏈接，服務器就會執行轉賬操作，

和 XSS 不同的是，CSRF 攻擊不需要將惡意代碼注入用戶的頁面，因此黑客是無法通過 CSRF 攻擊來獲取用戶頁面資料的；僅僅是利用服務器的漏洞和用戶的登錄狀態來實施攻擊，所以要提高服務器安全性，

如何防止CSRF攻擊？
發起 CSRF 攻擊的三個必要條件：
第一個，目標站點一定要有 CSRF 漏洞；
第二個，用戶要登錄過目標站點，并且在瀏覽器上保持有該站點的登錄狀態；第三個，需要用戶打開一個第三方站點，可以是黑客的站點，也可以是一些論壇，
要讓服務器避免遭受到 CSRF 攻擊，通常有以下幾種途徑：

• 充分利用好 Cookie 的 SameSite 屬性：
  原理：Cookie 是瀏覽器和服務器之間維護登錄狀態的一個關鍵資料實作從第三方站點發送請求時禁止 Cookie 的發送，因此在瀏覽器通過不同來源發送 HTTP 請求時，有如下區別：如果是從第三方站點發起的請求，那么需要瀏覽器禁止發送某些關鍵 Cookie 資料到服務器；如果是同一個站點發起的請求，那么就需要保證 Cookie 資料正常發送，在 HTTP 回應頭中，通過 set-cookie 欄位設定 Cookie 時，可以帶上 SameSite 選項，SameSite 選項通常有三個值：Strict：最為嚴格，瀏覽器會完全禁止第三方 Cookie，比如，如果你從 RANGE 的頁面中訪問 SIRIUS 的資源，而 SIRIUS 的某些 Cookie 設定了 SameSite = Strict 的話，那么這些 Cookie 是不會被發送到 SIRIUS 的服務器上的，只有你從 SIRIUS 的站點去請求 SIRIUS 的資源時，才會帶上這些 Cookie，Lax：相對寬松一點，在跨站點的情況下，從第三方站點的鏈接打開和從第三方站點提交 Get 方式的表單這兩種方式都會攜帶 Cookie，但如果在第三方站點中使用 Post 方法，或者通過 img、iframe 等標簽加載的 URL，這些場景都不會攜帶 Cookie，None：在任何情況下都會發送 Cookie 資料，
• 在服務器端驗證請求來源的站點
  由于 CSRF 攻擊大多來自于第三方站點，因此服務器可以禁止來自第三方站點的請求，那么該怎么判斷請求是否來自第三方站點呢？根據HTTP 請求頭中的 Referer 和 Origin 屬性，服務器的策略是優先判斷 Origin，如果請求頭中沒有包含 Origin 屬性，再根據實際情況判斷是否使用 Referer 值，
• CSRF Token
  第一步，在瀏覽器向服務器發起請求時，服務器生成一個 CSRF Token，CSRF Token 其實就是服務器生成的字串，然后將該字串植入到回傳的頁面中；第二步，在瀏覽器端如果要發起轉賬的請求，那么需要帶上頁面中的 CSRF Token，然后服務器會驗證該 Token 是否合法，如果是從第三方站點發出的請求，那么將無法獲取到 CSRF Token 的值，所以即使發出了請求，服務器也會因為 CSRF Token 不正確而拒絕請求，

總結：
頁面安全問題的主要原因就是瀏覽器為同源策略開的兩個“后門”：一個是在頁面中可以任意參考第三方資源，另外一個是通過 CORS 策略讓 XMLHttpRequest 和 Fetch 去跨域請求資源，

二、瀏覽器網路安全

網路安全協議HTTPS
HTTP是明文傳輸，使用 HTTP 傳輸的內容很容易被中間人竊取、偽造和篡改，通常我們把這種攻擊方式稱為中間人攻擊，
所以在 HTTP 協議堆疊中引入安全層：

從圖中我們可以看出 HTTPS 并非是一個新的協議，通常 HTTP 直接和 TCP 通信，HTTPS 則先和安全層通信，然后安全層再和 TCP 層通信，也就是說 HTTPS 所有的安全核心都在安全層，它不會影響到上面的 HTTP 協議，也不會影響到下面的 TCP/IP，因此要搞清楚 HTTPS 是如何作業的，就要弄清楚安全層是怎么作業的，總的來說，安全層有兩個主要的職責：對發起 HTTP 請求的資料進行加密操作和對接收到 HTTP 的內容進行解密操作，
第一版：使用對稱加密
所謂對稱加密是指加密和解密都使用的是相同的密鑰，
第二版：使用非對稱加密（公鑰和私鑰）
第三版：對稱加密和非對稱加密搭配使用
在傳輸資料階段依然使用對稱加密，但是對稱加密的密鑰我們采用非對稱加密來傳輸，
第四版：添加數字證書
HTTPS握手程序：
HTTPS（TLS握手程序）&TCP協議（三次握手四次揮手）

HTTPS連接中接收/發送HTTP資料包會怎么樣？
會怎么樣：
HTTPS會不高興，瀏覽器也會不高興，
阻止掉HTTP的AJAX請求，然后報一個Mixed Content的錯誤（黃色的警告），
引入一個HTTP請求的 js 檔案，會被瀏覽器直接 block 掉，
解決方案：
相對協議：將URL的協議（http、https）去掉，只保留//及后面的內容，
iframe：使用 iframe 的方式引入 http 資源

三、瀏覽器系統安全

瀏覽器的單行程架構的不足：
瀏覽器本身的漏洞是單行程瀏覽器的一個主要問題，如果瀏覽器被曝出存在漏洞，那么在這些漏洞沒有被及時修復的情況下，黑客就有可能通過惡意的頁面向瀏覽器中注入惡意程式，其中最常見的攻擊方式是利用緩沖區溢位，不過需要注意這種型別的攻擊和 XSS 注入的腳本是不一樣的，XSS 攻擊只是將惡意的 JavaScript 腳本注入到頁面中，雖然能竊取一些 Cookie 相關的資料，但是 XSS 無法對作業系統進行攻擊，而通過瀏覽器漏洞進行的攻擊是可以入侵到瀏覽器行程內部的，可以讀取和修改瀏覽器行程內部的任意內容，還可以穿透瀏覽器，在用戶的作業系統上悄悄地安裝惡意軟體、監聽用戶鍵盤輸入資訊以及讀取用戶硬碟上的檔案內容，
瀏覽器的多行程架構：

將渲染行程和作業系統隔離的這道墻就是安全沙箱，
瀏覽器中的安全沙箱是利用作業系統提供的安全技術，讓渲染行程在執行程序中無法訪問或者修改作業系統中的資料，在渲染行程需要訪問系統資源的時候，需要通過瀏覽器內核來實作，然后將訪問的結果通過 IPC 轉發給渲染行程，安全沙箱最小的保護單位是行程，因為單行程瀏覽器需要頻繁訪問或者修改作業系統的資料，所以單行程瀏覽器是無法被安全沙箱保護的，而現代瀏覽器采用的多行程架構使得安全沙箱可以發揮作用，
我們知道安全沙箱最小的保護單位是行程，并且能限制行程對作業系統資源的訪問和修改，這就意味著如果要讓安全沙箱應用在某個行程上，那么這個行程必須沒有讀寫作業系統的功能，比如讀寫本地檔案、發起網路請求、呼叫 GPU 介面等，
瀏覽器內核和渲染行程各自職責：

通過該圖，我們可以看到由于渲染行程需要安全沙箱的保護，因此需要把在渲染行程內部涉及到和系統互動的功能都轉移到瀏覽器內核中去實作，