摘要：所針對(duì)的問題相當(dāng)簡(jiǎn)單可以用一個(gè)簡(jiǎn)單的比喻你的另一半中午打電話給你當(dāng)你在一個(gè)會(huì)議上并詢問你告訴他們你的網(wǎng)上銀行賬戶的密碼因?yàn)樗麄冃枰獔?zhí)行一個(gè)銀行轉(zhuǎn)賬以確保你兒子的教育費(fèi)用按時(shí)支付。正如我提到的，你正在開會(huì)，需要拼寫你的網(wǎng)上銀行密碼。

想閱讀更多優(yōu)質(zhì)文章請(qǐng)猛戳GitHub博客,一年百來篇優(yōu)質(zhì)文章等著你！

這是關(guān)于web安全性系列文章的第2篇，第一篇可點(diǎn)擊以下查看：

Web 應(yīng)用安全性: 瀏覽器是如何工作的

HTTP是一個(gè)美好的東西:一個(gè)存在了20多年而沒有太多變化的協(xié)議。

正如我們?cè)谇耙黄恼轮锌吹降模瑸g覽器通過HTTP協(xié)議與web應(yīng)用程序交互，這是我們深入研究這個(gè)主題的主要原因。如果用戶在網(wǎng)站上輸入他們的信用卡信息，攻擊者就能在數(shù)據(jù)到達(dá)服務(wù)器之前攔截?cái)?shù)據(jù)，我們肯定會(huì)有麻煩。

了解HTTP是如何工作的，我們?nèi)绾伪Ｗo(hù)客戶端和服務(wù)器之間的通信，以及該協(xié)議提供了哪些與安全相關(guān)的特性，這是改進(jìn)安全狀態(tài)的第一步。

但是，在討論HTTP時(shí)，我們應(yīng)該始終區(qū)分語(yǔ)義和技術(shù)實(shí)現(xiàn)，因?yàn)樗鼈兪荋TTP工作方式的兩個(gè)非常不同的方面。

兩者之間的關(guān)鍵區(qū)別可以用一個(gè)非常簡(jiǎn)單的類比來解釋:20年前，人們像現(xiàn)在一樣關(guān)心他們的親人，盡管他們互動(dòng)的方式已經(jīng)發(fā)生了巨大的變化。我們的父母可能會(huì)開著車去他們姐姐家，這樣就能趕上和家人在一起。

相反，現(xiàn)在更常見的是在 WhatsApp 上留言、打電話或使用 Facebook 群組，這在以前是不可能的。這并不是說人們或多或少地交流或關(guān)心，而是說他們交流的方式改變了。

HTTP 也不例外:協(xié)議背后的語(yǔ)義沒有太大的變化，而客戶端和服務(wù)器之間通信的技術(shù)實(shí)現(xiàn)已經(jīng)經(jīng)過多年的優(yōu)化。如果您查看 1996 年的 HTTP 請(qǐng)求，它看起來與我們?cè)谇耙黄恼轮锌吹降恼?qǐng)求非常相似，盡管這些數(shù)據(jù)包通過網(wǎng)絡(luò)的方式非常不同。

如前所述，HTTP遵循請(qǐng)求/響應(yīng)模型，其中連接到服務(wù)器的客戶端發(fā)出請(qǐng)求，服務(wù)器對(duì)其進(jìn)行響應(yīng)。

HTTP消息(請(qǐng)求或響應(yīng))包含多個(gè)部分:

請(qǐng)求行

請(qǐng)求頭

請(qǐng)求體

第一部分：請(qǐng)求行，用來說明請(qǐng)求類型,要訪問的資源以及所使用的HTTP版本。

GET /players/lebron-james HTTP/1.1

GET說明請(qǐng)求類型為 GET,/players/lebron-james 為要訪問的資源，該行的最后一部分說明使用的是 HTTP1.1 版本。

第二部分：請(qǐng)求頭部，緊接著請(qǐng)求行（即第一行）之后的部分，用來說明服務(wù)器要使用的附加信。:

GET /players/lebron-james HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

例如，在此請(qǐng)求中，客戶端已為請(qǐng)求附加了3個(gè)附加標(biāo)頭：Host，Accept和 Coolness。

等一下,Coolness 是什么

