《圖解HTTP》書摘

圖解HTTP

上野宣、于均良

1.3 網絡基礎 TCP/IP

2016-03-03

互相通信，雙方就必須基于相同的方法。比如，如何探測到通信目标、由哪一邊先發起通信、使用哪種語言進行通信、怎樣結束通信等規則都需要事先确定。不同的硬體、作業系統之間的通信，所有的這一切都需要一種規則。而

協定中存在各式各樣的内容。從電纜的規格到 IP 位址的標明方法、尋找異地使用者的方法、雙方建立通信的順序，以及 Web 頁面顯示需要處理的步驟，等等。

值得一提的是，階層化之後，設計也變得相對簡單了。處于應用層上的應用可以隻考慮分派給自己的任務，而不需要弄清對方在地球上哪個地方、對方的傳輸路線是怎樣的、是否能確定傳輸送達等問題。

用來處理連接配接網絡的硬體部分。包括控制作業系統、硬體的裝置驅動、NIC（Network Interface Card，網絡擴充卡，即網卡），及光纖等實體可見部分（還包括連接配接器等一切傳輸媒介）。硬體上的範疇均在鍊路層的作用範圍之内。

這種把資料資訊包裝起來的做法稱為封裝（encapsulate）。

1.4 與 HTTP 關系密切的協定 : IP、TCP 和 DNS

IP 協定的作用是把各種資料包傳送給對方。而要保證确實傳送到對方那裡，則需要滿足各類條件。其中兩個重要的條件是 IP 位址和 MAC 位址（Media Access Control Address）。

IP 位址指明了節點被配置設定到的位址，MAC 位址是指網卡所屬的固定位址。IP 位址可以和 MAC 位址進行配對。IP 位址可變換，但 MAC 位址基本上不會更改。

會利用下一站中轉裝置的 MAC 位址來搜尋下一個中轉目标。這時，會采用 ARP 協定（Address Resolution Protocol）。ARP 是一種用以解析位址的協定，根據通信方的 IP 位址就可以反查出對應的 MAC 位址。

我們是想通過這個比喻說明，無論哪台計算機、哪台網絡裝置，它們都無法全面掌握網際網路中的細節。

所謂的位元組流服務（Byte Stream Service）是指，為了友善傳輸，将大塊資料分割成以封包段（segment）為機關的資料包進行管理。而可靠的傳輸服務是指，能夠把資料準确可靠地傳給對方。一言以蔽之，TCP 協定為了更容易傳送大資料才把資料分割，而且 TCP 協定能夠确認資料最終是否送達到對方。

用 TCP 協定把資料包送出去後，TCP 不會對傳送後的情況置之不理，它一定會向對方确認是否成功送達。握手過程中使用了 TCP 的标志（flag） —— SYN（synchronize） 和 ACK（acknowledgement）。

發送端首先發送一個帶 SYN 标志的資料包給對方。接收端收到後，回傳一個帶有 SYN/ACK 标志的資料包以示傳達确認資訊。最後，發送端再回傳一個帶 ACK 标志的資料包，代表“握手”結束。

1.5 負責域名解析的 DNS 服務

它提供域名到 IP 位址之間的解析服務。

為了解決上述的問題，DNS 服務應運而生。DNS 協定提供通過域名查找 IP 位址，或逆向從 IP 位址反查域名的服務。

1.7 URI 和 URL

資源的定義是“可辨別的任何東西”。除了文檔檔案、圖像或服務（例如當天的天氣預報）等能夠差別于其他類型的，全都可作為資源。另外，資源不僅可以是單一的，也可以是多數的集合體。

URI 用字元串辨別某一網際網路資源，而 URL 表示資源的地點（網際網路上所處的位置）。可見 URL 是 URI 的子集。

表示指定的 URI，要使用涵蓋全部必要資訊的絕對 URI、絕對 URL 以及相對 URL。

讓我們先來了解一下絕對 URI 的格式。

使用絕對 URI 必須指定待通路的伺服器位址。位址可以是類似 hackr.jp 這種 DNS 可解析的名稱，或是 192.168.1.1 這類 IPv4 位址 名，還可以是 [0:0:0:0:0:0:0:1] 這樣用方括号括起來的 IPv6 位址名。

針對已指定的檔案路徑内的資源，可以使用查詢字元串傳入任意參數。此項可選。

2.2 通過請求和響應的交換達成通信

HTTP 協定規定，請求從用戶端發出，最後伺服器端響應該請求并傳回。換句話說，肯定是先從用戶端開始建立通信的，伺服器端在沒有接收到請求之前不會發送響應。

請求封包是由請求方法、請求 URI、協定版本、可選的請求首部字段和内容實體構成的。

響應封包基本上由協定版本、狀态碼（表示請求成功或失敗的數字代碼）、用以解釋狀态碼的原因短語、可選的響應首部字段以及實體主體構成

2.3 HTTP 是不儲存狀态的協定

協定對于發送過的請求或響應都不做持久化處理

使用 HTTP 協定，每當有新的請求發送時，就會有對應的新響應産生。協定本身并不保留之前一切的請求或響應封包的資訊。這是為了更快地處理大量事務，確定協定的可伸縮性，而特意把 HTTP 協定設計成如此簡單的。

2.4 請求 URI 定位資源

如果不是通路特定資源而是對伺服器本身發起請求，可以用一個 * 來代替請求 URI

2.5 告知伺服器意圖的 HTTP 方法

GET 方法用來請求通路已被 URI 識别的資源。指定的資源經伺服器端解析後傳回響應内容。也就是說，如果請求的資源是文本，那就保持原樣傳回；如果是像 CGI（Common Gateway Interface，通用網關接口）那樣的程式，則傳回經過執行後的輸出結果。

雖然用 GET 方法也可以傳輸實體的主體，但一般不用 GET 方法進行傳輸，而是用 POST 方法。雖說 POST 的功能與 GET 很相似，但 POST 的主要目的并不是擷取響應的主體内容。

