摘要：書接上文瀏覽器之引擎本章主要講解瀏覽器安全機制的網(wǎng)頁的安全和瀏覽器的安全。總結瀏覽器的安全機制包括網(wǎng)頁安全模型和沙箱模型其中網(wǎng)頁安全模型就是利用了同源策略，讓不同域中的網(wǎng)頁不能相互訪問，當然有好幾種瀏覽器跨域的方法可以其相互訪問。

此文章是我最近在看的【W(wǎng)ebKit 技術內(nèi)幕】一書的一些理解和做的筆記。

而【W(wǎng)ebKit 技術內(nèi)幕】是基于 WebKit 的 Chromium 項目的講解。

書接上文 瀏覽器之 javaScript 引擎

本章主要講解 瀏覽器安全機制的網(wǎng)頁的安全和瀏覽器的安全。

當用戶訪問網(wǎng)頁的時候，瀏覽器需要確保該網(wǎng)頁中數(shù)據(jù)的安全性，如 Cookie、用戶名和密碼等信息不會被其他的惡意網(wǎng)頁所獲取。

HTML5 定義了一系列安全機制來保證網(wǎng)頁瀏覽的安全性，這構成了網(wǎng)頁的安全模型。

域（Origin）表示的是網(wǎng)頁所在的域名、傳輸協(xié)議和端口（Port）等信息，是表明網(wǎng)頁身份的重要標識。

例如：“http://blog.csdn.net/milado_nju”，那么

域是 “http://blog.csdn.net”

“http:” 是協(xié)議（Protocol）

“blog.csdn.net” 是域名（Domain）

端口是默認的 80

根據(jù)安全模型的定義，不同域中網(wǎng)頁間的資源訪問是受到嚴格的限制的，也就是網(wǎng)頁的 DOM 對象、個人數(shù)據(jù)、XMLHttpRequest 等需要受到控制。

默認情況下，不同網(wǎng)頁間的這些數(shù)據(jù)是被瀏覽器隔離的，不能相互訪問，這就是 HTML 的 “Same origin Policy” 策略。

因為這些策略的限制，所以如果有兩個網(wǎng)頁，只要協(xié)議、域名、端口 三個其中有一個不一樣，就是不同的域。

唯一允許的條件是 這兩個網(wǎng)頁在同一域中，根據(jù)規(guī)范的定義，當且僅當它們的協(xié)議、域名和端口都相同的情況下，瀏覽器才會允許它們之間相互訪問。

在 HTML 解釋器中，HTMl 構建 DOM 的過程中，WebKit 使用一個叫做 XSSAuditor 的類來做安全方面的檢查，它的作用是防止 XSS 攻擊的。

XSS 全稱是 Cross Site Scripting，其含義是 執(zhí)行跨域的 JavaScript 腳本代碼。

執(zhí)行腳本這本身沒什么問題，但是，由于執(zhí)行其他域的腳本代碼可能存在嚴重的危害，還有可能會盜取當前域中的各種數(shù)據(jù)。

假如用戶不小心單擊如下的鏈接：
“http://myweb.com/?”。

如果該網(wǎng)頁中存在漏洞，這段網(wǎng)址的輸入可能變成了代碼被注入網(wǎng)頁中，那么該網(wǎng)頁的信息將會被傳輸?shù)搅硗庖粋€域中去，其中主要的原因是瀏覽器將用戶的數(shù)據(jù)變成了可以執(zhí)行的代碼。

解決上面問題的一個典型的方法就是不信任任何來自用戶輸入的數(shù)據(jù)。對于上面的栗子，可以使用字符轉換，因為 “<>” 等字符在 HTML 中有特殊的含義，表示的是元素，所以開發(fā)都將用戶輸入的數(shù)據(jù)進行字符轉換，那就是將 “<” 轉換成 “ <；”，“>” 轉換成 “>；” 等，這樣瀏覽器就不會將它們作為代碼來執(zhí)行。

除了上面的攻擊的一個例子外，還有很多方法和手段會被用來攻擊網(wǎng)站的。

為此，標準組織和 WebKit 使用了大量的技術來避免各種攻擊的發(fā)生。

如，在 HTTP 消息頭中定義了一個名為 “X-XSS-Protection” 的字段，此時瀏覽器會打開防止 XSS 攻擊的過濾器，目前主要的瀏覽器都支持該技術。