報(bào)頭不必使用特定的保留名稱，但通常建議依賴于 HTTP 規(guī)范標(biāo)準(zhǔn)化的名稱:越偏離標(biāo)準(zhǔn)，交換中的另一方就越不理解你。

例如，Cache-Control 是一個(gè)頭文件，用于定義響應(yīng)是否是可緩存的:大多數(shù)代理和反向代理都完全按照 HTTP 規(guī)范來理解它。如果將 Cache-Control 頭重命名為 Awesome-Cache-Control，代理將不再知道如何緩存響應(yīng)，因?yàn)樗鼈儾皇前凑漳銊倓偺岢龅囊?guī)范構(gòu)建的。

但有時(shí)候，在消息中包含“自定義”標(biāo)題可能是有意義的，因?yàn)槟憧赡芟Ｍ砑訉?shí)際上不屬于 HTTP 規(guī)范的元數(shù)據(jù)：服務(wù)器可以決定在其響應(yīng)中包含技術(shù)信息，以便客戶端可以同時(shí)執(zhí)行請(qǐng)求并獲取有關(guān)回復(fù)的服務(wù)器狀態(tài)的重要信息：

...
X-Cpu-Usage: 40%
X-Memory-Available: 1%
...

使用自定義標(biāo)頭時(shí)，始終首選為它們添加一個(gè)鍵，以便它們不會(huì)與將來可能成為標(biāo)準(zhǔn)的其他標(biāo)頭沖突：從歷史上看，這一直很有效，直到每個(gè)人都開始使用“非標(biāo)準(zhǔn)” X 前綴 反過來，這成為常態(tài)。 X-Forwarded-For 和 X-Forwarded-Proto標(biāo) 頭是負(fù)載平衡器和代理廣泛使用和理解的自定義標(biāo)頭的示例，即使它們不是 HTTP 標(biāo)準(zhǔn)的一部分。

如果你需要添加自己的自定義頭，那么現(xiàn)在通常最好使用一個(gè)自動(dòng)生成的前綴，例如 Acme-Custom-Header 頭或 A-Custom-Header 頭。

在標(biāo)題之后，一個(gè)請(qǐng)求可能包含一個(gè)主體，它與標(biāo)題之間用空行隔開:

POST /players/lebron-james/comments HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

Best Player Ever

我們的請(qǐng)求完成了:第一行(位置和協(xié)議信息)、請(qǐng)求頭和請(qǐng)求體。注意，請(qǐng)求體是完全可選的，在大多數(shù)情況下，它只在我們想要向服務(wù)器發(fā)送數(shù)據(jù)時(shí)使用——這就是上面的示例使用 POST 的原因。

響應(yīng)沒有太大的不同:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=3600

{"name": "Lebron James", "birthplace": "Akron, Ohio", ...}

響應(yīng)發(fā)布的第一個(gè)信息是它使用的協(xié)議版本以及該響應(yīng)的狀態(tài)。請(qǐng)求頭也一樣，如果需要的話，在正文后面加一個(gè)換行符。

如前所述，該協(xié)議經(jīng)過了多次修訂，并隨著時(shí)間的推移添加了一些特性(新的頭文件、狀態(tài)代碼等)，但是底層結(jié)構(gòu)并沒有太大的變化(請(qǐng)求行、請(qǐng)求頭和正文)。真正改變的是客戶端和服務(wù)器如何交換這些消息——讓我們更仔細(xì)地研究一下。

HTTP 已經(jīng)經(jīng)歷了 2 個(gè)相當(dāng)大的語(yǔ)義變化: HTTP/1.0 和 HTTP/1.1。

那，“HTTPS 和 HTTP2 在哪里？”

HTTPS 和 HTTP2 (縮寫為 H2)是更多的技術(shù)更改，因?yàn)樗鼈円肓嗽诨ヂ?lián)網(wǎng)上傳遞消息的新方法，而不會(huì)嚴(yán)重影響協(xié)議的語(yǔ)義。

HTTPS 是 HTTP的一種“安全”擴(kuò)展，它涉及在客戶機(jī)和服務(wù)器之間建立一個(gè)公共秘密，確保我們與正確的一方進(jìn)行通信，并對(duì)與公共秘密交換的消息進(jìn)行加密(稍后將對(duì)此進(jìn)行詳細(xì)介紹)。HTTPS 的目標(biāo)是提高HTTP 協(xié)議的安全性，而 H2 的目標(biāo)是為其帶來更快的速度。