PUT 方法用來傳輸檔案。就像 FTP 協定的檔案上傳一樣，要求在請求封包的主體中包含檔案内容，然後儲存到請求 URI 指定的位置。

但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人都可以上傳檔案 , 存在安全性問題，是以一般的 Web 網站不使用該方法。若配合 Web 應用程式的驗證機制，或架構設計采用 REST（REpresentational State Transfer，表征狀态轉移）标準的同類 Web 網站，就可能會開放使用 PUT 方法。

圖：和 GET 一樣，但不傳回封包主體

但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機制，是以一般的 Web 網站也不使用 DELETE 方法。當配合 Web 應用程式的驗證機制，或遵守 REST 标準時還是有可能會開放使用的

但是，TRACE 方法本來就不怎麼常用，再加上它容易引發 XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會用到了。

2.7 持久連接配接節省通信量

使用浏覽器浏覽一個包含多張圖檔的 HTML 頁面時，在發送請求通路 HTML 頁面資源的同時，也會請求該 HTML 頁面裡包含的其他資源。是以，每次的請求都會造成無謂的 TCP 連接配接建立和斷開，增加通信量的開銷。

想出了持久連接配接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接配接的特點是，隻要任意一端沒有明确提出斷開連接配接，則保持 TCP 連接配接狀态。

在 HTTP/1.1 中，所有的連接配接預設都是持久連接配接

管線化技術出現後，不用等待響應亦可直接發送下一個請求。

2.8 使用 Cookie 的狀态管理

假設要求登入認證的 Web 頁面本身無法進行狀态的管理（不記錄已登入的狀态），那麼每次跳轉新頁面不是要再次登入，就是要在每次請求封包中附加參數來管理登入狀态。

3.3 編碼提升傳輸速率

HTTP 在傳輸資料時可以按照資料原貌直接傳輸，但也可以在傳輸過程中通過編碼提升傳輸速率。通過在傳輸時編碼，能有效地處理大量的通路請求。但是，編碼的操作需要計算機來完成，是以會消耗更多的 CPU 等資源。

通常，封包主體等于實體主體。隻有當傳輸中進行編碼操作時，實體主體的内容發生變化，才導緻它和封包主體産生差異。

3.4 發送多種資料的多部分對象集合

HTTP 協定中也采納了多部分對象集合，發送的一份封包主體内可含

4.2 2XX 成功

在響應封包内，随狀态碼一起傳回的資訊會因方法的不同而發生改變。比如，使用 GET 方法時，對應請求資源的實體會作為響應傳回；而使用 HEAD 方法時，對應請求資源的實體首部不随封包主體作為響應傳回（即在響應中隻傳回首部，不會傳回實體的主體部分）

4.3 3XX 重定向

表明浏覽器需要執行某些特殊的處理以正确處理請求。

臨時性重定向。該狀态碼表示請求的資源已被配置設定了新的 URI，希望使用者（本次）能使用新的 URI 通路。

但 302 狀态碼代表的資源不是被永久移動，隻是臨時性質的。換句話說，已移動的資源對應的 URI 将來還有可能發生改變。

303 狀态碼明确表示用戶端應當采用 GET 方法擷取

當 301、302、303 響應狀态碼傳回時，幾乎所有的浏覽器都會把 POST 改成 GET，并删除請求封包内的主體，之後請求會自動再次發送。

條件的請求 2 時，伺服器端允許請求通路資源，但未滿足條件的情況。3

4.4 4XX 用戶端錯誤

4XX 的響應結果表明用戶端是發生錯誤的原因所在。

當錯誤發生時，需修改請求的内容後再次發送請求。另外，浏覽器會像 200 OK 一樣對待該狀态碼。

傳回含有 401 的響應必須包含一個适用于被請求資源的 WWW-Authenticate 首部用以質詢（challenge）使用者資訊。當浏覽器初次接收到 401 響應，會彈出認證用的對話視窗。

未獲得檔案系統的通路授權，通路權限出現某些問題（從未授權的發送源 IP 位址試圖通路）等列舉的情況都可能是發生 403 的原因

該狀态碼表明伺服器上無法找到請求的資源。除此之外，也可以在伺服器端拒絕請求且不想說明理由時使用。

4.5 5XX 伺服器錯誤

狀态碼表明伺服器暫時處于超負載或正在進行停機維護，現在無法處理請求。如果事先得知解除以上狀況需要的時間，最好寫入 RetryAfter 首部字段再傳回給用戶端。

不少傳回的狀态碼響應都是錯誤的，但是使用者可能察覺不到這點。比如 Web 應用程式内部發生錯誤，狀态碼依然傳回 200 OK，這種情況也經常遇到。

5.1 用單台虛拟主機實作多個域名

HTTP/1.1 規範允許一台 HTTP 伺服器搭建多個 Web 站點。

這是因為利用了虛拟主機（Virtual Host，又稱虛拟伺服器）的功能。

在相同的 IP 位址下，由于虛拟主機可以寄存多個不同主機名和域名的 Web 網站，是以在發送 HTTP 請求時，必須在 Host 首部内完整指定主機名或域名的 URI。

5.2 通信資料轉發程式 ：代理、網關、隧道

2016-03-04

還有一些用于通信資料轉發的應用程式

這些應用程式和伺服器可以将請求轉發給通信線路上的下一站伺服器，并且能接收從那台伺服器發送的響應再轉發給用戶端。

代理是一種有轉發功能的應用程式

網關是轉發其他伺服器通信資料的伺服器，接收從用戶端發送來的請求時，它就像自己擁有資源的源伺服器一樣對請求進行處理。有時用戶端可能都不會察覺，自己的通信目标是一個網關。

隧道是在相隔甚遠的用戶端和伺服器兩者之間進行中轉，并保持雙方通信連接配接的應用程式。

注

跟代理什麼差別

代理伺服器的基本行為就是接收用戶端發送的請求後轉發給其他伺服器。代理不改變請求 URI，會直接發送給前方持有資源的目标伺服器。

