Web應(yīng)用安全性: 瀏覽器是如何工作的
這里先解釋瀏覽器的功能以及執(zhí)行方式。由于大多數(shù)客戶將通過瀏覽器與 web 應(yīng)用程序進行交互，因此必須了解這些出色程序的基礎(chǔ)知識。
瀏覽器是一個渲染引擎，它的工作是下載一個web頁面，并以人類能夠理解的方式渲染它。
雖然這幾乎是一種過于簡單的過分簡化，但我們現(xiàn)在需要知道的全部內(nèi)容。
- 用戶在瀏覽器欄中輸入一個地址。
- 瀏覽器從該 URL 下載“文檔”并渲染它。
你可能習(xí)慣使用 Chrome，F(xiàn)irefox，Edge或Safari等流行的瀏覽器之一，但這并不意味著沒有不同的瀏覽器。
例如，lynx 是一種輕量級的、基于文本的瀏覽器，可以在命令行中工作。lynx 的核心原理與其他“主流”瀏覽器的原理完全相同。用戶輸入 web 地址(URL)，瀏覽器獲取文檔并呈現(xiàn)它——僅有的區(qū)別是 lynx 不使用可視化渲染引擎，而是使用基于文本的界面，這使得像谷歌這樣的網(wǎng)站看起來像這樣:
我們大致了解瀏覽器的功能，但是讓我們仔細看看這些機智的應(yīng)用程序為我們所做的步驟。
瀏覽器做了什么?
長話短說，瀏覽器的工作主要包括:
- DNS 解析
- HTTP 交換
- 渲染
- 重復(fù)以下步驟
DNS 解析
這個過程確保一旦用戶輸入 URL，瀏覽器就知道它必須連接到哪個服務(wù)器。瀏覽器聯(lián)系 DNS 服務(wù)器，發(fā)現(xiàn)google.com 翻譯成 216.58.207.110，這是一個瀏覽器可以連接的 IP 地址。
HTTP 交換
一旦瀏覽器確定了哪個服務(wù)器將為我們的請求提供服務(wù)，它將啟動與它的 TCP 連接并開始 HTTP 交換。 這只是瀏覽器與服務(wù)器通信所需內(nèi)容以及服務(wù)器回復(fù)的一種方式。
HTTP 只是用于在 Web 上進行通信協(xié)議的名稱，而瀏覽器一般通過 HTTP 與服務(wù)器進行通信。 HTTP 交換涉及客戶端（我們的瀏覽器）發(fā)送請求，服務(wù)器回復(fù)響應(yīng)。
例如，當(dāng)瀏覽器成功連接到 google.com 背后的服務(wù)器后，它將發(fā)送一個如下所示的請求:
- GET / HTTP/1.1
- Host: google.com
- Accept: */*
讓我們一行一行地把請求分解:
- GET / HTTP/1.1:在第一行中，并補充說其余請求將遵循 HTTP/1.1 協(xié)議（它也可以使用1.0或2）
- Host: google.com：這是 HTTP/1.1 中必須的 HTTP 報頭。因為服務(wù)器可能服務(wù)多個域(google.com, google.co.uk) 。這里的客戶端提到請求是針對特定的主機的。
- Accept: */*：一個可選的標(biāo)頭，其中瀏覽器告訴服務(wù)器接受任何類型的響應(yīng)。服務(wù)器可以擁有 JSON、XM L或HTML 格式的可用資源，因此它可以選擇自己喜歡的格式。
作為客戶端的瀏覽器發(fā)送請求之后，就輪到服務(wù)器進行響應(yīng)了，這是響應(yīng)的格式如下:
- 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>
哇，有很多信息需要消化。服務(wù)器讓我們知道請求是成功的(200 OK)，并向響應(yīng)中添加一些頭部信息，例如，它告知哪個服務(wù)器處理了我們的請求(Server:gws)，該響應(yīng)的 X-XSS-Protection 策略是什么，等等。
現(xiàn)在，你不需要理解響應(yīng)中的每一行，在本系列后面的文章中，我們將介紹 HTTP 協(xié)議及其頭部等內(nèi)容。
現(xiàn)在，你只需要了解客戶端和服務(wù)器正在交換信息，并且它們是通過 HTTP 進行交換的。
渲染
- <!doctype html><html">
- ...
- ...
- </html>
在響應(yīng)的主體中，服務(wù)器根據(jù) Content-Type 頭包括響應(yīng)類型來表示。 在我們的例子中，內(nèi)容類型設(shè)置為 text/ html，因此我們期待響應(yīng)中的 HTML 標(biāo)記 - 這正是我們在正文中找到的。
這才是瀏覽器真正的亮點所在。它解析 HTML，加載標(biāo)記中包含的額外資源(例如，可能需要獲取JavaScript文件或CSS文檔)，并盡快將它們呈現(xiàn)給用戶。
最終的結(jié)果是普通人能夠理解的：
如果想要更詳細地了解當(dāng)我們在瀏覽器地址欄中按回車鍵時會發(fā)生什么，建議閱讀“What happens when…”，這是一個非常精細的嘗試來解釋該過程背后的機制。
由于這是一個關(guān)注安全性的系列文章，從剛剛了解到的內(nèi)容可以提到提示:攻擊者可以輕松地利用 HTTP 交換和渲染部分中的漏洞謀生。漏洞和惡意用戶也潛伏在其他地方，但是這些級別上更好的安全方法已經(jīng)允許你在改進安全性方面取得進展。
供應(yīng)商
4 個非常流行的瀏覽器屬于不同的公司:
- 谷歌的 Chrome
- Mozilla 的火狐
- 蘋果的 Safari
- 微軟的 Edge
除了為了增加市場滲透率而相互競爭之外，供應(yīng)商也為了提高 web 標(biāo)準(zhǔn)而相互合作，這是對瀏覽器的一種非常低的要求。
W3C是標(biāo)準(zhǔn)開發(fā)的主體，但是瀏覽器開發(fā)自己的特性并最終成為 web 標(biāo)準(zhǔn)的情況并不少見，安全性也不例外。
例如，Chrome 51 引入了 SameSite cookie，該功能允許 Web 應(yīng)用程序擺脫稱為 CSRF 的特定類型的漏洞（稍后將詳細介紹）。其他供應(yīng)商認為這是一個好主意，并紛紛效仿，導(dǎo)致 SameSite 成為 web 標(biāo)準(zhǔn):到目前為止，Safari 是僅有的沒有 SameSite cookie 支持的主流瀏覽器。
這告訴我們兩件事:
- Safari似乎并不關(guān)心用戶的安全性（開玩笑：Safari 12中將提供SameSite cookie，這可能在你閱讀本文時已經(jīng)發(fā)布）
- 修補一個瀏覽器上的漏洞并不意味著所有用戶都是安全的
第一點是對 Safari 的一次嘗試(正如我提到的，開玩笑的!)，而第二點非常重要。在開發(fā)web應(yīng)用程序時，我們不僅需要確保它們在不同的瀏覽器中看起來是相同的，還需要確保我們的用戶在不同的平臺上受到相同的保護。
你的網(wǎng)絡(luò)安全策略應(yīng)根據(jù)瀏覽器供應(yīng)商允許我們執(zhí)行的操作而有所不同。 如今，大多數(shù)瀏覽器都支持相同的功能集，并且很少偏離其常見的路線圖，但是上面的實例仍然會發(fā)生，這是我們在定義安全策略時需要考慮的事情。
在我們的例子中，如果我們決定只通過 SameSite cookie 來減輕 CSRF 攻擊，那么我們應(yīng)該意識到我們正在將 Safari 用戶置于危險之中。我們的用戶也應(yīng)該知道這一點。
然后，你應(yīng)該記住,你可以決定是否支持瀏覽器版本:支持每一個瀏覽器版本將是不切實際的(想想 Internet Explorer 6)。雖然確保最近幾個版本的主流瀏覽器的支持通常是一個好的決定，但是如果你不打算在特定的平臺上提供保護，一般建議讓你的用戶知道。
專業(yè)提示:你不應(yīng)該鼓勵你的用戶使用過時的瀏覽器，或積極支持他們。盡管你可能已經(jīng)采取了所有必要的預(yù)防措施，但是其他web開發(fā)人員可能沒有。鼓勵用戶使用主流瀏覽器支持的新版本。
供應(yīng)商還是標(biāo)準(zhǔn)bug?
普通用戶通過第三方客戶端（瀏覽器）訪問我們的應(yīng)用程序這一事實增加了另一層次的間接性：瀏覽器本身可能存在安全漏洞。‘
供應(yīng)商通常會向能夠發(fā)現(xiàn)瀏覽器自身漏洞的安全研究人員提供獎勵(即 bug獎金)。這些bug與你的實現(xiàn)無關(guān)，而是與瀏覽器本身處理安全性的方式有關(guān)。
例如，Chrome 獎勵計劃可讓安全工程師與 Chrome 安全團隊聯(lián)系，報告他們發(fā)現(xiàn)的漏洞。 如果確認了這些漏洞，則會發(fā)布補丁，通常會向公眾發(fā)布安全建議通知，研究人員會從該計劃中獲得（通常是財務(wù)上的）獎勵。
像谷歌這樣的公司在他們的Bug賞金項目中投入了相對較多的資金，這使得他們能夠通過承諾在發(fā)現(xiàn)應(yīng)用程序的任何問題時獲得經(jīng)濟利益來吸引研究人員。
在一個漏洞賞金計劃中，每個人都是贏家:供應(yīng)商設(shè)法提高其軟件的安全能力，研究人員也因此獲得報酬。我們將在后面討論這些程序，因為我相信Bug賞金計劃應(yīng)該在安全領(lǐng)域有自己的一節(jié)。
Jake Archibald 是谷歌的一名開發(fā)人員，他最近發(fā)現(xiàn)了一個影響多個瀏覽器的漏洞。他在一篇有趣的博客文章中記錄了他的努力，他如何接觸不同的供應(yīng)商，以及他們的反應(yīng)，建議你閱讀 這篇文章。
開發(fā)人員的瀏覽器
到目前為止，我們應(yīng)該理解一個非常簡單但相當(dāng)重要的概念：瀏覽器只是為普通網(wǎng)絡(luò)沖浪者構(gòu)建的 HTTP 客戶端。
它們肯定比平臺的純HTTP客戶端更強大(例如，考慮NodeJS的require(‘HTTP’))，但歸根結(jié)底，它們“只是”更簡單的 HTTP客戶端的自然演化。
作為開發(fā)人員，我們選擇的HTTP客戶機可能是 Daniel Stenberg 的 cURL，他是 web 開發(fā)人員每天使用的十分流行的軟件程序之一。它允許我們通過從命令行發(fā)送 HTTP 請求來實時執(zhí)行 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/ 上請求了文檔，本地服務(wù)器成功響應(yīng)。
在這里，我們沒有將響應(yīng)的主體顯示在命令行，而是使用了 -I 標(biāo)志，它告訴 cURL 我們只對響應(yīng)頭感興趣。更進一步，我們可以指示 cURL 顯示更多的信息，包括它執(zhí)行的實際請求，以便更好地查看整個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 可以獲得幾乎相同的信息。
正如我們所見，瀏覽器只不過是精心設(shè)計的HTTP客戶端。 當(dāng)然，他們添加了大量的功能（想到憑據(jù)管理，書簽，歷史等），但事實是，它們是作為人類的 HTTP 客戶端而誕生的。 這很重要，因為在大多數(shù)情況下，不需要使用瀏覽器來測試Web應(yīng)用程序的安全性，因為你可以簡單的通過 curl 命令來查看響應(yīng)信息。
進入 HTTP 協(xié)議
正如我們所提到的，HTTP交換和渲染階段是我們主要要涉及的階段，因為它們?yōu)閻阂庥脩籼峁┝舜髷?shù)量的攻擊媒介。
在下一篇文章中，我們將深入研究HTTP協(xié)議，并嘗試了解為了保護HTTP交換，我們應(yīng)該采取哪些措施。
