《圖解 HTTP》閱讀摘要

時間 2019-11-07

標籤圖解 HTTP 閱讀摘要欄目 HTTP/TCP 简体版

原文原文鏈接

這本 HTTP 方面的小冊子還蠻不錯，已經二刷了 😜javascript

此次作了一些筆記，方便本身和其餘人翻閱和複習，由於這本書是 2014 年出的第一版，因此有一些不怎麼經常使用的技術，筆記中就省略了，只記一些比較經常使用的 ~php

若是但願獲取本書的 PDF 資源，能夠關注文末二維碼加微信羣找羣主要～html

1. 瞭解 Web 及網絡基礎

1.1 網絡基礎 TCP/IP

一般使用的網絡（包括互聯網）是在 TCP/IP 協議族的基礎上運做，而 HTTP 屬於它內部的一個子集。前端

按層次分爲如下 4 層：應用層、傳輸層、網絡層和數據鏈路層。java

應用層： 決定了向用戶提供應用服務時通訊的活動，好比 FTP、DNS、HTTP
傳輸層： 對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸，好比 TCP、UDP
網絡層： 用來處理在網絡上流動的數據包，該層規定了經過怎樣的路徑（所謂的傳輸路線）到達對方計算機，並把數據包傳送給對方；與對方計算機之間經過多臺計算機或網絡設備進行傳輸時，網絡層所起的做用就是在衆多的選項內選擇一條傳輸路線。
數據鏈路層： 用來處理鏈接網絡的硬件部分

利用 TCP/IP 協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，接收端則往應用層往上走。web

以 HTTP 爲例，一次通訊的過程算法

首先做爲發送端的客戶端在應用層（HTTP 協議）發出獲取 Web 頁面的 HTTP 請求
接着，爲了傳輸方便，在傳輸層（TCP 協議）把從應用層處收到的數據（HTTP 請求報文）進行分割，並在各個報文上打上標記序號及端口號後轉發給網絡層。
在網絡層（IP 協議），增長做爲通訊目的地的 MAC 地址後轉發給鏈路層。這樣一來，發往網絡的通訊請求就準備齊全了
接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP 請求。

發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每通過一層時會把對應的首部消去。sql

這種把數據信息包裝起來的作法稱爲封裝（encapsulate）。數據庫

1.2 三次握手

爲了準確無誤地將數據送達目標處，TCP 協議採用了三次握手（three-way handshaking）策略。握手過程當中使用了 TCP 的標誌（flag） —— SYN（synchronize）和 ACK（acknowledgement）。瀏覽器

發送端首先發送一個帶 SYN 標誌的數據包給對方。接收端收到後，回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶 ACK 標誌的數據包，表明「握手」結束。

1.3 負責域名解析的 DNS 服務

DNS（Domain Name System）服務是和 HTTP 協議同樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。

1.4 各協議與 HTTP 協議的關係

經過這張圖來了解下 IP 協議、TCP 協議和 DNS 服務在使用 HTTP 協議的通訊過程當中各自發揮了哪些做用。

1.5 URI 和 URL

瞭解一下 URI 的各部分

協議方案名： 使用 http: 或 https: 等協議方案名獲取訪問資源時要指定協議類型。不區分字母大小寫，最後附一個冒號。也可以使用 data: 或 javascript: 這類指定數據或腳本程序的方案名。
登陸信息（認證）： 指定用戶名和密碼做爲從服務器端獲取資源時必要的登陸信息（身份認證）。此項是可選項。
服務器地址： 使用絕對 URI 必須指定待訪問的服務器地址。地址能夠是相似 hackr.jp 這種 DNS 可解析的名稱，或是 192.168.1.1 這類 IPv4 地址名，還能夠是 [0:0:0:0:0:0:0:1] 這樣用方括號括起來的 IPv6 地址名。
服務器端口號： 指定服務器鏈接的網絡端口號。此項也是可選項，若用戶省略則自動使用默認端口號。
帶層次的文件路徑： 指定服務器上的文件路徑來定位特指的資源。這與 UNIX 系統的文件目錄結構類似。
查詢字符串： 針對已指定的文件路徑內的資源，可使用查詢字符串傳入任意參數。此項可選。
片斷標識符： 使用片斷標識符一般可標記出已獲取資源中的子資源（文檔內的某個位置）。但在 RFC 中並無明確規定其使用方法。該項也爲可選項

2. 簡單的 HTTP 協議

2.1 HTTP 是不保存狀態的協議

HTTP 是一種不保存狀態，即無狀態（stateless）協議。HTTP 協議自身不對請求和響應之間的通訊狀態進行保存。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特地把 HTTP 協議設計成如此簡單的。

HTTP1.1 雖然是無狀態協議，但爲了實現指望的保持狀態功能，因而引入了 Cookie 技術。

2.2 告知服務器意圖的 HTTP 方法

GET 獲取資源： 用來請求訪問已被 URI 識別的資源，指定的資源經服務器端解析後返回響應內容。若是請求的資源是文本，那就保持原樣返回；若是是像 CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回通過執行後的輸出結果。
POST 傳輸實體主體： 用來傳輸實體的主體雖然用 GET 方法也能夠傳輸實體的主體，但通常不用 GET 方法進行傳輸，而是用 POST 方法。雖然說 POST 的功能與 GET 很類似，但 POST 的主要目的並非獲取響應的主體內容。
PUT 傳輸文件： 在請求報文的主體中包含文件內容，而後保存到請求 URI 指定的位置鑑於 HTTP1.1 的 PUT 方法自身不帶驗證機制，任何人均可以上傳文件，存在安全性問題，所以通常的 Web 網站不使用該方法。
HEAD 得到報文首部： 和 GET 方法同樣，只是不返回報文主體部分。用於確認 URI 的有效性及資源更新的日期時間等。
DELETE 刪除文件： 用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。 HTTP1.1 的 DELETE 方法自己和 PUT 方法同樣不帶驗證機制，因此通常的 Web 網站也不使用 DELETE 方法。
OPTIONS 詢問支持的方法： 用來查詢針對請求 URI 指定的資源支持的方法。
TRACE 追蹤路徑： 讓 Web 服務器端將以前的請求通訊環回給客戶端的方法。發送請求時，在 Max-Forwards 首部字段中填入數值，每通過一個服務器端就將該數字減 1，當數值恰好減到 0 時，就中止繼續傳輸，最後接收到請求的服務器端則返回狀態碼 200 OK 的響應。但 TRACE 方法原本就不怎麼經常使用，再加上它容易引起 XST（Cross-Site Tracing，跨站追蹤）攻擊，一般就更不會用到了。
CONNECT 要求用隧道協議鏈接代理： 要求在與代理服務器通訊時創建隧道，實現用隧道協議進行 TCP 通訊。主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。