每次通過代理伺服器轉發請求或響應時，會追加寫入 Via 首部資訊

透明代理

轉發請求或響應時，不對封包做任何加工的代理類型被稱為透明代理（Transparent Proxy）。反之，對封包内容進行加工的代理被稱為非透明代理。

利用網關可以由 HTTP 請求轉化為其他協定通信

網關的工作機制和代理十分相似。而網關能使通信線路上的伺服器提供非 HTTP 協定服務。

利用網關能提高通信的安全性，因

？？？

屆時使用 SSL 等加密手段進行通信。隧道的目的是確定用戶端能與伺服器進行安全的通信。

隧道本身不會去解析 HTTP 請求。也就是說，請求保持原樣中轉給之後的伺服器。隧道會在通信雙方斷開連接配接時結束。

隧道本身是透明的，用戶端不用在意隧道的存在

5.3 儲存資源的緩存

緩存伺服器是代理伺服器的一種，并歸類在緩存代理類型中。換句話說，當代理轉發從伺服器傳回的響應時，代理伺服器将會儲存一份資源的副本。

即便緩存伺服器内有緩存，也不能保證每次都會傳回對同資源的請求。因為這關系到被緩存資源的有效性問題。

外，和緩存伺服器相同的一點是，當判定緩存過期後，會向源伺服器确認資源的有效性。若判斷浏覽器緩存失效，浏覽器會再次請求新資

在 HTTP 普及之前，也就是從網際網路的誕生期至今，曾出現過各式各樣的協定。在 HTTP 規範确立之際，制定者們參考了那些協定的功

傳輸檔案時使用的協定。該協定曆史久遠，可追溯到 1973 年前後，比 TCP/IP 協定族的出現還要早。

但時至今日，仍被廣泛沿用。

由于現在已經被 HTTP 協定替代，也已經不怎麼使用了。

6.2 HTTP 首部字段

當 HTTP 封包首部中出現了兩個或兩個以上具有相同首部字段名時會怎麼樣？這種情況在規範内尚未明确，根據浏覽器内部處理邏輯的不同，結果可能并不一緻。有些浏覽器會優先處理第一次出現的首部字段，而有些則會優先處理最後出現的首部字段。

針對請求封包和響應封包的實體部分使用的首部。補充了資源内容更新時間等與實體有關的

還有 Cookie、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段，它們的使用頻率也很高。

下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個首部字段之外，其他所有字段都屬于端到端首部。

6.7 為 Cookie 服務的首部字段

調用 Cookie 時，由于可校驗 Cookie 的有效期，以及發送方的域、路徑、協定等資訊，是以正規釋出的 Cookie 内的資料不會因來自其他 Web 站點和攻擊者的攻擊而洩露。

目前使用最廣泛的 Cookie 标準卻不是 RFC 中定義的任何一個。而是在網景公司制定的标準上進行擴充後的産物。

第 7 章 確定 Web 安全的 HTTPS

在 HTTP 協定中有可能存在資訊竊聽或身份僞裝等安全問題。

7.1 HTTP 的缺點

通信使用明文（不加密），内容可能會被竊聽

不驗證通信方的身份，是以有可能遭遇僞裝無法證明封包的完整性，是以有可能已遭篡改

而且，還有像某些特定的 Web 伺服器和特定的 Web 浏覽器在實際應用中存在的不足（也可以說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等程式設計語言開發的 Web 應用也可能存在安全漏洞。

這是因為，按 TCP/IP 協定族的工作機制，通信内容在所有的通信線路上都有可能遭到窺視。

無論世界哪個角落的伺服器在和用戶端通信時，在此通信線路上的某些網絡裝置、光纜、計算機等都不可能是個人的私有物，是以不排除某個環節中會遭到惡意窺視行為。

即使已經過加密處理的通信，也會被窺視到通信内容，這點和未加密的通信是相同的。隻是說如果通信經過加密，就有可能讓人無法破解封包資訊的含義，但加密處理後的封包資訊本身還是會被看到的。

隻需要收集在網際網路上流動的資料包（幀）就行了。對于收集來的資料包的解析工作，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具。

下面的圖檔示例就是被廣泛使用的抓包工具 Wireshark。它可以擷取 HTTP 協定的請求和響應的内容，并對其進行解析。

一種方式就是将通信加密。HTTP 協定中沒有加密機制，但可以通過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協定）的組合使用，加密 HTTP 的通信内容

還有一種将參與通信的内容本身加密的方式。由于 HTTP 協定中沒有加密機制，那麼就對 HTTP 協定傳輸的内容本身加密。即把 HTTP 封包裡所含的内容進行加密處理。

誠然，為了做到有效的内容加密，前提是要求用戶端和伺服器同時具備加密和解密機制。主要應用在 Web 服務中。有一點必須引起注意，由于該方式不同于 SSL 或 TLS 将整個通信線路加密處理，是以内容仍有被篡改的風險。稍後我們會加以說明

HTTP 協定中的請求和響應不會對通信方進行确認。也就是說存在“伺服器是否就是發送請求中 URI 真正指定的主機，傳回的響應是否真的傳回到實際提出請求的用戶端”等類似問題。

另外，伺服器隻要接收到請求，不管對方是誰都會傳回一個響應（但也僅限于發送端的 IP 位址和端口号沒有被

無法确定正在通信的對方是否具備通路權限。因為某些 Web 伺服器上儲存着重要的資訊，隻想發給特定使用者通信的權限。

無法判定請求是來自何方、出自誰手。

即使是無意義的請求也會照單全收。無法阻止海量請求下的 DoS 攻擊（Denial of Service，拒絕服務攻擊）。

SSL 不僅提供加密處理，而且還使用了一種被稱為證書的手段，可用于确定方。

證書由值得信任的第三方機構頒發，用以證明伺服器和用戶端是實際存在的。另外，僞造證書從技術角度來說是異常困難的一件事。是以隻要能夠确認通信方（伺服器或用戶端）持有的證書，即可判斷通信方的真實意圖。

