Web 應用安全性: 瀏覽器是如何工做的

時間 2019-11-08

標籤 web 應用安全性瀏覽器如何欄目 HTML 简体版

原文原文鏈接

這本系列的第一篇，先解釋瀏覽器的功能以及執行方式。因爲大多數客戶將經過瀏覽器與 web 應用程序進行交互，所以必須瞭解這些出色程序的基礎知識。html

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等着你！前端

瀏覽器是一個渲染引擎，它的工做是下載一個web頁面，並以人類可以理解的方式渲染它。git

雖然這幾乎是一種過於簡單的過度簡化，但咱們如今須要知道的所有內容。github

用戶在瀏覽器欄中輸入一個地址。
瀏覽器從該 URL 下載「文檔」並渲染它。

你可能習慣使用 Chrome，Firefox，Edge或Safari等流行的瀏覽器之一，但這並不意味着沒有不一樣的瀏覽器。web

例如，lynx 是一種輕量級的、基於文本的瀏覽器，能夠在命令行中工做。lynx 的核心原理與其餘「主流」瀏覽器的原理徹底相同。用戶輸入 web 地址(URL)，瀏覽器獲取文檔並呈現它——惟一的區別是 lynx 不使用可視化渲染引擎，而是使用基於文本的界面，這使得像谷歌這樣的網站看起來像這樣:chrome

咱們大體瞭解瀏覽器的功能，可是讓咱們仔細看看這些機智的應用程序爲咱們所作的步驟。segmentfault

瀏覽器作了什麼?

長話短說，瀏覽器的工做主要包括:瀏覽器

DNS 解析
HTTP 交換
渲染
重複如下步驟

DNS 解析

這個過程確保一旦用戶輸入 URL，瀏覽器就知道它必須鏈接到哪一個服務器。瀏覽器聯繫 DNS 服務器，發現google.com 翻譯成 216.58.207.110，這是一個瀏覽器能夠鏈接的 IP 地址。安全

HTTP 交換

一旦瀏覽器肯定了哪一個服務器將爲咱們的請求提供服務，它將啓動與它的 TCP 鏈接並開始 HTTP 交換。這只是瀏覽器與服務器通訊所需內容以及服務器回覆的一種方式。服務器

HTTP 只是用於在 Web 上進行通訊協議的名稱，而瀏覽器通常經過 HTTP 與服務器進行通訊。 HTTP 交換涉及客戶端（咱們的瀏覽器）發送請求，服務器回覆響應。

例如，當瀏覽器成功鏈接到 google.com 背後的服務器後，它將發送一個以下所示的請求:

GET / HTTP/1.1
Host: google.com
Accept: */*

讓咱們一行一行地把請求分解:

GET / HTTP/1.1:在第一行中，並補充說其他請求將遵循 HTTP/1.1 協議（它也可使用1.0或2）
Host: google.com：這是 HTTP/1.1 中惟一必須的 HTTP 報頭。由於服務器可能服務多個域(google.com, google.co.uk) 。這裏的客戶端提到請求是針對特定的主機的。
Accept: */*：一個可選的標頭，其中瀏覽器告訴服務器接受任何類型的響應。服務器能夠擁有 JSON、XM L或HTML 格式的可用資源，所以它能夠選擇本身喜歡的格式。

做爲客戶端的瀏覽器發送請求以後，就輪到服務器進行響應了，這是響應的格式以下:

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly
<!doctype html><html">
...
...
</html>

哇，有不少信息須要消化。服務器讓咱們知道請求是成功的(200 OK)，並向響應中添加一些頭部信息，例如，它告知哪一個服務器處理了咱們的請求(Server:gws)，該響應的 X-XSS-Protection 策略是什麼，等等。

如今，你不須要理解響應中的每一行，在本系列後面的文章中，咱們將介紹 HTTP 協議及其頭部等內容。