方法	說明	支持的 HTTP 協議版本
GET	獲取資源	1.0、1.1
POST	傳輸實體主體	1.0、1.1
PUT	傳輸文件	1.0、1.1
HEAD	得到報文首部	1.0、1.1
DELETE	刪除文件	1.0、1.1
OPTIONS	詢問支持的方法	1.1
TRACE	追蹤路徑	1.1
CONNECT	要求用隧道協議鏈接代理	1.1
LINK	創建和資源之間的聯繫	1.0
UNLINE	斷開鏈接關係	1.0

LINK 和 UNLINK 已被 HTTP1.1 廢棄，再也不支持。

2.3 持久鏈接節省通訊量

HTTP 協議的初始版本中，每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接。

好比，使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請求該 HTML 頁面裏包含的其餘資源。所以，每次的請求都會形成無謂的 TCP 鏈接創建和斷開，增長通訊量的開銷。

持久連接 keep-alive

HTTP1.1 和一部分的 HTTP1.0 想出了持久鏈接（keep-alive）的方法。持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。

持久鏈接的好處在於減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使 HTTP 請求和響應可以更早地結束，這樣 Web 頁面的顯示速度也就相應提升了。

在 HTTP1.1 中，全部的鏈接默認都是持久鏈接，但在 HTTP1.0 內並未標準化。

管線化 pipelining

持久鏈接使得多數請求以管線化（pipelining）方式發送成爲可能。從前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。

這樣就可以作到同時並行發送多個請求，而不須要一個接一個地等待響應了。

用持久鏈接可讓請求更快結束。而管線化技術則比持久鏈接還要快。請求數越多，時間差就越明顯。

2.4 使用 Cookie 的狀態管理

HTTP 是無狀態協議，它不對以前發生過的請求和響應的狀態進行管理。也就是說，沒法根據以前的狀態進行本次的請求處理。

假設要求登陸認證的 Web 頁面自己沒法進行狀態的管理（不記錄已登陸的狀態），那麼每次跳轉新頁面不是要再次登陸，就是要在每次請求報文中附加參數來管理登陸狀態。

Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。

3. HTTP 報文內的 HTTP 信息

3.1 編碼提高傳輸速率

HTTP 能夠在傳輸過程當中經過編碼提高傳輸速率。

3.2 壓縮傳輸的內容編碼

內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。

經常使用的內容編碼有：gzip（GNU zip）、compress（UNIX 系統的標準壓縮）deflate（zlib）、identity（不進行編碼）

3.3 分割發送的分塊傳輸編碼

在 HTTP 通訊過程當中，請求的編碼實體資源還沒有所有傳輸完成以前，瀏覽器沒法顯示請求頁面。在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面。這種把實體主體分塊的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）。

分塊傳輸編碼會將實體主體分紅多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最後一塊會使用「0(CR+LF)」來標記。

使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼，恢復到編碼前的實體主體。

3.4 發送多種數據的多部分對象集合

在 HTTP 報文中使用多部分對象集合時，須要在首部字段里加上 Content-type：

multipart/form-data： 在 Web 表單文件上傳時使用。
multipart/byteranges： 狀態碼 206（Partial Content，部份內容）響應報文包含了多個範圍的內容時使用。

3.5 獲取部份內容的範圍請求

若是下載過程當中遇到網絡中斷的狀況，那就必須重頭開始。爲了解決上述問題，須要一種可恢復的機制。所謂恢復是指能從以前下載中斷處恢復下載。

要實現該功能須要指定下載的實體範圍，指定範圍發送的請求叫作範圍請求（Range Request）。針對範圍請求，響應會返回狀態碼 206。

好比：

5001~10 000 字節：Range: bytes=5001-10000
從 5001 字節以後所有的：Range: bytes=5001-
從一開始到 3000 字節和 5000~7000 字節的多重範圍：Range: bytes=-3000, 5000-7000

3.6 內容協商返回最合適的內容

內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，而後提供給客戶端最爲適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等做爲判斷的基準。

包含在請求報文中的某些首部字段（以下）就是判斷的基準：Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language

有如下幾種類型：

服務器驅動協商： 以請求的首部字段爲參考，在服務器端自動處理。但對用戶來講，以瀏覽器發送的信息做爲斷定的依據，並不必定能篩選出最優內容。
客戶端驅動協商： 用戶從瀏覽器顯示的可選項列表中手動選擇。還能夠利用 JavaScript 腳本在 Web 頁面上自動進行上述選擇。好比按 OS 的類型或瀏覽器類型，自行切換成 PC 版頁面或手機版頁面。
透明協商： 是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。

4. 返回結果的 HTTP 狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。藉助狀態碼，用戶能夠知道服務器端是正常處理了請求，仍是出現了錯誤。

4.1 狀態碼告知從服務器端返回的請求結果

數字中的第一位指定了響應類別，後兩位無分類

	類別	緣由短語
1XX	Informational（信息性狀態碼）	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	須要進行附加操做以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	服務器沒法處理請求
5XX	Server Error（服務器錯誤狀態碼）	服務器處理請求出錯

4.2 2xx 成功

請求被正常處理了。