由于 HTTP 協定無法證明通信的封包完整性，是以，在請求或響應送出之後直到對方接收之前的這段時間内，即使請求或響應的内容遭到篡改，也沒有辦法獲悉。

像這樣，請求或響應在傳輸途中，遭攻擊者攔截并篡改内容的攻擊稱為中間人攻擊（Man-in-the-

雖然有使用 HTTP 協定确定封包完整性的方法，但事實上并不便捷、可靠

不論使用哪一種方法，都需要操縱用戶端的使用者本人親自檢查驗證下載下傳的檔案是否就是原來伺服器上的檔案。浏覽器無法自動幫使用者檢查。

因為 PGP 和 MD5 本身被改寫的話，使用者是沒有辦法意識到的。

為了有效防止這些弊端，有必要使用 HTTPS

7.2 HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

如果在 HTTP 協定通信過程中使用未經加密的明文，比如在 Web 頁面中輸入信用卡号，如果這條通信線路遭到竊聽，那麼信用卡号就暴露了。

另外，對于 HTTP 來說，伺服器也好，用戶端也好，都是沒有辦法确認通信方的。因為很有可能并不是和原本預想的通信方在實際通信。并且還需要考慮到接收到的封包在通信途中已經遭到篡改這一可能性。

其實覺得他這塊還沒我總結得精煉

在 Web 的登入頁面和購物結算界面等使用 HTTPS 通信

通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和 SSL 通信，再由 SSL 和 TCP 通信了。簡言之，所謂 HTTPS，其實就是身披 SSL 協定這層外殼的 HTTP

可以說 SSL 是當今世界上應用最為廣泛的網絡安全技術。

近代的加密方法中加密算法是公開的，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性。

因為解密過程就是在對離散對數進行求值，這并非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那麼密碼破解還是存在希望的

是以應充分利用兩者各自的優勢，将多種方法組合起來用于通信。在交換密鑰環節使用公開密鑰加密方式，之後的建立通信交換封包階段則使用共享密鑰加密方式。

那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。

首先，伺服器的營運人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名，然後配置設定這個已簽名的公開密鑰，并将該公開密鑰放入公鑰證書後綁定在一起。

這個說得很混亂，不如看部落格然後自己總結，感覺很可能是翻譯的問題，根本不為讀者的了解着想

此處認證機關的公開密鑰必須安全地轉交給用戶端。使用通信方式時，如何安全轉交是一件很困難的事，是以，多數浏覽器開發商釋出版本時，會事先在内部植入常用認證機關的公開密鑰。

但是書的話，一般比較嚴謹

EV SSL 證書是基于國際标準的認證指導方針頒發的證書。其嚴格規定了對營運組織是否真實的确認方針，是以，通過認證的 Web 網站能夠獲得更高的認可度。

上述機制的原意圖是為了防止使用者被釣魚攻擊（Phishing），但就效果上來講，還得打一個問号。很多使用者可能不了解 EV SSL 證書相關的知識，是以也不太會留意它。

HTTPS 中還可以使用用戶端證書。以用戶端證書進行用戶端認證，證明伺服器正在通信的對方始終是預料之内的用戶端，其作用跟伺服器證書如出一轍。

但用戶端證書仍存在幾處問題點。其中的一個問題點是證書的擷取及釋出。

想獲驗證書時，使用者得自行安裝用戶端證書。但由于用戶端證書是要付費購買的，且每張證書對應到每位使用者也就意味着需支付和使用者數對等的費用。另外，要讓知識層次不同的使用者們自行安裝證書，這件事本身也充滿了各種挑戰。現狀是，安全性極高的認證機構可頒發用戶端證書但僅用于特殊用途的業務。比如那些可支撐用戶端證書支出費用的業務。

例如，銀行的網上銀行就采用了用戶端證書。在登入網銀時不僅要求使用者确認輸入 ID 和密碼，還會要求使用者的用戶端證書，以确認使用者是否從特定的終端通路網銀。用戶端證書存在的另一個問題點是，用戶端證書畢竟隻能用來證明用戶端實際存在，而不能用來證明使用者本人的真實有效性。也就是說，隻要獲得了安裝有用戶端證書的計算機的使用權限，也就意味着同時擁有了用戶端證書的使用權限。

忽然了解了為什麼有些要初始密碼

是因為建立在其信用絕對可靠這一大前提下的。然而，2011 年 7 月，荷蘭的一家名叫 DigiNotar 的認證機構曾遭黑客不法入侵，頒布了 google.com 和 twit

因為僞造證書上有正規認證機構的數字簽名，是以浏覽器會判定該證書是正當的。當僞造的證書被用做伺服器僞裝之時，使用者根本無法察覺到。

如果使用 OpenSSL 這套開源程式，每個人都可以建構一套屬于自己的認證機構，進而自己給自己頒發伺服器證書。但該伺服器證書在網際網路上不可作為證書使用，似乎沒什麼幫助。

獨立建構的認證機構叫做自認證機構，由自認證機構頒發的“無用”證書也被戲稱為自簽名證書。浏覽器通路該伺服器時，會顯示“無法确認連接配接安全性”或“該網站的安全證書存在問題”等警告消息。

由自認證機構頒發的伺服器證書之是以不起作用，是因為它無法消除僞裝的可能性。自認證機構能夠産生的作用頂多也就是自己對外宣稱“我是○○”的這種程度。即使采用自簽名證書，通過 SSL 加密之後，可能偶爾還會看見通信處在安全狀态的提示，可那也是有問題的。因為 就算加密通信，也不能排除正在和已經過僞裝的假伺服器保持通信。

值得信賴的第三方機構介入認證，才能讓已植入在浏覽器内的認證機構頒布的公開密鑰發揮作用，并借此證明伺服器的真實性。

中級認證機構的證書可能會變成自認證證書

但也有一小部分浏覽器會植入中級認證機構的證書。