H2 使用二進(jìn)制而不是純文本消息，支持多路復(fù)用，使用 HPACK 算法壓縮報(bào)頭……長(zhǎng)話短說，H2 是對(duì)HTTP/1.1 的性能提升。

網(wǎng)站所有者不愿意切換到 HTTPS，因?yàn)樗婕翱蛻舳撕头?wù)器之間的額外往返（如上所述，需要在兩方之間建立共同的秘密），從而減慢用戶體驗(yàn)：使用 H2 加密 默認(rèn)情況下，他們就沒有借口了，因?yàn)槎嗦窂?fù)用和服務(wù)器推送等功能使其 性能優(yōu)于普通的 HTTP/1.1。

HTTPS (HTTP Secure)的目標(biāo)是讓客戶端和服務(wù)器通過 TLS(傳輸層安全性)安全地進(jìn)行通信，TLS 是SSL(安全套接字層)的繼承者。

TLS 所針對(duì)的問題相當(dāng)簡(jiǎn)單,可以用一個(gè)簡(jiǎn)單的比喻:你的另一半中午打電話給你,當(dāng)你在一個(gè)會(huì)議上,并詢問你告訴他們你的網(wǎng)上銀行賬戶的密碼,因?yàn)樗麄冃枰獔?zhí)行一個(gè)銀行轉(zhuǎn)賬,以確保你兒子的教育費(fèi)用按時(shí)支付。重要的是你現(xiàn)在就告訴他們，否則第二天早上你的孩子可能會(huì)被學(xué)校拒之門外。

你們現(xiàn)在面臨著兩個(gè)挑戰(zhàn):

身份驗(yàn)證: 確保你真的在和你的另一半說話，因?yàn)橛锌赡軇e人會(huì)假裝他們

加密: 在同事無(wú)法理解和記錄下密碼的情況下進(jìn)行通信

這正是 HTTPS 試圖解決的問題。

為了驗(yàn)證你正在與誰(shuí)交談，HTTPS 使用公鑰證書，這只是聲明特定服務(wù)器背后身份的證書:當(dāng)你通過 HTTPS 連接到 IP 地址時(shí)，該地址背后的服務(wù)器將向你提供其證書，以驗(yàn)證其身份。回到我們的類比，這可能只是你讓你的另一半拼寫他們的社會(huì)保險(xiǎn)號(hào)。一旦驗(yàn)證了數(shù)字的正確性，你就獲得了額外的信任級(jí)別。

但是，這并不能阻止“攻擊者”學(xué)習(xí)受害者的社會(huì)安全號(hào)碼，偷走你伴侶的智能手機(jī)并給你打電話。 我們?nèi)绾悟?yàn)證來電者的身份？

你不是直接讓你的另一半拼他們的社會(huì)保險(xiǎn)號(hào)，而是打電話給你的媽媽(她正好住在你隔壁)，讓她去你的公寓，確保你的另一半拼的是他們的社會(huì)保險(xiǎn)號(hào)。這增加了額外的信任級(jí)別，因?yàn)槟悴徽J(rèn)為你的母親是一個(gè)威脅，并依賴她來驗(yàn)證調(diào)用者的身份。

在 HTTPS 術(shù)語(yǔ)中，你的媽媽稱為 CA，證書頒發(fā)機(jī)構(gòu) (Certificate Authority)的簡(jiǎn)稱：CA 的工作是驗(yàn)證特定服務(wù)器后面的身份，并頒發(fā)具有自己的數(shù)字簽名的證書：這意味著，當(dāng)我連接到特定域時(shí)，我不會(huì)出示由域所有者生成的證書（稱為自簽名證書），而是由 CA 頒發(fā)。

權(quán)威機(jī)構(gòu)的職責(zé)是確保他們驗(yàn)證域名后面的身份并相應(yīng)地頒發(fā)證書：當(dāng)你“訂購(gòu)”證書時(shí)（通常稱為 SSL 證書，即使現(xiàn)在使用 TLS 代替 ）， 當(dāng)局可能會(huì)給人打電話或要求你更改 DNS 設(shè)置，以驗(yàn)證你是否可以控制相關(guān)域。 驗(yàn)證過程完成后，它將頒發(fā)證書，然后你可以在 Web 服務(wù)器上安裝該證書。