200 OK： 表示從客戶端發來的請求在服務器端被正常處理了
204 No Content： 表示服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。另外，也不容許返回任何實體的主體。好比，當從瀏覽器發出請求處理後，返回 204 響應，那麼瀏覽器顯示的頁面不發生更新。通常在只須要從客戶端往服務器發送信息，而對客戶端不須要發送新信息內容的狀況下使用。
206 Partial Content： 表示客戶端進行了範圍請求，而服務器成功執行了這部分的 GET 請求。響應報文中包含由 Content-Range 指定範圍的實體內容。

4.3 3XX 重定向

瀏覽器須要執行某些特殊的處理以正確處理請求。

301 Moved Permanently： 永久性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，之後應使用資源如今所指的 URI。也就是說，若是已經把資源對應的 URI 保存爲書籤了，這時應該按 Location 首部字段提示的 URI 從新保存。
302 Found： 臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，但願用戶（本次）能使用新的 URI 訪問。已移動的資源對應的 URI 未來還有可能發生改變。
303 See Other： 表示因爲請求對應的資源存在着另外一個 URI，應使用 GET 方法定向獲取請求的資源。303 和 302 有着相同的功能，但 303 狀態碼明確表示客戶端應當採用 GET 方法獲取資源，這點與 302 狀態碼有區別。
304 Not Modified： 客戶端發送 GET 方法的請求頭中包含 If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since 中任一首部時，服務器端容許請求訪問資源，但未知足條件的狀況。304 狀態碼返回時，不包含任何響應的主體部分。304 雖然被劃分在 3XX 類別中，可是和重定向沒有關係。
307 Temporary Redirect： 臨時重定向，與 302 Found 有着相同的含義。

4.4 4XX 客戶端錯誤

客戶端發生了錯誤。

400 Bad Request： 表示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。另外，瀏覽器會像 200 同樣對待該狀態碼。
401 Unauthorized： 表示發送的請求須要有經過 HTTP 認證的認證信息。若以前已進行過一次請求，則表示用戶認證失敗。返回含有 401 的響應必須包含一個適用於被請求資源的 WWW-Authenticate 首部用以質詢用戶信息。當瀏覽器初次接收到 401 響應，會彈出認證用的對話窗口。
403 Forbidden： 對請求資源的訪問被服務器拒絕了。服務器端沒有必要給出拒絕的詳細理由，但若是想做說明的話，能夠在實體的主體部分對緣由進行描述，這樣就能讓用戶看到了。好比未得到文件系統的訪問受權、訪問權限出現某些問題等情景。
404 Not Found： 服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求且不想說明理由時使用。

4.5 5XX 服務器錯誤

服務器自己發生錯誤。

500 Internal Server Error： 服務器端在執行請求時發生了錯誤，也有多是 Web 應用存在的 bug 或某些臨時的故障。
503 Service Unavailable： 代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上情況須要的時間，最好寫入 RetryAfter 首部字段再返回給客戶端。

5. 與 HTTP 協做的 Web 服務器

一臺 Web 服務器可搭建多個獨立域名的 Web 網站，也可做爲通訊路徑上的中轉服務器提高傳輸效率。

5.1 用單臺虛擬主機實現多個域名

HTTP1.1 規範容許一個服務器搭建多個 Web 站點，這是虛擬主機（Virtual Host，又稱虛擬服務器）功能。

若是一臺服務器內託管了兩個域名，對應的同一個服務器 IP，當收到請求時就須要弄清楚究竟要訪問哪一個域名，因爲虛擬主機能夠寄存多個不一樣主機名和域名的 Web 網站，所以在發送 HTTP 請求時，必須在 Host 首部內完整指定主機名或域名的 URI。

5.2 通訊數據轉發程序：代理、網關、隧道

這些應用程序和服務器能夠將請求轉發給通訊線路上的下一站服務器，而且能接收從那臺服務器發送的響應再轉發給客戶端。

代理： 接收客戶端發送的請求後轉發給其餘服務器，。代理不改變請求 URI，會直接發送給前方持有資源的目標服務器。
1. 緩存代理：預先將資源緩存保存在代理服務器上，當代理再次接收到對相同資源的請求時，就能夠直接將以前緩存的資源做爲響應返回。
2. 透明代理：轉發請求或響應時，不對報文作任何加工被稱爲透明代理，對報文內容進行加工的稱爲非透明代理。
網關： 轉發其餘服務器通訊數據的服務器，接收從客戶端發送來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理。有時客戶端可能都不會察覺，本身的通訊目標是一個網關。網關能提升通訊的安全性，由於能夠在客戶端與網關之間的通訊線路上加密以確保鏈接的安全。
隧道： 按要求創建起一條與其餘服務器的通訊線路，屆時使用 SSL 等加密手段進行通訊，在通訊雙方斷開鏈接時結束。。隧道的目的是確保客戶端能與服務器進行安全的通訊。

5.3 保存資源的緩存

緩存是指代理服務器或客戶端本地保存的資源副本，是代理服務器的一種。

優點在於避免屢次從源服務器轉發資源，客戶端可就近從緩存服務器上獲取資源，而源服務器也沒必要屢次處理相同請求。

客戶端的緩存： 瀏覽器緩存若是有效，沒必要再向服務器請求，而直接從本地讀取。當斷定緩存過時後，會向源服務器確認資源的有效性。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資源。

6. HTTP 首部

HTTP 協議的請求和響應報文中一定包含 HTTP 首部，請求報文大約是下面的結構，響應報文相似

6.1 HTTP 首部字段

由首部字段名和字段值構成的，中間用冒號「:」分隔
字段值對應單個 HTTP 首部字段能夠有多個值

HTTP 首部字段將定義成緩存代理和非緩存代理的行爲，分紅 2 種類型。

端到端首部： 分在此類別中的首部會轉發給請求 / 響應對應的最終接收目標，且必須保存在由緩存生成的響應中，另外規定它必須被轉發。
逐跳首部： 分在此類別中的首部只對單次轉發有效，會因經過緩存或代理而再也不轉發。HTTP1.1 和以後版本中，若是要使用 hop-by-hop 首部，需提供 Connection 首部字段。