步驟 1： 用戶端通過發送 Client Hello 封包開始 SSL 通信。封包中包含用戶端支援的 SSL 的指定版本、加密元件（Cipher Suite）清單（所使用的加密算法及密鑰長度等）。

步驟 2： 伺服器可進行 SSL 通信時，會以 Server Hello 封包作為應答。和用戶端一樣，在封包中包含 SSL 版本以及加密元件。伺服器的加密元件内容是從接收到的用戶端加密元件内篩選出來的。步驟 3： 之後伺服器發送 Certificate 封包。封包中包含公開密鑰證書。

步驟 4： 最後伺服器發送 Server Hello Done 封包通知用戶端，最初階段的 SSL 握手協商部分結束。步驟 5： SSL 第一次握手結束之後，用戶端以 Client Key Exchange 封包作為回應。封包中包含通信加密中使用的一種被稱為 Pre-master secret 的随機密碼串。該封包已用步驟 3 中的公開密鑰進行加密。

步驟 6： 接着用戶端繼續發送 Change Cipher Spec 封包。該封包會提示伺服器，在此封包之後的通信會采用 Pre-master secret 密鑰加密。步驟 7： 用戶端發送 Finished 封包。該封包包含連接配接至今全部封包的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正确解密該封包作為判定标準。

SSL 技術最初是由浏覽器開發商網景通信公司率先倡導的，開發過 SSL3.0 之前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。

IETF 以 SSL3.0 為基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL 為原型開發的協定，有

。目前主流的版本是 SSL3.0 和 TLS1.0。

由于 SSL1.0 協定在設計之初被發現出了問題，就沒有實際投入使用。SSL2.0 也被發現存在問題，是以很多浏覽器直接廢除了該協定版本。

HTTPS 也存在一些問題，那就是當使用 SSL 時，它的處理速度會變慢。

SSL 的慢分兩種。一種是指通信慢。另一種是指由于大量消耗 CPU 及記憶體等資源，導緻處理速度變慢。

其中一個原因是，因為與純文字通信相比，加密通信會消耗更多的 CPU 及記憶體資源。如果每次通信都加密，會消耗相當多的資源，平攤到一台計算機上時，能夠處理的請求數量必定也會随之減少。

在進行加密處理時，并非對所有内容都進行加密

除此之外，想要節約購買證書的開銷也是原因之一。

要進行 HTTPS 通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不同的認證機構略有不同。通常，一年的授權需要數萬日元（現在一萬日元大約折合 600 人民币）。

第 8 章 确認通路使用者身份的認證

或者幹脆僅本人可見。為達到這個目标，必不可少的就是認證功能。下面我們一起來學習一下認證機制。

8.1 何為認證

密碼：隻有本人才會知道的字元串資訊。

動态令牌：僅限本人持有的裝置内顯示的一次性密碼。數字證書：僅限本人（終端）持有的資訊。

生物認證：指紋和虹膜等本人的生理資訊。IC 卡等：僅限本人持有的資訊。

8.2 BASIC 認證

BASIC 認證雖然采用 Base64 編碼方式，但這不是加密處理。不需要任何附加資訊即可對其解碼。換言之，由于明文解碼後就是使用者 ID 和密碼，在 HTTP 等非加密通信的線路上進行 BASIC 認證的過程中，如果被人竊聽，被盜的可能性極高。

另外，除此之外想再進行一次 BASIC 認證時，一般的浏覽器卻無法實作認證登出操作，這也是問題之一

8.3 DIGEST 認證

DIGEST 認證同樣使用質詢 / 響應的方式（challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。

8.5 基于表單認證

2016-03-05

另外，不僅基于表單認證的登入資訊及認證過程都無标準化的方法，伺服器端應如何儲存使用者送出的密碼等登入資訊等也沒有标準化。

通常，一種安全的儲存方法是，先利用給密碼加鹽（salt）1 的方式增加額外資訊，再使用散列（hash）函數計算出散列值後儲存。但是我們也經常看到直接儲存明文密碼的做法，而這樣的做法具有導緻密碼洩露的風險。

當兩個使用者使用了同一個密碼時，由于随機生成的 salt 值不同，對應的散列值也将是不同的

9.1 基于 HTTP 的協定

而這些網站所追求的功能可通過 Web 應用和腳本程式實作。即使這些功能已經滿足需求，在性能上卻未必最優，這是因為 HTTP 協定上的限制以及自身性能有限。

9.2 消除 HTTP 瓶頸的 SPDY

Ajax（Asynchronous JavaScript and XML， 異 步 JavaScript 與 XML 技術）是一種有效利用 JavaScript 和 DOM（Document Object Model，文檔對象模型）的操作，以達到局部 Web 頁面替換加載的異步通信手段。和以前的同步通信相比，由于它隻更新一部分頁面，響應中傳輸的資料量會是以而減少，這一優點顯而易見。

而利用 Ajax 實時地從伺服器擷取内容，有可能會導緻大量請求産生。另外，Ajax 仍未解決 HTTP 協定本身存在的問題。

一旦伺服器端有内容更新了，Comet 不會讓請求等待，而是直接給用戶端傳回響應。這是一種通過延遲應答，模拟實作伺服器端向用戶端推送（Server Push）的功能。

通常，伺服器端接收到請求，在處理完畢後就會立即傳回響應，但為了實作推送功能，Comet 會先将響應置于挂起狀态，當伺服器端有内容更新時，再傳回該響應。是以，伺服器端一旦有更新，就可以立即回報給用戶端。

SPDY 沒有完全改寫 HTTP 協定，而是在 TCP/IP 的應用層與運輸層之間通過新加會話層的形式運作。同時，考慮到安全性問題，SPDY 規定通信中使用 SSL。

支援伺服器主動向用戶端推送資料的功能。這樣，伺服器可直接發送資料，而不必等待用戶端的請求。

9.3 使用浏覽器進行全雙工通信的 WebSocket

。WebSocket 網絡技術正是為解決這些問題而實作的一套新協定及 API。