像瀏覽器這樣的客戶端將連接到您的服務(wù)器并獲得此證書，以便他們可以驗(yàn)證它看起來是真實(shí)的：瀏覽器與CA有某種“關(guān)系”，因?yàn)樗鼈兏櫩尚臗A的列表。 為了驗(yàn)證證書是否真的值得信賴。 如果證書未由受信任的機(jī)構(gòu)簽名，則瀏覽器將向用戶顯示一條信息量大的警告：

確保你和你的另一半之間的通信安全已經(jīng)完成了一半:現(xiàn)在我們已經(jīng)解決了身份驗(yàn)證(驗(yàn)證調(diào)用者的身份)，我們需要確保我們可以安全地通信，而不會(huì)在此過程中被其他人竊聽。正如我提到的，你正在開會(huì)，需要拼寫你的網(wǎng)上銀行密碼。你需要找到一種方法來加密你的交流，這樣只有你和你的伴侶才能理解你的談話。

您可以通過在雙方之間建立共享密鑰來實(shí)現(xiàn)此目的，并通過該密鑰加密消息：例如，你可以根據(jù)婚禮日期決定使用 Caesar cipher 的變體。

如果雙方都有一段穩(wěn)定的關(guān)系，就像你和你的靈魂伴侶一樣，這將會(huì)很有效，因?yàn)樗麄兛梢栽趧e人不知道的共同記憶的基礎(chǔ)上創(chuàng)造一個(gè)密鑰。但是，瀏覽器和服務(wù)器不能使用相同的機(jī)制，因?yàn)樗鼈兪孪炔涣私獗舜恕?/p>

取而代之的是 Diffie-Hellman 密鑰交換協(xié)議的變體，它確保沒有預(yù)先知道的各方建立共享的密鑰，而其他人無(wú)法“嗅探”它。這需要用到一點(diǎn)數(shù)學(xué)知識(shí)，這是留給讀者的一個(gè)練習(xí)。

一旦密鑰建立起來，客戶端和服務(wù)器就可以進(jìn)行通信，而不必?fù)?dān)心有人會(huì)截獲它們的消息。即使攻擊者這樣做，他們也沒有解密消息所需的公共密鑰。

還在爭(zhēng)論你是否應(yīng)該在你的網(wǎng)站上支持HTTPS？ 我沒有好消息：瀏覽器已經(jīng)開始推動(dòng)用戶遠(yuǎn)離不支持HTTPS 的網(wǎng)站，以“強(qiáng)迫”網(wǎng)絡(luò)開發(fā)者提供完全加密的瀏覽體驗(yàn)。

在 “HTTPS無(wú)處不在” 的口號(hào)背后，瀏覽器開始反對(duì)未加密的連接——谷歌是第一個(gè)給網(wǎng)絡(luò)開發(fā)者最后期限的瀏覽器供應(yīng)商，它宣布從 Chrome 68(2018年7月) 開始將把HTTP網(wǎng)站標(biāo)記為“不安全”:

對(duì)于不使用HTTPS的網(wǎng)站來說，更令人擔(dān)憂的是，一旦用戶在網(wǎng)頁(yè)上輸入任何內(nèi)容，“不安全”標(biāo)簽就會(huì)變成紅色——這一舉動(dòng)應(yīng)該會(huì)鼓勵(lì)用戶在與不支持HTTPS的網(wǎng)站交換數(shù)據(jù)之前三思而后行。

將此與在HTTPS上運(yùn)行并配備有效證書的網(wǎng)站的外觀進(jìn)行比較:

從理論上講，網(wǎng)站不一定是安全的，但在實(shí)踐中，這會(huì)嚇跑用戶 - 這是理所當(dāng)然的。 當(dāng) H2 還沒普遍時(shí)，堅(jiān)持使用未加密的純HTTP通信是有意義的，如今幾乎沒有理由這樣做。

正如我們前面看到的，HTTP請(qǐng)求以一個(gè)特殊的請(qǐng)求行開始:

首先，客戶端告訴服務(wù)器它正在使用什么動(dòng)詞來執(zhí)行請(qǐng)求：常見的 HTTP 動(dòng)詞包括 GET，POST，PUT 和 DELETE，但列表可以繼續(xù)使用不常見（但仍然是標(biāo)準(zhǔn)的）動(dòng)詞，如 TRACE， OPTIONS，或 HEAD。

理論上，沒有一種方法比其他方法更安全;實(shí)際上，事情并沒有那么簡(jiǎn)單。

GET 請(qǐng)求通常不帶主體，因此參數(shù)包含在 URL 中（如 www.example.com/articles?article_id=1），而 POST 請(qǐng)求通常用于發(fā)送（“post”）包含在內(nèi)的數(shù)據(jù)。

另一個(gè)區(qū)別在于這些動(dòng)詞帶有的副作用：GET 是一個(gè)冪等動(dòng)詞，意思是無(wú)論你要發(fā)送多少個(gè)請(qǐng)求，你都不會(huì)改變網(wǎng)絡(luò)服務(wù)器的狀態(tài)。 相反，POST 不是冪等的：對(duì)于你發(fā)送的每個(gè)請(qǐng)求，你可能正在更改服務(wù)器的狀態(tài)（例如，考慮發(fā)布新的付款 - 現(xiàn)在您可能理解為什么站點(diǎn)要求你在執(zhí)行時(shí)不刷新頁(yè)面 交易）。

冪等性：指一次和多次請(qǐng)求某一個(gè)資源應(yīng)該具有同樣的副作用，也就是一次訪問與多次訪問，對(duì)這個(gè)資源帶來的變化是相同的。

為了說明這些方法之間的一個(gè)重要區(qū)別，我們需要看一看 web 服務(wù)器的日志，這些日志你可能已經(jīng)很熟悉了:

192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:39:47 +0000] "GET /?token=1234 HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 404 0.002 [example-local] 172.17.0.8:9090 525 0.002 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:40:47 +0000] "GET / HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 393 0.004 [example-local] 172.17.0.8:9090 525 0.004 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:41:34 +0000] "PUT /users HTTP/1.1" 201 23 "http://example.local/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 4878 0.016 [example-local] 172.17.0.8:9090 23 0.016 201

如你所見，web服務(wù)器記錄請(qǐng)求路徑:這意味著，如果你在 URL 中包含敏感數(shù)據(jù)，那么它將被 web 服務(wù)器泄露并保存在你的日志中的某個(gè)位置—你的密鑰將以明文的形式出現(xiàn)，這是我們絕對(duì)需要避免的。假設(shè)攻擊者能夠訪問你的一個(gè)舊日志文件，該文件可能包含信用卡信息、私有服務(wù)的訪問令牌等等:這將是一場(chǎng)徹底的災(zāi)難。

Web 服務(wù)器不記 錄HTTP標(biāo)頭或主體，因?yàn)橐４娴臄?shù)據(jù)太大 - 這就是為什么通過請(qǐng)求主體而不是URL發(fā)送信息通常更安全。 從這里我們可以得出 POST（和類似的，非冪等方法）比 GET 更安全，即使更多的是使用特定動(dòng)詞時(shí)數(shù)據(jù)的發(fā)送方式而不是特定動(dòng)詞本身比其他動(dòng)詞更安全：如果你 將敏感信息包含在 GET 請(qǐng)求的主體中，然后你不會(huì)遇到比使用 POST 時(shí)更多的問題，即使這種方法被認(rèn)為是不尋常的。

在本文中，我們研究了HTTP，它的演變以及它的安全擴(kuò)展如何集成身份驗(yàn)證和加密，以使客戶端和服務(wù)器通過安全通道進(jìn)行通信：這不是所有 HTTP 在安全性方面提供的。

正如我們將在下一篇文章中看到的，HTTP安全頭文件提供了一種改進(jìn)應(yīng)用程序安全狀態(tài)的方法，下一篇文章將致力于理解如何利用它們。

你的點(diǎn)贊是我持續(xù)分享好東西的動(dòng)力，歡迎點(diǎn)贊！

一個(gè)笨笨的碼農(nóng)，我的世界只能終身學(xué)習(xí)！

更多內(nèi)容請(qǐng)關(guān)注公眾號(hào)《大遷世界》！