下面列舉了 HTTP1.1 中的逐跳首部字段。除這 8 個首部字段以外，其餘全部字段都屬於端到端首部。

Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
Trailer
TE
Transfer-Encoding
Upgrade

HTTP 首部根據用途被分爲 4 種 HTTP 首部字段類型，在 HTTP 協議通訊交互中使用到的首部字段，不限於 RFC2616 中定義的 47 種。還有 Cookie、Set-Cookie 和 Content-Disposition 等在其餘 RFC 中定義的，使用頻率也很高。

通用首部字段

請求報文和響應報文兩方都會使用的首部。

首部字段名	說明
Cache-Control	控制緩存的行爲
Connection	逐跳首部、鏈接的管理
Date	建立報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級爲其餘協議
Via	代理服務器的相關信息
Warning	錯誤通知

請求首部字段

從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。

首部字段名	說明
Accept	用戶代理可處理的媒體類型
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言（天然語言）
Authorization	Web認證信息
Expect	期待服務器的特定行爲
From	用戶的電子郵箱地址
Host	請求資源所在服務器
If-Match	比較實體標記（ETag）
If-Modified-Since	比較資源的更新時間
If-None-Match	比較實體標記（與 If-Match 相反）
If-Range	資源未更新時發送實體 Byte 的範圍請求
If-Unmodified-Since	比較資源的更新時間（與If-Modified-Since相反）
Max-Forwards	最大傳輸逐跳數
Proxy-Authorization	代理服務器要求客戶端的認證信息
Range	實體的字節範圍請求
Referer	對請求中 URI 的原始獲取方
TE	傳輸編碼的優先級
User-Agent	HTTP 客戶端程序的信息

響應首部字段

從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

首部字段名	說明
Accept-Ranges	是否接受字節範圍請求
Age	推算資源建立通過時間
ETag	資源的匹配信息
Location	令客戶端重定向至指定URI
Proxy-Authenticate	代理服務器對客戶端的認證信息
Retry-After	對再次發起請求的時機要求
Server	HTTP服務器的安裝信息
Vary	代理服務器緩存的管理信息
WWW-Authenticate	服務器對客戶端的認證信息

實體首部字段

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

首部字段名	說明
Allow	資源可支持的HTTP方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的天然語言
Content-Length	實體主體的大小（單位：字節）
Content-Location	替代對應資源的URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置範圍
Content-Type	實體主體的媒體類型
Expires	實體主體過時的日期時間
Last-Modified	資源的最後修改日期時間

6.2 HTTP1.1 通用首部字段

通用首部字段是指請求報文和響應報文都會使用的首部。

Cache-Control

no-cache： 防止從緩存中返回過時的資源。客戶端請求若是包含 no-cache，表示客戶端將不會接收緩存過的響應，緩存服務器必須把客戶端請求轉發給源服務器。服務器響應中包含 no-cache，那麼緩存服務器不能對資源進行緩存，源服務器之後也將再也不對緩存服務器請求中提出的資源有效性進行確認，且禁止其對響應資源進行緩存操做。
no-store： 緩存不能在本地存儲請求或響應的任一部分。

從字面意思上很容易把 no-cache 誤解成爲不緩存，但 no-cache 表明不緩存過時的資源，緩存會向源服務器進行有效期確認後處理資源，no-store 纔是真正地不進行緩存。

Connection

控制再也不轉發給代理的首部字段： 在客戶端發送請求和服務器返回響應內，使用 Connection 首部字段，可控制再也不轉發給代理的首部字段（即 Hop-by-hop 首部）。
管理持久鏈接： HTTP1.1 默認持久鏈接，客戶端會在持久鏈接上連續發送請求。服務器端想斷開鏈接時，則設置 Connection 首部字段爲 Close。HTTP1.1 以前默認都是非持久鏈接。爲此，若是想在舊版本 HTTP 協議上持續鏈接，則需設置 Connection 首部字段爲 Keep-Alive。

Date

代表建立 HTTP 報文的日期和時間。

Upgrade

用於檢測 HTTP 協議及其餘協議是否可以使用更高的版本進行通訊，其參數值能夠用來指定一個徹底不一樣的通訊協議。

6.3 請求首部字段

從客戶端往服務器端發送請求報文中所使用的字段，用於補充請求的附加信息、客戶端信息、對響應內容相關的優先級等內容。

Accept

通知服務器，用戶代理可以處理的媒體類型及媒體類型的相對優先級。可以使用 type/subtype 這種形式，一次指定多種媒體類型。

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
複製代碼

Host

告知服務器，請求的資源所處的互聯網主機名和端口號。Host 首部字段在 HTTP1.1 規範內是惟一一個必須被包含在請求內的首部字段。

請求被髮送至服務器時，主機名會直接用 IP 地址。但若是這時，相同的 IP 地址下部署多個域名，那麼服務器就會沒法理解到底是哪一個域名對應的請求。所以，就須要使用首部字段 Host 來明確指出請求的主機名。若服務器未設定主機名，那直接設空值便可。

If-Match

形如 If-xxx 這種，均可稱爲條件請求。服務器接收到後，只有判斷指定條件爲真時，纔會執行請求。

首部字段 If-Match，屬附帶條件之一，它會告知服務器匹配資源所用的實體標記（ETag）值。這時的服務器沒法使用弱 ETag 值。服務器會比對 If-Match 的字段值和資源的 ETag 值，僅當二者一致時，纔會執行請求。

能夠用星號 *，服務器會忽略 ETag 的值，只要資源存在就處理請求。

If-None-Match

和 If-Match 做用相反，用於指定 If-None-Match 的實體標記 ETag 值與請求資源的 ETag 不一致時，它就告知服務器處理該請求。

If-Modified-Since

若是在 If-Modified-Since 字段指定的日期時間後資源發生了更新，服務器會接受請求。