如今，你只須要了解客戶端和服務器正在交換信息，而且它們是經過 HTTP 進行交換的。

渲染

<!doctype html><html">
...
...
</html>

在響應的主體中，服務器根據 Content-Type 頭包括響應類型來表示。在咱們的例子中，內容類型設置爲 text/ html，所以咱們期待響應中的 HTML 標記 - 這正是咱們在正文中找到的。

這纔是瀏覽器真正的亮點所在。它解析 HTML，加載標記中包含的額外資源(例如，可能須要獲取JavaScript文件或CSS文檔)，並儘快將它們呈現給用戶。

最終的結果是普通人可以理解的：

若是想要更詳細地瞭解當咱們在瀏覽器地址欄中按回車鍵時會發生什麼，建議閱讀「What happens when…」，這是一個很是精細的嘗試來解釋該過程背後的機制。

因爲這是一個關注安全性的系列文章，從剛剛瞭解到的內容能夠提到提示:攻擊者能夠輕鬆地利用 HTTP 交換和渲染部分中的漏洞謀生。漏洞和惡意用戶也潛伏在其餘地方，可是這些級別上更好的安全方法已經容許你在改進安全性方面取得進展。

供應商

4 個最流行的瀏覽器屬於不一樣的公司:

谷歌的 Chrome
Mozilla 的火狐
蘋果的 Safari
微軟的 Edge

除了爲了增長市場滲透率而相互競爭以外，供應商也爲了提升 web 標準而相互合做，這是對瀏覽器的一種「最低要求」。

W3C是標準開發的主體，可是瀏覽器開發本身的特性並最終成爲 web 標準的狀況並很多見，安全性也不例外。

例如，Chrome 51 引入了 SameSite cookie，該功能容許 Web 應用程序擺脫稱爲 CSRF 的特定類型的漏洞（稍後將詳細介紹）。其餘供應商認爲這是一個好主意，並紛紛效仿，致使 SameSite 成爲 web 標準:到目前爲止，Safari 是惟一沒有 SameSite cookie 支持的主流瀏覽器。

這告訴咱們兩件事:

Safari彷佛並不關心用戶的安全性（開玩笑：Safari 12中將提供SameSite cookie，這可能在你閱讀本文時已經發布）
修補一個瀏覽器上的漏洞並不意味着全部用戶都是安全的

第一點是對 Safari 的一次嘗試(正如我提到的，開玩笑的!)，而第二點很是重要。在開發web應用程序時，咱們不只須要確保它們在不一樣的瀏覽器中看起來是相同的，還須要確保咱們的用戶在不一樣的平臺上受到相同的保護。

你的網絡安全策略應根據瀏覽器供應商容許咱們執行的操做而有所不一樣。現在，大多數瀏覽器都支持相同的功能集，而且不多偏離其常見的路線圖，可是上面的實例仍然會發生，這是咱們在定義安全策略時須要考慮的事情。

在咱們的例子中，若是咱們決定只經過 SameSite cookie 來減輕 CSRF 攻擊，那麼咱們應該意識到咱們正在將 Safari 用戶置於危險之中。咱們的用戶也應該知道這一點。

最後但並不是最不重要,你應該記住,你能夠決定是否支持瀏覽器版本:支持每個瀏覽器版本將是不切實際的(想一想 Internet Explorer 6)。雖然確保最近幾個版本的主流瀏覽器的支持一般是一個好的決定，可是若是你不打算在特定的平臺上提供保護，通常建議讓你的用戶知道。

專業提示:你不該該鼓勵你的用戶使用過期的瀏覽器，或積極支持他們。儘管你可能已經採起了全部必要的預防措施，可是其餘web開發人員可能沒有。鼓勵用戶使用主流瀏覽器支持的最新版本。

供應商仍是標準bug?