一旦 Web 伺服器與用戶端之間建立起 WebSocket 協定的通信連接配接，之後所有的通信都依靠這個專用協定進行。通信過程中可互相發送 JSON、XML、HTML 或圖檔等任意格式的資料。

9.5 Web 伺服器管理檔案的 WebDAV

是一個可對 Web 伺服器上的内容直接進行檔案複制、編輯等操作的分布式檔案系統

使用 HTTP/1.1 的 PUT 方法和 DELETE 方法，就可以對 Web 伺服器上的檔案進行建立和删除操作。可是出于安全性及便捷性等考慮，一般不使用。

過去，新編寫接入網際網路的系統或軟體時，還需要同時編寫實作與必要功能對應的新協定。

但最近，使用 HTTP 的系統和軟體占了絕大多數。

這有着諸多原因，其中與企業或組織的防火牆設定有着莫大的關系。防火牆的基本功能就是禁止非指定的協定和端口号的資料包通過。是以如果使用新協定或端口号則必須修改防火牆設定。

10.1 HTML

超文本是一種文檔系統，可将文檔中任意位置的資訊與其他資訊（文本或圖檔等）建立關聯，即超連結文本。

我們把出現在 HTML 文檔内的這種特殊字元串叫做 HTML 标簽（Tag）。

目前的最新版本是 HTML4.01 标準，1999 年 12 月 W3C（World Wide Web Consortium）組織推薦使用這一版本。下一個版本，預計會在 2014 年左右正式推薦使用 HTML5 标準。

CSS（Cascading Style Sheets，層疊樣式表）可以指定如何展現 HTML 内的各種元素，屬于樣式表标準之一。

即使是相同的 HTML 文檔，通過改變應用的 CSS，用浏覽器看到的頁面外觀也會随之改變。CSS 的理念就是讓文檔的結構和設計分離，達到解耦的目的。

10.2 動态 HTML

所謂動态 HTML（Dynamic HTML），是指使用用戶端腳本語言将靜态的 HTML 内容變成動态的技術的總稱。滑鼠單擊點開的新聞、Google Maps 等可滾動的地圖就用到了動态 HTML。

通過調用用戶端腳本語言 JavaScript，實作對 HTML 的 Web 頁面的動态改造

DOM 是用以操作 HTML 文檔和 XML 文檔的 API

使用 DOM 可以将 HTML 内的元素當作對象操作，如取出元素内的字元串、改變那個 CSS 的屬性等，使頁面的設計發生改變。

從 JavaScript 的角度來看，将上述 HTML 文檔的第 3 個 P 元素（P 标簽）改變文字顔色時，會像下方這樣編寫代碼。

DOM 記憶體在各種函數，使用它們可查閱 HTML 中的各個元素。

10.3 Web 應用

原本應用 HTTP 協定的 Web 的機制就是對用戶端發來的請求，傳回事前準備好的内容。

引入由程式建立 HTML 内容的做法。

對，對，這個是關鍵！它不是指有web功能的本地應用，而是指能動态生成網頁

類似這種由程式建立的内容稱為動态内容，而事先準備好的内容稱為靜态内容。Web 應用則作用于動态内容之上。

CGI（Common Gateway Interface，通用網關接口）是指 Web 伺服器在接收到用戶端發送過來的請求後轉發給程式的一組機制。在 CGI 的作用下，程式會對請求内容做出相應的動作，比如建立 HTML 等動态内容。

Servlet1 是一種能在伺服器上建立動态内容的程式。Servlet 是用 Java 語言實作的一個接口，屬于面向企業級 Java（JavaEE，Java Enterprise Edition）的一部分。

Servlet=Server+Applet，表示輕量服務程式

Servlet 的運作環境叫做 Web 容器或 Servlet 容器。

随着 CGI 的普及，每次請求都要啟動新 CGI 程式的 CGI 運作機制逐漸變成了性能瓶頸，是以之後 Servlet 和 mod_perl 等可直接在 Web 伺服器上運作的程式才得以開發、普及。

10.4 資料釋出的格式及語言

與 HTML 相比，它對資料的記錄方式做了特殊處理。

用浏覽器打開該文檔時，就會顯示排列的清單内容，但如果這些資料被其他程式讀取會發生什麼？某些程式雖然具備可通過識别布局特征取出文本的方法，但這份 HTML 的樣式一旦改變，要讀取資料内容也就變得相對困難了。可見，為了保持資料的正确讀取，HTML 不适合用來記錄資料結構。

因為浏覽器隻是顯示，不是解析

XML 和 HTML 一樣，使用标簽構成樹形結構，并且可自定義擴充标簽。

從 XML 文檔中讀取資料比起 HTML 更為簡單。由于 XML 的結構基本上都是用标簽分割而成的樹形結構，是以通過文法分析器（Parser）的解析功能解析 XML

RSS（簡易資訊聚合，也叫聚合内容）和 Atom 都是釋出新聞或部落格日志等更新資訊文檔的格式的總稱。兩者都用到了 XML。

false/null/true/ 對象 / 數組 / 數字 / 字元串，這 7 種類型。

11.1 針對 Web 的攻擊技術

協定本身幾乎不會成為攻擊的對象

應用 HTTP 協定的伺服器和用戶端，以及運作在伺服器上的 Web 應用等資源才是攻擊目标。

幾乎現今所有的 Web 網站都會使用會話（session）管理、加密處理等安全性方面的功能，而 HTTP 協定内并不具備這些功能。

是以，開發者需要自行設計并開發認證及會話管理功能來滿足 Web 應用的安全。而自行設計就意味着會出現各種形形色色的實作。結果，安全等級并不完備，可仍在運作的 Web 應用背後卻隐藏着各種容易被攻擊者濫用的安全漏洞的 Bug。

在 Web 應用中，從浏覽器那接收到的 HTTP 請求的全部内容，都可以在用戶端自由地變更、篡改。是以 Web 應用可能會接收到與預期 資料不相同的内容。