指定 If-Modified-Since 字段值的日期時間以後，請求的資源在給定的日期時間以後對內容進行過修改的狀況下才會將資源返回，狀態碼爲 200，若是請求的資源沒有更新，則返回狀態碼 304 Not Modified 的響應。

If-Unmodified-Since

If-Unmodified-Since 和 If-Modified-Since 的做用相反。它的做用的是告知服務器，指定的請求資源只有在指定日期時間以後未發生更新，才處理請求。若是在指定日期時間後發生了更新，則以狀態碼 412 Precondition Failed 做爲響應返回。

If-Range

If-Range 字段若是跟 ETag 值或更新的日期時間一致，那麼就做爲範圍請求處理。反之，則返回全體資源。

6.4 響應首部字段

由服務器端向客戶端返回響應報文中所使用的字段，用於補充響應的附加信息、服務器信息，以及對客戶端的附加要求等信息。

ETag

實體標識，將資源以字符串形式作惟一性標識的方式。服務器會爲每份資源分配對應的 ETag 值。當資源更新時，ETag 值也須要更新。

若在下載過程當中出現鏈接中斷、再鏈接的狀況，都會依照 ETag 值來指定資源。

6.5 實體首部字段

包含在請求報文和響應報文中的實體部分所使用的首部，用於補充內容的更新時間等與實體相關的信息。

Allow

通知客戶端可以支持的全部 HTTP 方法。當服務器接收到不支持的 HTTP 方法時，會以狀態碼 405 Method Not Allowed 做爲響應返回。與此同時，還會把全部能支持的 HTTP 方法寫入首部字段 Allow 後返回。

Content-Encoding

告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。

主要有：gzip、compress、deflate、identity

Content-Length

代表了實體主體部分的大小（單位是字節）。對實體主體進行內容編碼傳輸時，不能再使用 Content-Length 首部字段。

Content-Type

說明了實體主體內對象的媒體類型，用 type/subtype 形式賦值。

Content-Type: text/html; charset=UTF-8
複製代碼

Expires

Expires 會將資源失效的日期告知客戶端。緩存服務器在收到有 Expires 的響應後，會以緩存來應答請求，在 Expires 字段值指定的時間以前，響應的副本會一直被保存。當超過指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求資源。

源服務器不但願緩存服務器對資源緩存時，最好在 Expires 字段內寫入與 Date 相同的時間值。

可是，當首部字段 Cache-Control 有指定 max-age 時，比起 Expires，會優先處理 max-age 指令。

Last-Modified

包含源頭服務器認定的資源作出修改的日期及時間。

6.6 爲 Cookie 服務的首部字段

首部字段名	說明	首部類型
Set-Cookie	開始狀態管理所使用的Cookie信息	響應首部字段
Cookie	服務器接收到的Cookie信息	請求首部字段

Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;	
複製代碼

屬性	說明
NAME=VALUE	賦予 Cookie 的名稱和其值（必需項）
expires=DATE	Cookie 的有效期（若不明確指定則默認爲瀏覽器關閉前爲止）
path=PATH	將服務器上的文件目錄做爲Cookie的適用對象（若不指定則默認爲文檔所在的文件目錄）
domain=域名	做爲 Cookie 適用對象的域名（若不指定則默認爲建立 Cookie 的服務器的域名）
Secure	僅在 HTTPS 安全通訊時纔會發送 Cookie
HttpOnly	加以限制，使 Cookie 不能被 JavaScript 腳本訪問

一旦 Cookie 從服務器端發送至客戶端，服務器端就沒有顯式刪除 Cookie 的方法。但可經過覆蓋已過時的 Cookie，實現對客戶端 Cookie 的實質性刪除操做。

HttpOnly 屬性是 Cookie 的擴展功能，它使 JavaScript 腳本沒法得到 Cookie。其主要目的爲防止跨站腳本攻擊（Cross-site scripting，XSS）對 Cookie 的信息竊取。

Cookie

Cookie: status=enable
複製代碼

當客戶端想得到 HTTP 狀態管理支持時，就會在請求中包含從服務器接收到的 Cookie。

6.7 其餘首部字段

X-XSS-Protection

是針對跨站腳本攻擊（XSS）的一種對策，用於控制瀏覽器 XSS 防禦機制的開關，可指定的字段值以下

0：將 XSS 過濾設置成無效狀態
1：將 XSS 過濾設置成有效狀態

7. 確保 Web 安全的 HTTPS

HTTP 協議中有可能存在信息竊聽或身份假裝等安全問題，使用 HTTPS 能夠有效地防止這些問題。

7.1 HTTP 的缺點

通訊使用明文（不加密），內容可能會被竊聽
不驗證通訊方的身份，所以有可能遭遇假裝
沒法證實報文的完整性，因此有可能已遭篡改

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

把添加了加密及認證機制的 HTTP 稱爲 HTTPS（HTTP Secure）。HTTPS 並不是是應用層的一種新協議，只是 HTTP 通訊接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。SSL 是獨立於 HTTP 的協議，因此其餘運行在應用層的 SMTP 和 Telnet 等協議都可配合 SSL 協議使用。

HTTPS 採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。若密鑰可以實現安全交換，那麼有可能會考慮僅使用公開密鑰加密來通訊。可是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。

因此取長補短，在交換密鑰環節使用公開密鑰加密方式，以後的創建通訊交換報文階段則使用共享密鑰加密方式。

數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書就是認證的能夠信賴的公開密鑰，服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通訊。公鑰證書也可叫作數字證書或直接稱爲證書。

HTTPS 通訊的步驟：