Content Security Policy 是一種防止 XSS 攻擊的技術，它 使用 HTTP 消息頭 來指定網(wǎng)站或者網(wǎng)頁能夠標注哪些域中的哪些類型的資源被允許加載在該域的網(wǎng)頁中，包括 JavaScript、CSS、HTML Frames、字體、圖片和嵌入對象（如插件、Java Applet 等）。

在 HTTP 消息頭中，可以使用相應的字段來控制這些域和資源的訪問，其主要是服務器返回的 HTTP 消息頭。

根據(jù) “Same Origin Policy" 原則，瀏覽器做了很多限制以阻止跨域的訪問，所以跨域的資源共享又變成了一個問題。

標準組織為了適應現(xiàn)實的需要，制定了 CORS (Cross Origin Resource Sharing) 規(guī)范，也就是跨域資源共享，該規(guī)范也是借助于 HTTP 消息頭 并通過定義了一些字段來實現(xiàn)的，主要是 定義不同域之間交互數(shù)據(jù)的方式。

值得注意，CORS 和 CSP 規(guī)定的是不同領域的標準，處理的是不同的事情。

主要區(qū)別：

CSP 定義的是網(wǎng)頁自身能夠訪問的某些域和資源，而 CORS 定義的是一個網(wǎng)頁如何才能訪問被同源策略禁止的跨域資源，規(guī)定兩者交互的協(xié)議和方式。

當某個網(wǎng)頁希望訪問其他域資源的時候，就需要按照 CORS 定義的標準從一個域訪問另外一個域的數(shù)據(jù)。比如 一個網(wǎng)站 http://myweb.com 希望使用 http://blog.csdn.net 上的數(shù)據(jù)，這時就需要用到 CORS。

包含了 CORS 的消息頭不是簡單的 HTTP 消息頭，該消息請求在 CROS 里面被稱為 “Preflight” 消息請求。

CORS 使用的字段名和功能如表 12-2所示。

其類型可以分成請求端和響應端兩種。因為沒有必要每個 HTTP 消息頭都要包含這些類型，所以用 “Preflight” 請求來發(fā)送包含 CORS 字段的消息，而其他則是簡單的 HTTP 消息頭。

圖中的 “Access-Control-Max-Age” 則是表示 Prefight 請求的有效期，在有效期內(nèi)不需要重復發(fā)送 CORS 定義字段的消息。

為了解決 JavaScript 直接訪問其他域網(wǎng)頁的 DOM 結構問題，標準組織引入一個消息傳遞機制，就是 Cross Document Messaging。

Cross Document Messaging 定義的是通過 window.postMessage 接口讓 JavaScript 在不同域的文檔中傳遞消息成為可能。如 示例代碼 12-2

// http://myweb.com 中的 JavaScript 代碼：
contentWin.postMessage("Hello"，"http://blog.csdn.net")；

// http://blog.csdn.net/milado_nju 網(wǎng)頁中 JavaScript 代碼（假如可以的話）：
window.addEventListener("message",function(e){
  if (e.origin == "http://myweb.com" ){
    if (e.data == "Heello"){
      e.source.postMessage("Hello2", e.origin);
    }else{
      alert(e.data);
    }
  }
}, false);

該機制使用 “window” 對象的 postMessage 方法來傳遞給其他域網(wǎng)頁消息，該方法包含兩個參數(shù)，第一個是 消息內(nèi)容，第二個是需要對方的域信息。而在接收方，開發(fā)者在 JavaScript 代碼中注冊一個消息響應函數(shù)，如上面代碼所示，如果檢查出消息來自于 “http://myweb.com” ，那么就回復一個 “hello2” 消息，原理非常簡單。

在 http 時代，網(wǎng)頁的數(shù)據(jù)的傳輸都是使用明文方式，它們對誰都是可見的，所以對于隱私的數(shù)據(jù)，如密碼、銀行賬號信息等，就不能使用明文來傳輸了。

為此，Web 引入了安全的數(shù)據(jù)傳輸協(xié)議，這就是 HTTPS。

HTTPS 是在 HTTP 協(xié)議之上使用 SSL(Secure Socket Layer) 技術來對傳輸?shù)臄?shù)據(jù)進行加密，從而保證了數(shù)據(jù)的安全性。

SSL 協(xié)議是構建在 TCP 協(xié)議之上，應用層協(xié)議 HTTP 之下的。SSL 工作的主要流程是先進行服務器認證（認證服務器是安全可靠的），然后是用戶認證。