這個的意思沒寫明白，确切意思應該是說伺服器接受到的http請求是可以是黑客刻意編輯的攻擊代碼

在 HTTP 請求封包内加載攻擊代碼，就能發起對 Web 應用的攻擊。通過 URL 查詢字段或表單、HTTP 首部、Cookie 等途徑把攻擊代碼傳入，若這時 Web 應用存在安全漏洞，那内部資訊就會遭到竊取，或被攻擊者拿到管理權限。

主動攻擊模式裡具有代表性的攻擊是 SQL 注入攻

擊和 OS 指令注入攻擊。

在被動攻擊過程中，攻擊者不直接對目标 Web 應用通路發起攻擊。

步驟 3： 中招後的使用者浏覽器會把含有攻擊代碼的 HTTP 請求發送給作為攻擊目标的 Web 應用，運作攻擊代碼。

步驟 4： 執行完攻擊代碼，存在安全漏洞的 Web

應用會成為攻擊者的跳闆，可能導緻使用者所持的 Cookie 等個人資訊被竊取，登入狀态中的使用者權限遭惡意濫用等後果

被動攻擊模式中具有代表性的攻擊是跨站腳本攻擊和跨站點請求僞造。

利用使用者的身份攻擊企業内部網絡

利用被動攻擊，可發起對原本從網際網路上無法直接通路的企業内網等網絡的攻擊。隻要使用者踏入攻擊者預先設好的陷阱，在使用者能夠通路到的網絡範圍内，即使是企業内網也同樣會受到攻擊。

很多企業内網依然可以連接配接到網際網路上，通路 Web 網站，或接收網際網路發來的郵件。這樣就可能給攻擊者以可乘之機，誘導使用者觸發陷阱後對企業内網發動攻擊。

11.2 因輸出值轉義不完全引發的安全漏洞

從資料庫或檔案系統、HTML、郵件等輸出 Web 應用處理的資料之際，針對輸出做值轉義處理是一項至關重要的安全政策。當輸出值轉義不完全時，會因觸發攻擊者傳入的攻擊代碼，而給輸出對象帶來損害。

沒懂

動态建立的 HTML 部分有可能隐藏着安全漏洞

利用虛假輸入表單騙取使用者個人資訊。

利用腳本竊取使用者的 Cookie 值，被害者在不知情的情況下，幫助攻擊者發送惡意請求。顯示僞造的文章或圖檔。

具體方式好低端

此時的确認界面上，浏覽器會把使用者輸入的 <s> 解析成 HTML 标簽，然後顯示删除線。

删除線顯示出來并不會造成太大的不利後果，但如果換成使用 script 标簽将會如何呢。

下圖網站通過位址欄中 URI 的查詢字段指定 ID，即相當于在表單内自動填寫字元串的功能。而就在這個地方，隐藏着可執行跨站腳本攻擊的漏洞。

充分熟知此處漏洞特點的攻擊者，于是就建立了下面這段嵌入惡意代碼的 URL。并隐藏植入事先準備好的欺詐郵件中或 Web 頁面内，誘使使用者去點選該 URL。

哇哇哇！天，就這麼簡單，是以不要亂掃碼！

2016-03-06

當使用者在表單内輸入 ID 和密碼之後，就會直接發送到攻擊者的網站（也就是 hackr.jp），導緻個人登入資訊被竊取。

操作。如果在調用 SQL 語句的方式上存在疏漏，就有可能執行被惡意注入（Injection）非法 SQL 語句。

URL 的查詢字段已指定 q= 上野宣，這個值由 Web 應用傳入到 SQL 語句中，構成下方的 SQL 語句。

把剛才指定查詢字段的上野宣改寫成“上野宣'--”。

SQL 語句中的 -- 之後全視為注釋。即，and flag=1 這個條件被自動忽略了。

SQL 注入是攻擊者将 SQL 語句改變成開發者意想不到的形式以達到破壞結構的攻擊。

本案例中的問題僅僅是把未出版書籍的條目也一同顯示出來了。但實際發生 SQL 注入攻擊時，很有可能會導緻使用者資訊或結算内容等其他資料表的非法浏覽及篡改，進而使使用者遭受不同程度的損失。

OS 指令注入攻擊（OS Command Injection）是指通過 Web 應用，執行非法的作業系統指令達到攻擊的目的。隻要在能調用 Shell 函數的地方就有存在被攻擊的風險。

也就是說，通過 OS 注入攻擊可執行 OS 上安裝着的各種程式。

攻擊者的輸入值中含有分号（;）。這個符号在 OS 指令中，會被解析為分隔多個執行指令的标記。

HTTP 首部注入攻擊（HTTP Header Injection）是指攻擊者通過在響應首部字段内插入換行，添加任意響應首部或主體的一種攻擊。屬于被動攻擊模式。

此刻，首部字段 Set-Cookie 已生效，是以攻擊者可指定修改任意的 Cookie 資訊。通過和會話固定攻擊（攻擊者可使用指定的會話 ID）攻擊組合，攻擊者可僞裝成使用者。

攻擊者輸入的 %0D%0A，原本應該屬于首部字段 Location 的查詢值部分，但經過解析後，%0D%0A 變成了換行符，結果插入了新的首部字段。這樣一來，攻擊者可在響應中插入任意的首部字段。

利用這兩個連續的換行就可作出 HTTP 首部與主體分隔所需的空行了，這樣就能顯示僞造的主體，達到攻擊目的。這樣的攻擊叫做 HTTP 響應截斷攻擊。

通過 Web 應用對檔案處理操作時，在由外部指定檔案名的處理存在疏漏的情況下，使用者可使用 .../ 等相對路徑定位到 /etc/passed 等絕對路徑上，是以伺服器上任意的檔案或檔案目錄皆有可能被通路到。這樣一來，就有可能非法浏覽、篡改或删除 Web 伺服器上的檔案。

11.3 因設定或設計上的缺陷引發的安全漏洞

錯誤設定 Web 伺服器，或是由設計上的一些問題引起的安全漏洞。