客戶端經過發送 Client Hello 報文開始 SSL 通訊。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
服務器可進行 SSL 通訊時，會以 Server Hello 報文做爲應答。和客戶端同樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
以後服務器發送 Certificate 報文。報文中包含公開密鑰證書。
最後服務器發送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協商部分結束。
SSL 第一次握手結束以後，客戶端以 Client Key Exchange 報文做爲迴應。報文中包含通訊加密中使用的一種被稱爲 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文以後的通訊會採用 Pre-master secret 密鑰加密。
客戶端發送 Finished 報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。
服務器一樣發送 Change Cipher Spec 報文。
服務器一樣發送 Finished 報文。
服務器和客戶端的 Finished 報文交換完畢以後，SSL 鏈接就算創建完成。固然，通訊會受到 SSL 的保護。今後處開始進行應用層協議的通訊，即發送 HTTP 請求。
應用層協議通訊，即發送 HTTP 響應。
最後由客戶端斷開鏈接。斷開鏈接時，發送 close_notify 報文。上圖作了一些省略，這步以後再發送 TCP FIN 報文來關閉與 TCP 的通訊。

在以上流程中，應用層發送數據時會附加一種叫作 MAC（Message Authentication Code）的報文摘要。MAC 可以查知報文是否遭到篡改，從而保護報文的完整性。

SSL 速度慢嗎

HTTPS 也存在一些問題，那就是當使用 SSL 時，它的處理速度會變慢。它慢分兩種。一種是指通訊慢。另外一種是指因爲大量消耗 CPU 及內存等資源，致使處理速度變慢。

和 HTTP 相比，HTTPS 網絡負載可能會變慢 2 到 100 倍。除去和 TCP 鏈接、發送 HTTP 請求響應之外，還必須進行 SSL 通訊，所以總體上處理通訊量不可避免會增長。另外 SSL 必須進行加密處理，在服務器和客戶端都須要進行加解密處理，比 HTTP 消耗更多硬件資源，致使負載加強。

針對速度變慢這一問題，並無根本性的解決方案，通常會使用 SSL 加速器這種（專用服務器）硬件。能提升數倍 SSL 的計算速度，僅在 SSL 處理時發揮功效，分擔負載。

沒使用 HTTPS 的緣由

與純文本通訊相比，加密通訊會消耗更多的 CPU 及內存資源。若是每次通訊都加密，會消耗至關多的資源，平攤到一臺計算機上時，可以處理的請求數量一定也會隨之減小。

若是是非敏感信息則使用 HTTP 通訊，只有在包含我的信息等敏感數據時，才利用 HTTPS 加密通訊。能夠僅在那些須要信息隱藏時才加密，以節約資源。

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

8. 確認訪問用戶身份的認證

一些頁面只想讓特定的人瀏覽，這就引入了認證功能。

HTTP1.1 經常使用的認證方式：

BASIC 認證（基本認證）
DIGEST 認證（摘要認證）
SSL 客戶端認證
FormBase 認證（基於表單認證）

9. 基於 HTTP 的功能追加協議

9.1 全雙工通訊的 WebSocket

鏈接的發起方還是客戶端，一旦確立 WebSocket 通訊鏈接，服務器與客戶端任意一方均可向對方發送報文。

推送功能： 支持由服務器向客戶端推送數據的推送功能。這樣，服務器可直接發送數據，而沒必要等待客戶端的請求。
減小通訊量： 和 HTTP 相比，不但每次鏈接時的開銷減小，且因爲首部信息很小，通訊量也減小了。

通訊的創建：

首先使用 HTTP 的 Upgrade 首部字段，告知服務器通訊協議發生改變，進行握手。

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
複製代碼

Sec-WebSocket-Key 字段內記錄着握手過程當中必不可少的鍵值。Sec-WebSocket-Protocol 字段內記錄使用的子協議。

以前的請求將會被返回 101 Switching Protocols 響應
```
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
複製代碼
```
Sec-WebSocket-Accept 的字段值是由握手請求中的 Sec-WebSocket-Key 的字段值生成的。

成功握手創建 WebSocket 鏈接以後，通訊時再也不使用 HTTP 的數據幀，而採用 WebSocket 獨立的數據幀。

9.2 HTTP/2.0

HTTP/2.0 的目標是改善用戶在使用 Web 時的速度體驗。特色：

HTTP/2.0 採用二進制格式而非文本格式
HTTP/2.0 是徹底多路複用的，而非有序並阻塞的——只需一個鏈接便可實現並行
使用報頭壓縮，HTTP/2.0 下降了開銷
HTTP/2.0 讓服務器能夠將響應主動「推送」到客戶端緩存中

10. 構建 Web 內容的技術

10.1 HTML

HTML（HyperText Markup Language，超文本標記語言）是爲了發送 Web 上的超文本（Hypertext）而開發的標記語言。

超文本是一種文檔系統，可將文檔中任意位置的信息與其餘信息（文本或圖片等）創建關聯，即超連接文本。

10.2 Web 應用

Web 應用是指經過 Web 功能提供的應用程序。

CGI 每次接到請求，都要跟着啓動一次，一旦訪問量過大，Web 服務器要承擔至關大的負載。而 Servlet 運行在與 Web 服務器相同的進程中，所以受到的負載較小。

Servlet 的運行環境叫作 Web 容器或 Servlet 容器。隨着 CGI 的普及，每次請求都要啓動新 CGI 程序的 CGI 運行機制逐漸變成了性能瓶頸。而 Servlet 常駐內存，在每次請求時，可啓動相對進程級別更爲輕量的 Servlet，程序的執行效率從而變得更高。

11. Web 的攻擊技術

11.1 針對 Web 的攻擊技術

HTTP 協議自己並不存在安全性問題，服務器和客戶端以及運行在服務器上的 Web 應用等資源纔是攻擊目標。

HTTP 就是一個通用的單純協議機制，開發者須要自行設計並開發認證及會話管理功能來知足 Web 應用的安全，所以在運行的應用會隱藏着各類容易被攻擊者濫用的安全漏洞。

在客戶端便可篡改請求

從瀏覽器那接收到的 HTTP 請求的所有內容，均可以在客戶端自由地變動、篡改。因此 Web 應用接受到的內容可能與預期數據不一樣。

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

針對 Web 應用的攻擊模式

對 Web 攻擊的模式有主動攻擊和被動攻擊兩種

主動攻擊