SSL協(xié)議主要是服務提供商對用戶信息保密的承諾，這有利于提供商而不利于消費者。

同時 SSl 還存在一些問題，如，只能提供交易中客戶與服務器間的雙方認證，在涉及多方的電子交易中，SSL 協(xié)議并不能協(xié)調(diào)各方間的安全傳輸和信任關系。

TLS （Transport Layer Security）是在 SSL3.0 基礎之上發(fā)展起來的，它使用了新的加密算法，所以它同 HTTPS 之間并不兼容。TLS 用于兩個通信應用程序之間，提供保密性和數(shù)據(jù)完整性，該協(xié)議是由兩個子協(xié)議組成的，包括 TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。較低的層為 TLS 記錄協(xié)議，位于 TCP 協(xié)議之上。

因為如果瀏覽器運行的主機代碼被入侵了，通過一些手段或者瀏覽器中的漏洞，這些代碼可能獲取了主機的管理權限，對主機系統(tǒng)來說是非常危險的。

所以，除了保證網(wǎng)頁本身之外，還需要保證瀏覽器和瀏覽器所在的系統(tǒng)不存在危險。

如果有一種機制，將網(wǎng)頁運行限制在一個特定的環(huán)境中，也就是一個沙箱中，使它只能訪問有限的功能。 那么，即使網(wǎng)頁工作的渲染引擎被攻擊，它也不能夠獲取渲染引擎工作的主機系統(tǒng)中的任何權限，這一思想就是沙箱模型。

WebKit 中并沒有提供沙箱機制的支持，是 Chromium 支持沙箱的實現(xiàn)方式。

Chromium 是以多進程為基礎的，網(wǎng)頁的渲染在一個獨立的 Renderer 進程中進行，這為實現(xiàn)沙箱模型提供了基礎，因為可以相對容易地使用一些技術將整個網(wǎng)頁的渲染過程放在一個受限的進程中來完成，如圖 12-7 所示，愛限環(huán)境只能被某些或者很少的系統(tǒng)調(diào)用而且不能直接訪問用戶數(shù)據(jù)。而沙箱模型工作的基本單位就是進程。

Chromium 的沙箱模型是 利用系統(tǒng)提供的安全技術，讓網(wǎng)頁在執(zhí)行過程中不會修改操作系統(tǒng)或者是訪問系統(tǒng)中的隱私數(shù)據(jù)，而需要訪問系統(tǒng)資源或者說是系統(tǒng)調(diào)用的時候，通過一個代理機制來完成。

因為沙箱模型嚴重依賴操作系統(tǒng)提供的技術，而不同操作系統(tǒng)提供的安全技術是不一樣的，所以不同操作系統(tǒng)上的實現(xiàn)是不一致的。不管是 LInux、Windows、還是其他平臺， Chromium 都是在進程的粒度下來實現(xiàn)沙箱模型，也就是說需要運行在沙箱下的操作都在一個多帶帶的進程中。所以，對于使用沙箱模型至少需要兩個進程。如 12-8。

目標進程就是需要在沙箱中運行的代碼。

代理進程是 需要負責創(chuàng)建目標進程并為目標進程設置各種安全策略，同時建立 IPC 連接，接受目標進程的各種請求，因為目標進程是不能訪問過多資源的。

瀏覽器的安全機制包括 網(wǎng)頁安全模型 和 沙箱模型

其中 網(wǎng)頁安全模型 就是利用了同源策略，讓不同域中的網(wǎng)頁不能相互訪問，當然有好幾種瀏覽器跨域的方法可以其相互訪問。

而沙箱模型則是利用了 Chromium 實現(xiàn)的，利用 代理進程 來創(chuàng)建獨立的環(huán)境讓 目標進程 在當中安全運行。

Chrom 引入的沙箱機制極大地降低了網(wǎng)頁中各種破壞操作系統(tǒng)的潛在風險，將網(wǎng)頁執(zhí)行置于一個孤立（Isolated）和受限制（Strict）的環(huán)境中。

希望本文對你有點幫助。

對 全棧開發(fā) 有興趣的朋友可以掃下方二維碼關注我的公眾號

微信公眾號：愛寫bugger的阿拉斯加
分享 web 開發(fā)相關的技術文章，熱點資源，全棧程序員的成長之路，大家一起交流成長。

只要關注公眾號并回復 福利 便免費送你六套視頻資源，絕對干貨。

福利詳情請點擊： 免費資源分享——Python、Java、Linux、Go、node、vue、react、javaScript