強制浏覽（Forced Browsing）安全漏洞是指，從安置在 Web 伺服器的公開目錄下的檔案中，浏覽那些原本非自願公開的檔案。

直接顯示容易推測的檔案名或檔案目錄索引時，通過某些方法可能會使 URL 産生洩露。

http://www.example.com/log/

通過指定檔案目錄名稱，即可在檔案一覽中看到顯示的檔案名。容易被推測的檔案名及目錄名

http://www.example.com/entry/entry_081202.log檔案名稱容易推測（按上面的情況，可推出下一個檔案是 entry_081203.log）

備份檔案http://www.example.com/cgi-bin/entry.cgi（原始檔案）

http://www.example.com/cgi-bin/entry.cgi~（備份檔案）http://www.example.com/cgi-bin/entry.bak（備份檔案）

由編輯軟體自動生成的備份檔案無執行權限，有可能直接以源代碼形式顯示

即使沒有對這篇日記的通路權限，隻要知道這圖檔的 URL，通過直接指定 URL 的方式就能顯示該圖檔。日記的功能和文本具有通路對象的控制，但不具備對圖檔通路對象的控制，進而産生了安全漏洞。

Web 應用不必在使用者的浏覽畫面上展現詳細的錯誤消息。對攻擊者來說，詳細的錯誤消息有可能給他們下一次攻擊以提示。

攻擊者利用進行不同的輸入會提示不同的錯誤資訊這條，就可用來确認輸入的郵件位址是否已在這個 Web 網站上注冊過了。

為了不讓錯誤消息給攻擊者以啟發，建議将提示消息的内容僅保留到“認證錯誤”這種程度即可

攻擊者從這條消息中可讀出資料庫選用的是 MySQL，甚至還看見了 SQL 語句的片段。這可能給攻擊者進行 SQL 注入攻擊以啟發。

假如指定的重定向 URL 到某個具有惡意的 Web 網站，那麼使用者就會被誘導至那個 Web 網站。

11.4 因會話管理疏忽引發的安全漏洞

會話劫持（Session Hijack）是指攻擊者通過某種手段拿到了使用者的會話 ID，并非法使用此會話 ID 僞裝成使用者，達到攻擊的目的

2016-03-07

通過非正規的生成方法推測會話 ID

通過竊聽或 XSS 攻擊盜取會話 ID通過會話固定攻擊（Session Fixation）強行擷取會話 ID

這個 Web 網站的認證功能，會在認證前釋出一個會話 ID，若認證成功，就會在伺服器内改變認證狀态。

跨站點請求僞造（Cross-Site Request Forgeries，CSRF）攻擊是指攻擊者通過設定好的陷阱，強制對已完成認證的使用者進行非預期的個人資訊或設定資訊等某些狀态更新，屬于被動攻擊。

攻擊者設定好一旦使用者通路，即會發送在留言闆上發表非主觀行為産生的評論的請求的陷阱。使用者 A 的浏覽器執行完陷阱中的請求後，留言闆上也就會留下那條評論（步驟②）。

11.5 其他安全漏洞

密碼破解有以下兩種手段。

通過網絡的密碼試錯對已加密密碼的破解（指攻擊者入侵系統，已獲得加密或散列處理的密碼資料的情況）

除去突破認證的攻擊手段，還有 SQL 注入攻擊逃避認證，跨站腳本攻擊竊取密碼資訊等方法

因為窮舉法會嘗試所有的候選密碼，是以是一種必然能夠破解密碼的攻擊。但是，當密鑰空間很龐大時，解密可能需要花費數年，甚至千年的時間，是以從現實角度考量，攻擊是失敗的。

Web 應用在儲存密碼時，一般不會直接以明文的方式儲存，通過散列函數做散列處理或加 salt 的手段對要儲存的密碼本身加密。那即使攻擊者使用某些手段竊取密碼資料，如果想要真正使用這些密碼，則必須先通過解碼等手段，把加密處理的密碼還原成明文形式。

彩虹表

彩虹表（Rainbow Table）是由明文密碼及與之對應的散列值構成的一張資料庫表，是一種通過事先制作龐大的彩虹表，可在窮舉法 • 字典攻擊等實際破解過程中縮短消耗時間的技巧。從彩虹表内搜尋散列值就可以推導出對應的明文密碼。

為了提高攻擊成功率，擁有一張海量資料的彩虹表就成了必不可少的條件。例如在 Free Rainbow Tables 網站上（http://www.freerainbowtables.com/en/tables2/）公布的一張由大小寫字母及數字全排列的 1~8 位字元串對應的 MD5 散列值構成的彩虹表，其大小約為 1050 吉位元組。

而 Web 應用開發者獨立實作的加密算法，想必尚未經過充分的驗證，還是很有可能存在漏洞的。

點選劫持（Clickjacking）是指利用透明的按鈕或連結做成陷阱，覆寫在 Web 頁面之上。然後誘使使用者在不知情的情況下，點選那個連結通路内容的一種攻擊手段。這種行為又稱為界面僞裝（UI Redressing）。

攻擊者在預料使用者會點選的 Web 頁面上設下陷阱。上圖中釣魚遊戲頁面上的 PLAY 按鈕就是這類陷阱的執行個體。

在做過手腳的 Web 頁面上，目标的 SNS 登出功能頁面将作為透明層覆寫在遊戲網頁上。覆寫時，要保證 PLAY 按鈕與登出按鈕的頁面所在位置保持一緻。

主要有以下兩種 DoS 攻擊方式。

集中利用通路請求造成資源過載，資源用盡的同時，實際上服務也就呈停止狀态。通過攻擊安全漏洞使服務停止。

伺服器很難分辨何為正常請求，何為攻擊請求，是以很難防止 DoS 攻擊。

通常的後門程式分為以下 3 種類型。

開發階段作為 Debug 調用的後門程式開發者為了自身利益植入的後門程式

攻擊者通過某種方法設定的後門程式