指攻擊者經過直接訪問 Web 應用，把攻擊代碼傳入的攻擊模式。因爲該模式是直接針對服務器上的資源進行攻擊，所以攻擊者須要可以訪問到那些資源。

表明性的是 SQL 注入攻擊和 OS 命令注入攻擊。

被動攻擊

指利用圈套策略執行攻擊代碼的攻擊模式。在被動攻擊過程當中，攻擊者不直接對目標 Web 應用訪問發起攻擊。

表明性的是跨站腳本攻擊和跨站點請求僞造。

一般的攻擊步驟

攻擊者誘使用戶觸發已設置好的陷阱，而陷阱會啓動發送已嵌入攻擊代碼的 HTTP 請求。
當用戶不知不覺中招以後，用戶的瀏覽器或郵件客戶端就會觸發這個陷阱。
中招後的用戶瀏覽器會把含有攻擊代碼的 HTTP 請求發送給做爲攻擊目標的 Web 應用，運行攻擊代碼。
執行完攻擊代碼，存在安全漏洞的 Web 應用會成爲攻擊者的跳板，可能致使用戶所持的 Cookie 等我的信息被竊取，登陸狀態中的用戶權限遭惡意濫用等後果。

11.2 因輸出值轉義不徹底引起的安全漏洞

驗證主要有兩種：

客戶端的驗證
Web 應用端（服務器端）的驗證，包括輸入值驗證和輸出值轉義

通常驗證數據是在客戶端使用 JS，然而客戶端的腳本是能夠篡改的，因此不適合做爲安全對策。

從數據庫或文件系統、HTML、郵件等輸出需處理的數據的時候，針對輸出作值轉義處理是一項相當重要的安全策略。當輸出值轉義不徹底時，會觸發攻擊者傳入的攻擊代碼。

XSS 跨站腳本攻擊

跨站腳本攻擊（Cross-Site Scripting，XSS）是指經過存在安全漏洞的客戶端運行非法的 HTML 標籤或 JavaScript 進行的一種攻擊。動態建立的 HTML 部分有可能隱藏着安全漏洞。

若是用戶填寫的表單是直接做爲 HTML 解析，那麼換成 script 標籤，就中招了。

SQL 注入攻擊

SQL 注入（SQL Injection）是指針對 Web 應用使用的數據庫，經過運行非法的 SQL 而產生的攻擊。

若是在調用 SQL 語句的方式上存在疏漏，就可能被惡意注入（Injection）非法的 SQL 語句。

好比，若是把表單查詢的字段直接拼接給 SQL 語句，那麼可能會出現下面這個狀況

上面一句查詢的是 上野宣，下面一句查詢 上野宣'--

SELECT * FROM bookTbl WHERE author = '上野宣' and flag = 1;
SELECT * FROM bookTbl WHERE author = '上野宣'--' and flag = 1;
複製代碼

SQL 語句中的 -- 以後全視爲註釋，所以 and flag=1 這個條件被自動忽略了，失去過濾條件，不想顯示的內容也被顯示出來了。

OS 命令注入攻擊

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

HTTP 首部注入攻擊

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

向首部主體內添加內容的攻擊稱爲 HTTP 響應截斷攻擊（HTTP Response Splitting Attack）。

好比有時候 Web 應用有時會把從外部收到的值，賦給響應首部字段 Location 和 Set-Cookie。若是攻擊者發送 101%0D%0ASet-Cookie:+SID=123456789 這裏的 %0D%0A 表明的是換行符，那麼就會致使結果返回：

Location: http://example.com/?cat=101（%0D%0A ：換行符）
Set-Cookie: SID=123456789
複製代碼

這裏攻擊者就能夠修改任意的 Cookie 信息了。

這個例子中，本來應該屬於首部字段 Location 的查詢值部分，攻擊者輸入的 %0D%0A 成了換行符，結果插入了新的首部字段，實際上攻擊者能夠在響應中插入任意的首部字段。

HTTP 響應截斷攻擊

HTTP 響應截斷攻擊是用在 HTTP 首部注入的一種攻擊。

攻擊順序相同，可是要將兩個 %0D%0A%0D%0A 並排插入字符串後發送。利用這兩個連續的換行就可做出 HTTP 首部與主體分隔所需的空行了，這樣就能顯示僞造的主體，達到攻擊目的。

Set-Cookie: UID=（%0D%0A ：換行符）
（%0D%0A ：換行符）
<HTML><HEAD><TITLE>以後，想要顯示的網頁內容 <!-- （原來頁面對應的首部字段和主體部分全視爲註釋）
複製代碼

利用這個攻擊，已觸發陷阱的用戶瀏覽器會顯示僞造的 Web 頁面，再讓用戶輸入本身的我的信息等，可達到和跨站腳本攻擊相同的效果。

郵件首部注入攻擊

郵件首部注入（Mail Header Injection）是指 Web 應用中的郵件發送功能，攻擊者經過向郵件首部 To 或 Subject 內任意添加非法內容發起的攻擊。利用存在安全漏洞的 Web 網站，可對任意郵件地址發送廣告郵件或病毒郵件。

目錄遍歷攻擊

目錄遍歷（Directory Traversal）攻擊是指對本無心公開的文件目錄，經過非法截斷其目錄路徑後，達成訪問目的的一種攻擊。這種攻擊有時也稱爲路徑遍歷（Path Traversal）攻擊。

經過 Web 應用對文件處理操做時，在由外部指定文件名的處理存在疏漏的狀況下，用戶可以使用 .../ 等相對路徑定位到 /etc/passed 等絕對路徑上，所以服務器上任意的文件或文件目錄皆有可能被訪問到。這樣一來，就有可能非法瀏覽、篡改或刪除 Web 服務器上的文件。

http://example.com/read.php?log=0401.log
http://example.com/read.php?log=../../etc/passwd
複製代碼

遠程文件包含漏洞

遠程文件包含漏洞（Remote File Inclusion）是指當部分腳本內容須要從其餘文件讀入時，攻擊者利用指定外部服務器的 URL 充當依賴文件，讓腳本讀取以後，就可運行任意腳本的一種攻擊。

