HTTP協議概述
HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP是一個基於TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
HTTP協議的主要特點可概括如下：
1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
HTTP協議初探
1、一個簡單的HTTP協議：
HTTP協議和TCP/IP協議族內的其他眾多的協議相同，用於客戶端和服務器之間的通信。請求訪問文本或圖像等資源的一端稱為客戶端，而提供資源響應的一端稱為服務器端。
下面我們來看一個具體的示例：
請求報文：
起始行開頭的GET表示請求訪問服務器的類型，稱為方法（method）。隨后的字符串/index.htm指明了請求訪問的資源對象，也叫做請求URI（request-URI）。最后的HTTP/1.1，即HTTP的版本號，用來提示客戶端使用的HTTP協議功能。
綜合來看，這段請求內容的意思是：請求訪問某台HTTP服務器上的/index.htm頁面資源。
請求報文是由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。
響應報文：
在起始行開頭的HTTP/1.1表示服務器對應的HTTP版本。
緊挨着的200OK表示請求的處理結果的狀態碼（status code）和原因短語（reason-phrase）。下一行顯示了創建響應的日期時間，是首部字段（header field）內的一個屬性。
接着以一空行分隔，之后的內容稱為資源實體的主體（entity body）。
響應報文基本上由協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。
2、HTTP協議中常用的方法：
GET：獲取資源
GET方法用來請求訪問已被URI識別的資源。指定的資源經服務器端解析后返回響應內容。也就是說，如果請求的資源是文本，那就保持原樣返回；如果是像CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回經過執行后的輸出結果。
POST：傳輸實體主體
POST方法用來傳輸實體的主體。雖然用GET方法也可以傳輸實體的主體，但一般不用GET方法進行傳輸，而是用POST方法。雖說POST的功能與GET很相似，但POST的主要目的並不是獲取響應的主體內容。
PUT：傳輸文件
PUT方法用來傳輸文件。就像FTP協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然后保存到請求URI指定的位置。
HEAD：獲得報文首部
HEAD方法和GET方法一樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等。
DELETE：刪除文件
DELETE方法用來刪除文件，是與PUT相反的方法。DELETE方法按請求URI刪除指定的資源。
CONNECT：要求用隧道協議連接代理
CONNECT方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL（Secure Sockets Layer，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密后經網絡隧道傳輸。
上面列舉了一下常見的方法，HTTP協議支持的方法入下圖所示：
HTTP報文內的HTTP信息
1、HTTP報文：
用於HTTP協議交互的信息被稱為HTTP報文。請求端（客戶端）的HTTP報文叫做請求報文，響應端（服務器端）的叫做響應報文。HTTP報文本身是由多行（用CR+LF作換行符）數據構成的字符串文本。
HTTP報文大致可分為報文首部和報文主體兩塊。兩者由最初出現的空行（CR+LF）來划分。通常，並不一定要有報文主體。
2、報文結構：
請求報文結構：
響應報文結構：
請求行：包含用於請求的方法，請求URI和HTTP版本
狀態行：包含表明響應結果的狀態碼，原因短語和HTTP版本
首部字段：包含表示請求和響應的各種條件和屬性的各類首部
其他：可能包含HTTP的RFC里未定義的首部（Cookie等）
HTTP狀態碼
1、狀態碼分類：
狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。借助狀態碼，用戶可以知道服務器端是正常處理了請求，還是出現了錯誤。
2、2XX成功：
200 OK：表示從客戶端發來的請求在服務器端被正常處理了。
204 NO Content：該狀態碼代表服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。另外，也不允許返回任何實體的主體。比如，當從瀏覽器發出請求處理后，返回204響應，那么瀏覽器顯示的頁面不發生更新。
206 Parial Content：該狀態碼表示客戶端進行了范圍請求，而服務器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定范圍的實體內容。
3、3XX重定向：
301 Moved Permanently：永久性重定向。該狀態碼表示請求的資源已被分配了新的URI，以后應使用資源現在所指的URI。也就是說，如果已經把資源對應的URI保存為書簽了，這時應該按Location首部字段提示的URI重新保存。
302 Found：臨時性重定向。該狀態碼表示請求的資源已被分配了新的URI，希望用戶（本次）能使用新的URI訪問。
303 See Other：該狀態碼表示由於請求對應的資源存在着另一個URI，應使用GET方法定向獲取請求的資源。
304 Not Modified：該狀態碼表示客戶端發送附帶條件的請求”時，服務器端允許請求訪問資源，但未滿足條件的情況。304狀態碼返回時，不包含任何響應的主體部分。304雖然被划分在3XX類別中，但是和重定向沒有關系。
307 Temporary Redirect：臨時重定向。該狀態碼與302Found有着相同的含義。盡管302標准禁止POST變換成GET，但實際使用時大家並不遵守。
4、4XX客戶端錯誤：
400 Bad Request：該狀態碼表示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容后再次發送請求。另外，瀏覽器會像2000K一樣對待該狀態碼。
401 Unauthorized：該狀態碼表示發送的請求需要有通過HTTP認證（BASIC認證、DIGEST認證）的認證信息。另外若之前已進行過1次請求，則表示用戶認證失敗。
403 Forbidden：該狀態碼表明對請求資源的訪問被服務器拒絕了。服務器端沒有必要給出拒絕的詳細理由，但如果想作說明的話，可以在實體的主體部分對原因進行描述，這樣就能讓用戶看到了。
404 Not Found：該狀態碼表明服務器上無法找到請求的資源。除此之外，也可以在服務器端拒絕請求且不想說明理由時使用。
5、5XX服務器錯誤：
500 Internal Server Error：該狀態碼表明服務器端在執行請求時發生了錯誤。也有可能是Web應用存在的bug或某些臨時的故障。
503 Service Unavailable：該狀態碼表明服務器暫時處於超負載或正在進行停機維護，現在無法處理請求。如果事先得知解除以上狀況需要的時間，最好寫入Retry-After首部字段再返回給客戶端。
HTTP報文首部
1、概述：
HTTP首部字段是構成HTTP報文的要素之一。在客戶端與服務器之間以HTTP協議進行通信的過程中，無論是請求還是響應都會使用首部字段，它能起到傳遞額外重要信息的作用。
使用首部字段是為了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。
2、HTTP首部字段結構：
HTTP首部字段是由首部字段名和字段值構成的，中間用冒號“：”分隔，如 Content-Type: text/html
3、HTTP首部字段一覽：
通用首部字段：
請求首部字段：
響應首部字段：
實體首部字段：
4、通用首部字段詳解：
1、Cache-Control：通過指定首部字段Cache-Control的指令，就能操作緩存的工作機制。
2、Connction：控制不再轉發給代理的首部字段；管理持久連接。
3、Date：首部Date字段表明創建HTTP報文的日期和時間。
4、Trailer：首部字段Trailer會事先說明在報文主體后記錄了哪些首部字段。該首部字段可應用在HTTP/1.1版本分塊傳輸編碼時。
5、Transfer-Encoding：首部字段Transfer-Encoding規定了傳輸報文主體時采用的編碼方式。
6、Upgrade：首部字段Upgrade用於檢測HTTP協議及其他協議是否可使用更高的版本進行通信，其參數值可以用來指定一個完全不同的通信協議。
7、Via：使用首部字段Via是為了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。
5、請求首部字段：
1、Accept：Accept首部字段可通知服務器，用戶代理能夠處理的媒體類型及媒體類型的相對優先級。可使用type/subtype這種形式，一次指定多種媒體類型。
2、Accept-Charset：Accept-Charset首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優先順序。另外，可一次性指定多種字符集。與首部字段Accept相同的是可用權重q值來表示相對優先級。
3、Accept-Encoding：Accept-Encoding首部字段用來告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序。可一次性指定多種內容編碼。
4、Accept-Language：首部字段Accept-Language用來告知服務器用戶代理能夠處理的自然語言集（指中文或英文等），以及自然語言集的相對優先級。可一次指定多種自然語言集。
5、Authorization：首部字段Authorization是用來告知服務器，用戶代理的認證信息（證書值）。通常，想要通過服務器認證的用戶代理會在接收到返回的401狀態碼響應后，把首部字段Authorization加入請求中。共用緩存在接收到含有Authorization首部字段的請求時的操作處理會略有差異。
6、Except：客戶端使用首部字段Expect來告知服務器，期望出現的某種特定行為。因服務器無法理解客戶端的期望作出回應而發生錯誤時，會返回狀態碼417Expectation Failed。
7、From：首部字段From用來告知服務器使用用戶代理的用戶的電子郵件地址。通常，其使用目的就是為了顯示搜索引擎等用戶代理的負責人的電子郵件聯系方式。使用代理時，應盡可能包含From首部字段（但可能會因代理不同，將電子郵件地址記錄在User-Agent首部字段內）。
8、Host：首部字段Host會告知服務器，請求的資源所處的互聯網主機名和端口號。Host首部字段在HTTP/1.1規范內是唯一一個必須被包含在請求內的首部字段。
9、User-Agent：首部字段User-Agent會將創建請求的瀏覽器和用戶代理名稱等信息傳達給服務器。
6、響應首部字段：
1、Accept-Ranges：首部字段Accept-Ranges是用來告知客戶端服務器是否能處理范圍請求，以指定獲取服務器端某個部分的資源。
2、Age：首部字段Age能告知客戶端，源服務器在多久前創建了響應。字段值的單位為秒。
3、Location：使用首部字段Location可以將響應接收方引導至某個與請求URI位置不同的資源。
4、Proxy-Authenticate：首部字段Proxy-Authenticate會把由代理服務器所要求的認證信息發送給客戶端。
5、Server：首部字段Server告知客戶端當前服務器上安裝的HTTP服務器應用程序的信息。不單單會標出服務器上的軟件應用名稱，還有可能包括版本號和安裝時啟用的可選項。
6、Vary：首部字段Vary可對緩存進行控制。源服務器會向代理服務器傳達關於本地緩存使用方法的命令。
7、實體首部字段：
1、Allow：首部字段Allow用於通知客戶端能夠支持Request-URI指定資源的所有HTTP方法。當服務器接收到不支持的HTTP方法時，會以狀態碼405 Method Not Allowed作為響應返回。
2、Content-Encoding：首部字段Content-Encoding會告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。
3、Content-Language：使用的語言。
4、Content-Length：首部字段Content-Length表明了實體主體部分的大小（單位是字節）。
5、Content-Location：首部字段Content-Location給出與報文主體部分相對應的URI。和首部字段Location不同，Content-Location表示的是報文主體返回資源對應的URI。
6、Content-Range：針對范圍請求，返回響應時使用的首部字段Content-Range，能告知客戶端作為響應返回的實體的哪個部分符合范圍請求。字段值以字節為單位，表示當前發送部分及整個實體大小。
7、Content-Type：首部字段Content-Type說明了實體主體內對象的媒體類型。和首部字段Accept一樣，字段值用type/subtype形式賦值。
HTTPS
1、HTTP缺點：
- 通信使用明文（不加密），內容可能會被竊聽
- 不驗證通信方的身份，因此有可能遭遇偽裝
- 無法證明報文的完整性，所以有可能已遭篡改
2、HTTPS簡介：
如果在HTTP協議通信過程中使用未經加密的明文，比如在Web頁面中輸入信用卡號，如果這條通信線路遭到竊聽，那么信用卡號就暴露了。
另外，對於HTTP來說，服務器也好，客戶端也好，都是沒有辦法確認通信方的。因為很有可能並不是和原本預想的通信方在實際通信。並且還需要考慮到接收到的報文在通信途中已經遭到篡改這一可能性。
為了統一解決上述這些問題，需要在HTTP上再加入加密處理和認證等機制。我們把添加了加密及認證機制的HTTP稱為HTTPS（HTTP Secure）。
3、HTTPS=HTTP+SSL：
HTTPS並非是應用層的一種新協議。只是HTTP通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。
通常，HTTP直接和TCP通信。當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。簡言之，所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP。在采用SSL后，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。
4、加密技術：
共享密鑰加密：
加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common key crypto system），也被叫做對稱密鑰加密。
共享密鑰加密是不安全的，因為只要攻擊者拿到了密鑰，就可以進行破解。
公開密鑰加密：
公開密鑰加密方式很好地解決了共享密鑰加密的困難。
公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key）。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得。使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。
另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難的，因為解密過程就是在對離散對數進行求值，這並非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那么密碼破解還是存在希望的。但就目前的技術來看是不太現實的。
5、HTTPS采用混合加密機制：
HTTPS采用共享密鑰加密和公開密鑰加密兩者並用的混合加密機制。若密鑰能夠實現安全交換，那么有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。所以應充分利用兩者各自的優勢，將多種方法組合起來用於通信。
在交換密鑰環節使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式。
6、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。
WEB攻擊技術
1、Web的攻擊模式：
以服務器為目標的主動攻擊：
主動攻擊（active attack）是指攻擊者通過直接訪問Web應用，把攻擊代碼傳人的攻擊模式。由於該模式是直接針對服務器上的資源進行攻擊，因此攻擊者需要能夠訪問到那些資源。
主動攻擊模式里具有代表性的攻擊是SQL注入攻擊和OS命令注入攻擊。
以服務器為目標的被動攻擊：
被動攻擊（passive attack）是指利用圈套策略執行攻擊代碼的攻擊模式。在被動攻擊過程中，攻擊者不直接對目標Web應用訪問發起攻擊。
2、XSS攻擊：
xss就是攻擊者在web頁面插入惡意的Script代碼，當用戶瀏覽該頁之時，嵌入其中web里面的Script代碼會被執行，從而達到惡意攻擊用戶的特殊目的。
例如：
<select>
<script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script>
</select>
3、SQL注入攻擊：
SQL注入（SQLInjection）是指針對Web應用使用的數據庫，通過運行非法的SQL而產生的攻擊。該安全隱患有可能引發極大的威脅，有時會直接導致個人信息及機密信息的泄露。Web應用通常都會用到數據庫，當需要對數據庫表內的數據進行檢索或添加、刪除等操作時，會使用SQL語句連接數據庫進行特定的操作。如果在調用SQL語句的方式上存在疏漏，就有可能執行被惡意注入（Injection）非法SQL語句。
4、OS命令注入攻擊：
OS命令注入攻擊（OSCommand Injection）是指通過Web應用，執行非法的操作系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。OS命令注入攻擊可以向Shell發送命令，讓Windows或Linux操作系統的命令行啟動程序。也就是說，通過OS注入攻擊可執行OS上安裝着的各種程序。
5、郵件首部注入攻擊：
郵件首部注入（Mail Header Injection）是指Web應用中的郵件發送功能，攻擊者通過向郵件首部To或Subject內任意添加非法內容發起的攻擊。利用存在安全漏洞的Web網站，可對任意郵件地址發送廣告郵件或病毒郵件。