普通用戶經過第三方客戶端（瀏覽器）訪問咱們的應用程序這一事實增長了另外一層次的間接性：瀏覽器自己可能存在安全漏洞。
‘
供應商一般會向可以發現瀏覽器自身漏洞的安全研究人員提供獎勵(即 bug獎金)。這些bug與你的實現無關，而是與瀏覽器自己處理安全性的方式有關。

例如，Chrome 獎勵計劃可以讓安全工程師與 Chrome 安全團隊聯繫，報告他們發現的漏洞。若是確認了這些漏洞，則會發布補丁，一般會向公衆發佈安全建議通知，研究人員會從該計劃中得到（一般是財務上的）獎勵。

像谷歌這樣的公司在他們的Bug賞金項目中投入了相對較多的資金，這使得他們可以經過承諾在發現應用程序的任何問題時得到經濟利益來吸引研究人員。

在一個漏洞賞金計劃中，每一個人都是贏家:供應商設法提升其軟件的安全性，研究人員也所以得到報酬。咱們將在後面討論這些程序，由於我相信Bug賞金計劃應該在安全領域有本身的一節。

Jake Archibald 是谷歌的一名開發人員，他最近發現了一個影響多個瀏覽器的漏洞。他在一篇有趣的博客文章中記錄了他的努力，他如何接觸不一樣的供應商，以及他們的反應，建議你閱讀這篇文章。

開發人員的瀏覽器

到目前爲止，咱們應該理解一個很是簡單但至關重要的概念：瀏覽器只是爲普通網絡衝浪者構建的 HTTP 客戶端。

它們確定比平臺的純HTTP客戶端更強大(例如，考慮NodeJS的require(‘HTTP’))，但歸根結底，它們「只是」更簡單的 HTTP客戶端的天然演化。

做爲開發人員，咱們選擇的HTTP客戶機多是 Daniel Stenberg 的 cURL，他是 web 開發人員天天使用的最流行的軟件程序之一。它容許咱們經過從命令行發送 HTTP 請求來實時執行 HTTP 交換:

$ curl -I localhost:8080
HTTP/1.1 200 OK
server: ecstatic-2.2.1
Content-Type: text/html
etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
last-modified: Fri, 20 Jul 2018 11:20:35 GMT
cache-control: max-age=3600
Date: Fri, 20 Jul 2018 11:21:02 GMT
Connection: keep-alive

在上面的示例中，咱們在 localhost:8080/ 上請求了文檔，本地服務器成功響應。

在這裏，咱們沒有將響應的主體顯示在命令行，而是使用了 -I 標誌，它告訴 cURL 咱們只對響應頭感興趣。更進一步，咱們能夠指示 cURL 顯示更多的信息，包括它執行的實際請求，以便更好地查看整個HTTP交換。須要使用的選項是-v(詳細):

$ curl -I -v localhost:8080
* Rebuilt URL to: localhost:8080/
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> HEAD / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< server: ecstatic-2.2.1
server: ecstatic-2.2.1
< Content-Type: text/html
Content-Type: text/html
< etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
< last-modified: Fri, 20 Jul 2018 11:20:35 GMT
last-modified: Fri, 20 Jul 2018 11:20:35 GMT
< cache-control: max-age=3600
cache-control: max-age=3600
< Date: Fri, 20 Jul 2018 11:25:55 GMT
Date: Fri, 20 Jul 2018 11:25:55 GMT
< Connection: keep-alive
Connection: keep-alive
<
* Connection #0 to host localhost left intact

主流瀏覽器經過它們的 DevTools 能夠得到幾乎相同的信息。

正如咱們所見，瀏覽器只不過是精心設計的HTTP客戶端。固然，他們添加了大量的功能（想到憑據管理，書籤，歷史等），但事實是，它們是做爲人類的 HTTP 客戶端而誕生的。這很重要，由於在大多數狀況下，不須要使用瀏覽器來測試Web應用程序的安全性，由於你能夠簡單的經過 curl 命令來查看響應信息。