11.3 因設置或設計上的缺陷引起的安全漏洞

強制瀏覽

對那些本來不肯公開的文件，爲了保證安全會隱蔽其 URL。可一旦知道了那些 URL，也就意味着可瀏覽 URL 對應的文件。好比

http://www.example.com/entry/entry_081202.log
複製代碼

這樣一個路徑，就很容易推測出下一個文件是 entry_081203.log，從而被訪問。

不正確的錯誤消息處理

不正確的錯誤消息處理（Error Handling Vulnerability）的安全漏洞是指，Web 應用的錯誤信息內包含對攻擊者有用的信息。與 Web 應用有關的主要錯誤信息以下所示：

Web 應用拋出的錯誤消息 Web 應用沒必要在用戶的瀏覽畫面上展示詳細的錯誤消息。對攻擊者來講，詳細的錯誤消息有可能給他們下一次攻擊以提示。
數據庫等系統拋出的錯誤消息攻擊者從某些錯誤消息中可讀出數據庫選用的類型，有時還可看見 SQL 語句的片斷。這可能給攻擊者進行 SQL 注入攻擊以啓發。系統應對詳細的錯誤消息進行抑制設定，或使用自定義錯誤消息。

開放重定向

開放重定向（Open Redirect）是一種對指定的任意 URL 做重定向跳轉的功能。而於此功能相關聯的安全漏洞是指，假如指定的重定向 URL 到某個具備惡意的 Web 網站，那麼用戶就會被誘導至那個 Web 網站。好比:

http://example.com/?redirect=http://www.tricorder.jp
http://example.com/?redirect=http://hackr.jp
複製代碼

可信度高的 Web 網站若是開放重定向功能，則會被攻擊者用來做爲釣魚攻擊的跳板。

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

會話劫持

會話劫持（Session Hijack）是指攻擊者經過某種手段拿到了用戶的會話 ID，並不是法使用此會話 ID 假裝成用戶，達到攻擊的目的。

攻擊者在得知該 Web 網站存在可跨站攻擊 XSS 的安全漏洞後，就設置好用 JavaScript 腳本調用 document.cookie 以竊取 Cookie 信息的陷阱，獲取含有會話 ID 的 Cookie。

拿到用戶的會話 ID 後，往本身的瀏覽器的 Cookie 中設置該會話 ID，便可假裝成會話 ID 遭竊的用戶，訪問 Web 網站。

會話固定攻擊

對以竊取目標會話 ID 爲主動攻擊手段的會話劫持而言，會話固定攻擊（Session Fixation）攻擊會強制用戶使用攻擊者指定的會話 ID，屬於被動攻擊。

攻擊者設置好強制用戶使用該會話 ID 的陷阱，並等待用戶拿着這個會話 ID 前去認證。一旦用戶觸發陷阱並完成認證，會話在服務器上的狀態（用戶 A 已認證）就會被記錄下來，再利用以前這個會話 ID 訪問網站。

CSRF 跨站點請求僞造

跨站點請求僞造（Cross-Site Request Forgeries，CSRF）攻擊是指攻擊者經過設置好的陷阱，強制對已完成認證的用戶進行非預期的我的信息或設定信息等某些狀態更新，屬於被動攻擊。

好比這個留言板功能，只容許已認證並登陸的用戶發表內容。用戶的 Cookie 持有已認證的會話 ID。用戶若是點擊了攻擊者留下的惡意代碼連接，則會利用用戶的信息執行操做。

11.5 其餘安全漏洞

密碼破解

密碼破解攻擊（Password Cracking）即算出密碼，突破認證。

經過網絡進行密碼試錯主要有下面兩種方式：

窮舉法（Brute-force Attack，又稱暴力破解法）是指對全部密鑰集合構成的密鑰空間（Keyspace）進行窮舉。
字典攻擊是指利用事先收集好的候選密碼（通過各類組合方式後存入字典），枚舉字典中的密碼，嘗試經過認證的一種攻擊手法。

字典攻擊中有一種利用其餘 Web 網站已泄露的 ID 及密碼列表進行的攻擊，由於不少用戶習慣隨意地在多個 Web 網站使用同一套 ID 及密碼。

對已加密密碼的破解一般有下面幾種方法：

經過窮舉法/字典攻擊進行類推
彩虹表
拿到密鑰
加密算法的漏洞

點擊劫持

點擊劫持（Clickjacking）是指利用透明的按鈕或連接作成陷阱，覆蓋在 Web 頁面之上。而後誘使用戶在不知情的狀況下，點擊那個連接訪問內容的一種攻擊手段。這種行爲又稱爲界面假裝（UI Redressing）。

已設置陷阱的 Web 頁面，表面上內容並沒有不妥，但早已埋入想讓用戶點擊的連接。當用戶點擊到透明的按鈕時，其實是點擊了已指定透明屬性元素的 iframe 頁面。

DoS 攻擊

DoS 攻擊（Denial of Service attack）是一種讓運行中的服務呈中止狀態的攻擊。有時也叫作服務中止攻擊或拒絕服務攻擊。DoS 攻擊的對象不只限於 Web 網站，還包括網絡設備及服務器等。

集中利用訪問請求形成資源過載，好比發送大量的合法請求
經過攻擊安全漏洞使服務中止。

後門程序

後門程序（Backdoor）是指開發設置的隱藏入口，可不按正常步驟使用受限功能。利用後門程序就可以使用本來受限制的功能。

可經過監視進程和通訊的狀態發現被植入的後門程序。但設定在 Web 應用中的後門程序，因爲和正常使用時區別不大，一般很難發現。

PS：歡迎你們關注個人公衆號【前端下午茶】，一塊兒加油吧~

另外能夠加入「前端下午茶交流羣」微信羣，長按識別下面二維碼便可加我好友，備註加羣，我拉你入羣～

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

《圖解 HTTP》 閱讀摘要